Using LibreOffice for Documentation

Tommy Trussell tommy.trussell at gmail.com
Thu Sep 3 13:25:49 EDT 2015


On Thu, Sep 3, 2015 at 11:40 AM, Mike Evans <mikee at saxicola.co.uk> wrote:

> A new but related thread then.
>
> It seems many documenters are not prepared to accept anything but a
> WYSIWIG solution, even though I feel then learning the arcanery of
> LibreOffice is harder than learning Asciidoc. Oh well.
>
> LibreOffice was mentioned ealier, somewhere so I thought I'd experiment a
> bit.  I've put the results of my experiment at
> https://github.com/EvansMike/gnucash-opendocs It's not a perfect
> conversion but reasonably good.  Each file is still separate, and git
> trackable, and these are included into the master document "guide.odm".
>
> Just thought I'd throw it into the mix.
>
> Mike E
>
>
I have been following the discussions with interest, and using pandoc was a
tack I had not expected. Thanks!

I have two concerns that jump out immediately...

1) To be "better" trackable in git I would assume .fodt (flat uncompressed
xml) would be "better" than .odt, but it appears Pandoc doesn't have that
as an option. Oh, and I'm also aware of the spurious page markers (and
other things?) that makes git tracking of .fodt more difficult, and that
the LibreOffice folks don't intend to fix it. If this is a "one-shot"
conversion then that's not a problem, because the files could be converted
then be kept in whatever format works best.

2) To be "better" trackable, maintainable and functional I would assume the
doc files would need to pass through some sort of lint utility or something
to check or enforce "proper" stylesheet application and such -- because as
we know with WYSIWYG you can make it "LOOK" right (set the font attributes
etc.) but not "WORK" right (set the headings as necessary to generate the
code).

I don't have a ready-made solution. I would think an open-source
application like LibreOffice / OpenOffice would be ideal platform for
building an editor or utility that could enforce document structure, or at
the very least have a macro to highlight the obvious problems. But if
anyone has done this I haven't seen it.


More information about the gnucash-devel mailing list