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

[Dag Wieers]

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 at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

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