LibreOfficeKit bits ...

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