Difficulties with Flat XML under source control

Johannes Sixt j6t at kdbg.org
Tue Jun 19 10:56:08 PDT 2012


Michael,

thanks for your feedback!

Am 19.06.2012 10:48, schrieb Michael Meeks:
> On Sun, 2012-06-17 at 22:10 +0200, Johannes Sixt wrote:
>> I'm writing a small tool that transforms the XML into a canonical format
>> so that only substantial changes remain. The question is: Which
>> transformations are allowed?
> 
> 	Oh - so ... why write an external tool to do this, and not just fix it
> in LibreOffice ! ? :-)

Because I'm using git, and then it's just a matter of a "simple" 'clean
filter'. :-)

>> - <office:meta> changes. It's not a problem, I don't care about this.
> 
> 	Some level of sorting here might help too.

Not only that. Most of the stuff is irrelevant (diverse counts, editing
duration, time of last edit). That should just be removed if the
document is placed under source control. Such stuff leads to merge
conflicts almost by definition.

(And, BTW, to be able to keep different modifications of the manual in
different branches and *merge* them again is the whole point of this
excercise.)

>> - <office:settings> changes. I don't know, yet, whether I mind or not.

I'll try removing this entire section and hope that LO does something
sensible.

>> - The <text:list xml:id="list533178598"> changes. That xml:id does not
>> seem to be used anywhere. Can I just remove it? What will I lose?
> 
> 	No idea; if it's unused just try removing it and see what happens.

The ids are sometimes used in a text:continue-list attribute. Hence,
they can't be stripped out blindly.

>> - Measurements change. E.g. (just to pick one case), in
>> <style:graphic-properties> the draw:visible-area-width changes from
>> 6.088cm to 6.089cm. Is there a remedy to avoid changes of this kind?
> 
> 	Ah; nasty, some rounding problem / internal representation issue -
> possibly again looking at the code we could do better here to make it
> more predictable; possibly using more precision we could do better
> (doubles instead of floats) ?

Probably. Looking at this again, these changes seem to happen only for
draw:visible-area-*. Hence, it may also be a matter of conversion
between screen dimensions (pixels?) and cm/mm/in/etc.

> 	So - the best place to fix this stuff is inside LibreOffice itself :-)
> then it is permanently fixed for everyone: you are not the only problem
> with this pain - soon we'll be using flat odf for our templates and will
> suffer the same way :-) 
> 
> 	The code to poke at is in:
> 
> 	xmloff/
> and
> 	sw/source/filter/xml/

Been there, done that. But it's way over my head (and time budget). See

http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/23528/focus=23543

-- Hannes


More information about the LibreOffice mailing list