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: