Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]

On Tue, 24 Jan 2012, Michael Meeks wrote:

> On Mon, 2012-01-23 at 15:27 +0100, Michael Stahl wrote:
>
> > unfortunately this would have less benefits than you imagine, because of
> > the way xmloff writes automatic styles: they are generated anew on every
> > export, in a non-deterministic order
>
>         Wow - how non-deterministic ? randomly shuffled or ... ? ;-)
>
> > , which results in huge spurious diffs... (at least for Writer)
>
>         Interesting; the order is really not based on the order that the
> different intersection of styles appear in the document ? I suspect this
> is something that a number of people will want to improve for all those
> funky "store flat odf in git" things :-)

It's a worthy goal, but I can imagine that those people capable of using 
git might want to write documentation/text in a lightweigth markup 
language instead, like AsciiDoc and convert it to ODF when producing final 
output.

E.g. http://github.com/dagwieers/asciidoc-odf


Now that we have native (embedded) SVG support in 3.5, the toolchain 
becomes a lot more interesting, considering there are some nice 
ascii-to-image conversion plugins that create nice diagrams and charts 
from asciiart. So that changes to images become humanly parseable too ;-)

E.g. http://code.google.com/p/asciidoc-ditaa-filter/
     http://code.google.com/p/asciidoc-plantuml/
     http://code.google.com/p/asciidoc-aafigure-filter/
     http://volnitsky.com/project/mplw/
     http://code.google.com/p/asciidoc-mscgen-filter/
     http://powerman.name/asciidoc/


Also the way LibreOffice is naming styles by default is suboptimal, not 
using internal names but instead using the visible name and converting 
e.g. spaces to _20_. This will get you ugly names for:

        Heading 1       ->   Heading_20_1
        Text body       ->   Text_20_body

ODF does support internal names that are different than the visible 
representation so there's no need to retain the space in the internal 
name. Although I can see why it was implemented like this, I personally 
don't really like it. I wonder what other ODF producers do in this case 
though.

--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]