Bug 61028 - Problems with OOXML custGeom and arcTo command
Summary: Problems with OOXML custGeom and arcTo command
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Drawing (show other bugs)
Version: 3.6.4.3 release
Hardware: All All
: low normal
Assignee: Not Assigned
QA Contact: Joel Madero
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-17 21:49 UTC by Regina Henschel
Modified: 2013-04-05 14:46 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Contains a custGeom with artTo command (14.03 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2013-02-17 21:49 UTC, Regina Henschel
Details

Description Regina Henschel 2013-02-17 21:49:11 UTC
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.
Comment 1 Joel Madero 2013-02-19 17:10:29 UTC
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)
Comment 2 Radek Doulik 2013-04-05 12:16:16 UTC
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.
Comment 3 Regina Henschel 2013-04-05 14:46:09 UTC
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.