Issue 123473 - The description of complex polygons should be rechecked
Summary: The description of complex polygons should be rechecked
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: 4.0.1
Hardware: All All
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2013-10-14 02:29 UTC by Zirneklitis
Modified: 2017-05-20 10:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Impress and Draw files as well as screen shots (206.07 KB, application/x-7z-compressed)
2013-10-14 02:29 UTC, Zirneklitis
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Zirneklitis 2013-10-14 02:29:38 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  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.
Comment 1 Armin Le Grand 2013-10-29 11:50:43 UTC
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' (, 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.
Comment 2 Zirneklitis 2013-10-29 12:44:50 UTC
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.
Comment 3 Armin Le Grand 2013-10-30 09:39:47 UTC
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...
Comment 4 Marcus 2017-05-20 10:45:04 UTC
Reset the assignee to the default "".