diff options
Diffstat (limited to 'touch/idl/org/libreoffice/touch/XDocument.idl')
-rw-r--r-- | touch/idl/org/libreoffice/touch/XDocument.idl | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/touch/idl/org/libreoffice/touch/XDocument.idl b/touch/idl/org/libreoffice/touch/XDocument.idl new file mode 100644 index 000000000000..bc3d563d8708 --- /dev/null +++ b/touch/idl/org/libreoffice/touch/XDocument.idl @@ -0,0 +1,73 @@ +// -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- + +// Copyright 2012 LibreOffice contributors. +// +// This Source Code Form is subject to the terms of the Mozilla Public +// License 2.0. If a copy of the MPL was not distributed with this +// file, You can obtain one at http://mozilla.org/MPL/2.0/. + +#ifndef org_libreoffice_touch_XDocument_idl +#define org_libreoffice_touch_XDocument_idl + +#include <com/sun/star/uno/XInterface.idl> +#include <com/sun/star/lang/IllegalArgumentException.idl> + +module org { module libreoffice { module touch { + +// Note that this is work in progress + +// Error handling? Presumably for true errors expected to be uncommon, or +// invalid usage, the methods should throw exceptions. + +// Multithreaded use of this is undefined (the intent obviously is that this +// API is called in another thread than the "main" UI thread, but calling this +// stuff on the same object simultaneously in multiple threads is undefined). + +// Represents one (Writer, for now) document + +interface XDocumentRenderCallback; + +interface XDocument: com::sun::star::uno::XInterface +{ + [attribute, readonly] long numberOfPages; + + // Renders a (part of a) page into a square bitmap, for Android in the + // android.graphics.Bitmap.Config.ARGB_8888 format. Despite the name, the + // order of bytes is R,G,B,A. Is this reliable, or coincidental depending + // on Android version and/or hardware? TBD. Will the same format be useful + // also for iOS? TBD. + + // buffer must have an exact number of bytes for a square number of + // pixels, At the UNO level buffer is represented as the address of its + // bytes, i.e. on Android it must be a "direct" ByteBuffer for that to be + // meaningful. + + // listener gets a "reasonable" number of callbacks during the rendering + // if it takes "significantly" long, and can inerrupt the rendering. + + // zoomLevel is 0 for whole page, 1 for tiled into four, etc. + + // x and y are in [0..2^zoomLevel] + + // Should we have this method copy the rendered buffer into a Bitmap + // instead and return that? A Bitmap is presumably what the caller wants + // anyway? + + // Or should we just go OpenGL ES and render into a texture? + + void render( [in] hyper buffer, + [in] long bufferSize, + [in] XDocumentRenderCallback listener, + [in] long pageNo, + [in] long zoomLevel, + [in] long x, + [in] long y) + raises( com::sun::star::lang::IllegalArgumentException ); + +}; + +}; }; }; + +#endif + +// vim:set shiftwidth=4 softtabstop=4 expandtab: |