Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


Hi Nicholas,

        So - CC'ing the public dev list as I said I would; since this is
generally interesting (I hope ;-).

On Tue, 2014-09-30 at 08:25 -0400, nicholas ferguson wrote:
    Sure sure - so; that's not -so- hard. You basically want the
equivalent of liblibreoffice I think - which currently works on
Linux only but is easy enough to tweak for Windows with a bit of
work / thought I think.

How do I get a liblibreoffice?  I hadn't heard of it.  which I presume
is Libreoffice full functionality available as a library?  Is this the
libreoffice built with 'headless'

        Sure - so, that is the goal; for Linux - yes headless; for Windows - we
need to do some more work to get headless-ness going nicely. Various
fonts & pieces needed for eg. headless PDF rendering are associated with
window handles & the like.

        So - I lie; it's not called liblibreoffice anymore it is
LibreOfficeKit:

http://cgit.freedesktop.org/libreoffice/core/tree/include/LibreOfficeKit

        Has the (so far rather spartan) API. We wrap a C++ API around some C
vtables - and the -idea- [ just to make you aware that we are trying to
care about ease of use ] - is that this would have zero compile-time
dependencies. Just cut/paste the dlopen type code in & then de-reference
some vtables. The very minimal tiled rendering API there is not stable
yet.

[ incidentally do you want this for an automated service or a UI
spreadsheet debugging tool ? 

automated service.  A small app that would link with liblibreoffice.
This app would have functions to

open(excel)
analyze(excel)
close(excel)

        Yep - so open & close are already parts of LibreOfficeKit. I have a
plan to try to expose the UNO functionality with pre-compiled headers in
such a way that these are also dependency-less; ie. you don't need to
link to anything to use the programmatic API; but that needs a somewhat
tweaked UNO binding - again, not got to that yet.

And behind these functions are code from liblibreoffice.  In  a
sense...liblibreoffice would be this fat rich library of code.

        Seems we share a vision =)

First round of accessement is to build an automated service that would
audit a spreadsheet.  Automated means that an application is started,
it loads up an excel spreadsheet, then generates an output of its
analysis.

        Sounds good to me; of course, we're also interested in internal
auditing tooling - I'd love that "histogram + list of functions used",
"visualized dependency graph" stuff built right into calc myself: tons
of people would use it.

So if I use code from sc.... what function/file  do I use that takes
as an argument, a url of an excel spreadsheet file and creates an
object that can allow access to all of the functionality in sc?

        Oh - so, that is actually hard ;-) then again - I -guess- we could have
some fun here. If you want a -really- evil / dirty hack, you could -try-
copy/pasting/hacking (in an ABI compatible way) some of the calc
headers; using LibreOfficeKit and dynamic_casting your UNO object
suitably ;-> [ URGH ! ;-]. Of course v. fragile, we don't support that
but might work for quick bootstrapping.

        The hook to dlopen / call is in desktop/source/lib/init.cxx - see the:

SAL_DLLPUBLIC_EXPORT LibreOfficeKit *libreofficekit_hook(const char*
install_path)

        Method - which is what returns that LOK class. Then by some horror of
dynamic_casting and ptr offsets, I suspect you could get from: 

struct LibLODocument_Impl : public _LibreOfficeKitDocument
{
    uno::Reference<css::lang::XComponent> mxComponent;

        To the:

 sc/inc/docuno.hxx:  public ::vcl::ITiledRenderable,

        And from there - ripping out only a few headers to an ScDocument ;-)

        Of course - that is all basically illegal; horribly fragile, none of
that ABI is stable - indeed we guarentee it will be horribly unstable
etc. =)

        So - in general, you'd do far better to implement the code inside
LibreOffice - inside a clean Windows VM; and then we can discuss a patch
to see if there is some way that we can provide a nice API for this.
Then again - if you want to get something working first and then iterate
- that'd be cool.

        I'd be open to a generic LibreOfficeKit API for introspecting
spreadsheets, their formulae etc. though it might be better to get a
sensible UNO bridge written first - and providing a UNO interface that
could be used generically at run-time.

        ATB,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.