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, 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
Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]
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 :-) All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]
Hello Niko, 2012/1/23 Niko Rönkkö : >> Only one query; I wonder whether we should be using the flat (fods) >> file-type for these tests - so we can read meaningful diffs to them in >> the git history. > > > +1 for this... > ... and I also think that all ODF files in git repos should be in Flat > ODFormat so that the Git can track them easily. > This makes only sense for the subsequenttest files. For all other files we want to test the normal filters directly, e.g. sc's filters-test with sc/qa/unit/data. I have been working a bit on the flat odf support in the c++ based subsequenttests but I still miss at leat one dependency and at the moment I have no idea which one. If you want to play a bit with it you can run it in gdb and chech where the exception in Desktop::loadComponentFromURl is coming from. Then you need to follow this path a bit until you reache a point where a uno factory call failed and returnend an empty uno interface. If it makes sense at all( see michael's comment) can only be checked after it works. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]
On 23/01/12 15:20, Niko Rönkkö wrote: >> Only one query; I wonder whether we should be using the flat (fods) >> file-type for these tests - so we can read meaningful diffs to them in >> the git history. > > +1 for this... > and I also think that all ODF files in git repos should be in Flat > ODFormat so that the Git can track them easily. 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, which results in huge spurious diffs... (at least for Writer) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Flat ODF usage in Git [Was: concept for c++ based subsequenttests]
Only one query; I wonder whether we should be using the flat (fods) file-type for these tests - so we can read meaningful diffs to them in the git history. +1 for this... ... and I also think that all ODF files in git repos should be in Flat ODFormat so that the Git can track them easily. Just my 2 snt's. -- RN ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
