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

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to