| Summary: | Problems with OOXML custGeom and arcTo command | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Regina Henschel <rb.henschel> |
| Component: | Drawing | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | Joel Madero <jmadero.dev> |
| Severity: | normal | ||
| Priority: | low | CC: | jmadero.dev |
| Version: | 3.6.4.3 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Contains a custGeom with artTo command | ||
I was able to verify on: Version 3.6.4.3 (Build ID: 2ef5aff) using Bodhi Linux 2.2.0 Because of this I am updating the version field to reflect the oldest version that the bug has been seen on. Marking as: New (confirmed) Normal (can prevent high quality work given certain circumstances) Low (seems to be quite a chore to reproduce, basically you need to do save as multiple times to get the problem) Loads OK in master, where we handle the G command OK. I cannot use the T command, because it doesn't cover all the functionality of drawingml arcTo command. So if I understand it correctly, the document was saved with newer LO which supports already G command and loaded in older LO it doesn't look the same (because it uses draw:enhanced-path which is there to not break older versions with unknown commands) That is expected behavior, in current version it should survive save/load cycle. Which functionality is not supported by current ODF1.2? I'm alarmed, when something is introduced, that breaks interoperability. Besides my principal concerns about the command G, some comments: Save to .odp and reload is OK now with daily 4.Apr. Save to .pptx is still broken, reload results in a rectangle. Saved .odp file fails validation with Office-o-tron Validator. The part without drawooo, should give a solution that is at least so good as the .odp export of PowerPoint. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 75011 [details] Contains a custGeom with artTo command Open attached document. It contains the following OOXML custGeom: <p:spPr> <a:xfrm> <a:off x="1080000" y="720000" /> <a:ext cx="2160000" cy="2160000" /> </a:xfrm> <a:custGeom> <a:pathLst> <a:path w="6" h="6"> <a:moveTo> <a:pt x="3" y="3" /> </a:moveTo> <a:arcTo hR="3" wR="3" stAng="1800000" swAng="2700000" /> <a:close /> </a:path> </a:pathLst> </a:custGeom> <a:ln> <a:solidFill> <a:srgbClr val="FF0000" /> </a:solidFill> </a:ln> </p:spPr> LO shows the correct shape, a circle segment. Now use "save as" and save it to .pptx format. Open the resulting file in PowerPoint or in LO. Notice, you get a square. Open attached document again. Now use "save as" and save it to .odp format. Open the resulting file in PowerPoint2013 or in LO. Notice, the shape still exists, but the path is lost. LO produces in .odp the element <draw:enhanced-geometry draw:mirror-horizontal="false" draw:mirror-vertical="false" svg:viewBox="0 0 0 0" draw:type="ooxml-non-primitive" draw:enhanced-path="M 3 3 Z N" drawooo:enhanced-path="M 3 3 G 3 3 ?f0 ?f1 Z N"> It contains an attribute with an own namespace, but LO cannot read correctly, what it has written. I wonder, why a way with own namespace was used. I have expected an enhanced path with T command.