LibreOfficeKit bits ...
michael.meeks at collabora.com
Tue Sep 30 06:03:18 PDT 2014
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
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
> > [ 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
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
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*
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
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
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.
michael.meeks at collabora.com <><, Pseudo Engineer, itinerant idiot
More information about the LibreOffice