OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi all, the command U (angle-ellipse) and T (angle-ellipseto) draw an elliptical arc from the ellipse defined by center (x y) and size (w,h), and start-angle t0 and end-angle t1. Example: <draw:custom-shape draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="6cm" svg:height="2cm" svg:x="6cm" svg:y="6.5cm"> <text:p/> <draw:enhanced-geometry svg:viewBox="0 0 6000 2000" draw:type="non-primitive" draw:enhanced-path="U 3000 1000 6000 2000 30 315 N"/> </draw:custom-shape> But the specification does not describe, how to calculate the start and end point. I have tested it with some applications and found, that actually two methods are used. (1) Used by LibreOffice 4.0 and PowerPoint 2013 Preview Draw an angle with the given value (here 30deg and 315deg). Calculate the intersection of the leg of the angle with the full ellipse (here center (3000 1000) and size (6000 2000)). (2) Used by Apache OpenOffice and Calligra Stage Draw an angle with the given value. Draw a circle from maximum radius. Intersect leg of the angle with the circle and remember the point. Scale the circle (and thereby transform the point) in height (or width) to fit the given ellipse. Take the transformed point as start or end point respectively. I have no proposal, because both methods are reasonable. The attached file "source.odp" contains the document itself. The attached file "Diagnose.odg" contains screenshots and additional lines, to determine how the start and end point is calculated. The screenshots show some additional problems: (A) The third and forth parameter are sometimes interpreted as radius, sometime as diameter. That is already tracked in https://tools.oasis-org/issues/browse/OFFICE-3711 (B) PowerPoint starts the angle not at the x-axis, but at the y-axis. That is a general problem of insufficient angle definitions in the specification. I think, the angle should start at the positive x-axis, when not explicitly something else is specified. (C) The applications agree in which direction they draw the arc. But it looks not like "clockwise", although "clockwise" is specified. (D) The applications agree use the angle direction as positive from positive x-axis to negative y-axis. That is against mathematical definition. Again a problem of insufficient angle definitions in the specification. I think, that B,C,D need a separate discussion. Kind regards Regina Attachment: source.odp Description: application/vnd.oasis.opendocument.presentation Attachment: Diagnose.odg Description: application/vnd.oasis.opendocument.graphics

Hi Regina, thanks for another detailed analysis here - you wrote: > But the specification does not describe, how to calculate the start > and end point. I have tested it with some applications and found, > that actually two methods are used. > > (1) Used by LibreOffice 4.0 and PowerPoint 2013 Preview > Draw an angle with the given value (here 30deg and 315deg). > Calculate the intersection of the leg of the angle with the full > ellipse (here center (3000 1000) and size (6000 2000)). > That at least appears to be the simplest interpretation. Also note that those enhanced paths are more-or-less a bijection of those binary ppt autoshape things (see also 20.1.9 in ISO 29500), and keeping that mapping lossless and/or preventing excessive recalculation seems desirable. > I have no proposal, because both methods are reasonable. > I wonder how wide-spread those commands are - where did you notice the difference, I presume there is a bug report somewhere? > (C) The applications agree in which direction they draw the arc. But > it looks not like "clockwise", although "clockwise" is specified. > That looks like an easy fix then. > (D) The applications agree use the angle direction as positive from > positive x-axis to negative y-axis. That is against mathematical > definition. Again a problem of insufficient angle definitions in the > specification. > Seems uncontroversial to fix, too? Kind regards, -- Thorsten Behrens SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Attachment: signature.asc Description: Digital signature

Hi Thorsten, Thorsten Behrens schrieb: Hi Regina, thanks for another detailed analysis here - you wrote: But the specification does not describe, how to calculate the start and end point. I have tested it with some applications and found, that actually two methods are used. (1) Used by LibreOffice 4.0 and PowerPoint 2013 Preview Draw an angle with the given value (here 30deg and 315deg). Calculate the intersection of the leg of the angle with the full ellipse (here center (3000 1000) and size (6000 2000)). That at least appears to be the simplest interpretation. Method (2) is simple too. Only my description was complicated :( Here a hopeful simpler one: Use a unit circle and intersect it with the leg of the angle (that's simple cos and sin) and then use a transformation matrix to fit the unit circle into the target rectangle area (that's a simple scale and translate). Method (2) is used for the primitive ellipse <draw:ellipse>. Also note that those enhanced paths are more-or-less a bijection of those binary ppt autoshape things (see also 20.1.9 in ISO 29500), and keeping that mapping lossless and/or preventing excessive recalculation seems desirable. As far as I know, neither the current import filter nor the predefined customshapes themselves in AOO use the commands U or T at all. The commands A,B,V,W are used, which do not define start and end by an angle but by points. I have no proposal, because both methods are reasonable. I wonder how wide-spread those commands are - where did you notice the difference, I presume there is a bug report somewhere? No bug report yet. There is no UI to define own custom shapes. But there might exist a shape collection, where the commands are used. I don't know, and considering millions of downloads, and the time, the custom shapes exist now, I will not estimate it. I examined draw:enhanced-path, when I prepared my talk about custom shapes for FOSDEM, but skipped all problems at that time. It was only when I have the custom-shapes now examined more closely, I noticed that the command U is rendered different in LO and AOO. Kind regards Regina