2015-04-06 18:14 GMT+02:00 mathog <mathog@...1176...>:
Then any time a user's action working on the objects makes a change which should be reflected in the SVG, it should do (A) and then (B). From what you are saying, it is doing (B) (A) (B).
No. The problem is that you have absolutely no idea what to do in step A until you have done step B.
For instance, if you want to transform an object, you need to first compute its new coordinates. You can't do this given only the unparsed XML.
The XML tree essentially stores text. The DOM tree stores the 'interpretation' of this text, e.g. coordinates of the object as doubles, path data, color values, and so on. To determine what to write in the XML as text, you first have to compute the new 'interpretation', i.e. coordinates of the transformed object, and then construct new XML from that. Reading back from XML is thus always redundant, as long as serialization to XML is not accidentally asymmetric, i.e. the function that reads and interprets XML will not give exactly the same DOM object as the one that generated that XML.
Therefore, the way to go would be to have the development version always do readback, while the release version would just assume it wrote the correct data.
Big red flag. Any time the release acts differently than the development you open the door for release bugs which cannot be reproduced in the development. In my experience this can be something as minor as changing the optimization level, which often exposes/hides memory corruption bugs.
Then perhaps we should use unit tests to verify that the serialization of objects to XML is correct, instead of making the versions behave differently.
That goes back to the SVG -> Object conversion. The one that counts is the value that is held in the SVG, and I believe that precision is set by that standard. That said, given the amount of memory in most computers these days, there isn't much reason to use single precision in favor of double precision.
SVG does not specify what should be the binary precision of numeric values in the user agent once they are parsed. It only specifies the textual format of numbers.
Currently Inkscape limits output to a specific number of decimal digits, and the default number of digits does not capture the full precision of doubles. What I propose is to use a library (double-conversion) that generates the shortest possible string that parses back to the same double value. This would allow us to avoid writing many unnecessary digits and guarantee perfect roundtrip between doubles and XML.
Regards, Krzysztof