Apache OpenOffice (AOO) Bugzilla – Issue 123473
The description of complex polygons should be rechecked
Last modified: 2017-05-20 10:45:04 UTC
Created attachment 81759 [details] Impress and Draw files as well as screen shots No sure is there a bug in the AOO. Complex polygons (e.g. polygon with a hole) created with the AOO Impress (or Draw) are displaced in LibreOffice Impress (or Draw) and Microsoft PowerPoint 2007. At the same time OpenOffice.org 3.2.1 opens the created files without distortions. Impress and Draw files as well as screen shots are attached as an archive. See “about.txt” for more details.
ALG: The problem is an old error in the usage of svg:d in ODF files; the svg:d defines that for using relative coordinates, the ' the next subpath starts at the same initial point as the current subpath' (http://www.w3.org/TR/SVG/paths.html#PathElement, 8.3.3 The "closepath" command). The ODF implementation uses the last point as current point for the next sub-path. This is wrong, but correcting this leads to make all existing ODF files being incompatible. Others have choosen to do so, we did not. There was a lot of discussion and there are two sides: (a) To not make all existing ODF files invalid, keep the error and define that svg:d usage in ODF XML is a little bit 'special' in this point (b) Change it to pure svg:d and risk that all ever existing ODF files may get read with errors The discussion had strong arguments for both sides, thus AOO kept the 'error' for now. Problem is that there is no easy way to detect inside the ODF if an svg:d is written with or without that error, thus no hints for correcting this at load time. I am working on some changes, e.g. starting svg:d sub-pathes always with an absolute moveto ('M' instead of 'm'); these will be loaded the same in all offices. The default import from ODF will have to keep that error, else all existing ODF files are on risk. HTH!
Taking in account that a lot of ODF users are using LibreOffice (as default office package for most of Linux distributions) and there are MSOffice 2007/2010/2013 users out there , this lead to serious incompatibility issues.
ALG: Well, not serious, you need to draw a PolyPolygon by hand, rarely done by users. But asides frm that, yes, that's the reason we kept it at AOO with some paradigm like 'svg:d in AOO is like standard AOO, but behaves different in this single point'. I think that's better than to break potentially all existing ODFs. Besides that, I just did task 123433 (see there). There *is* a way to save regular svg:d so that it can be read independent from that error: Just write a 'M' instead of a 'm' in export. This should ensure that AOO derivatives can read the geometry without problems, so exchange in that direction is ensured. To ensure in the other direction would require that these others do the same...
Reset the assignee to the default "issues@openoffice.apache.org".