Definition of draw:angle in ODF1.2 does not fit to implementation
Hi all, I want to suggest OASIS to change the definition of draw:angle. The draft mail follows below. What do you think about it? Kind regards Regina Draft of the mail to OASIS: For type 'Linear' section 19.218 defines "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." It actually means, that in the internal coordinate system (that with an upright y-axis), rotating this y-axis clockwise with the draw:angle gives the gradient vector. section 19.122 repeats this in a less exact form. For the angle itself it specifies: "The draw:angle attribute has the data type angle 18.3.1." And in section 18.3.1 you read, "An angle, as defined in §4.1 of [SVG]. An angle is a double value that may be followed immediately by one of the following angle unit identifiers: deg (degrees), grad (gradiants) or rad (radians). If no unit identifier is specified, the value is assumed to be in degrees." But that is wrong for the implementations in Apache OpenOffice, LibreOffice, and Microsoft Office. All of them allow in draw:angle only integers without unit and interpret them as 0.1deg. Calligra does not use draw:gradient but uses svg:gradient. Microsoft Office can read negative integers, but writes itself always non negative integers. Apache OpenOffice and LibreOffice read and write only non negative integers. Therefore I suggest to alter the definition of draw:angle in this way: Instead of the sentence "The draw:angle attribute has the data type angle 18.3.1." use the text "The draw:angle attribute has the date type integer. A value of n is interpreted as n*0.1 degrees."
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi Regina, On 30.07.2012 18:34, Regina Henschel wrote: Hi all, I want to suggest OASIS to change the definition of draw:angle. The draft mail follows below. What do you think about it? Kind regards Regina Draft of the mail to OASIS: For type 'Linear' section 19.218 defines "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." It actually means, that in the internal coordinate system (that with an upright y-axis), rotating this y-axis clockwise with the draw:angle gives the gradient vector. section 19.122 repeats this in a less exact form. For the angle itself it specifies: "The draw:angle attribute has the data type angle 18.3.1." And in section 18.3.1 you read, "An angle, as defined in §4.1 of [SVG]. An angle is a double value that may be followed immediately by one of the following angle unit identifiers: deg (degrees), grad (gradiants) or rad (radians). If no unit identifier is specified, the value is assumed to be in degrees." But that is wrong for the implementations in Apache OpenOffice, LibreOffice, and Microsoft Office. All of them allow in draw:angle only integers without unit and interpret them as 0.1deg. Calligra does not use draw:gradient but uses svg:gradient. Microsoft Office can read negative integers, but writes itself always non negative integers. Apache OpenOffice and LibreOffice read and write only non negative integers. Therefore I suggest to alter the definition of draw:angle in this way: Instead of the sentence "The draw:angle attribute has the data type angle 18.3.1." use the text "The draw:angle attribute has the date type integer. A value of n is interpreted as n*0.1 degrees." Sorry, I would not do that. This would limit the possible precision without needs in a format definition. If the precision in the cores is limited or not does not play a role for the definition (it will increase, we are on it). I would rather suggest to go with the SVG definition and propose that. It's always good to get closer to other graphic standards. It also needs to be evaluated to which orientation "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." leads. What does this mean? The Y-Axis goes down (X to the right), thus the correct mathematical orientation would go anti-clockwise, starting at 0.0 on the Y-Axis which is below the origin. It may be wrong, the same as the current object rotation (and shear) is wrong in this aspect, see our current UI and what it does for a 5 degree object rotation (and would need to be proposed to be changed, too). Thus, when we are at it, we may need to correct the orientation of draw:angle, too. BTW: It is correct in the MS UI and their core data. Do the same 5 degree rotation there. I am currently not sure where draw:angle is used, is it the object rotation or the gradient rotation, or is it used for both? If used for both, I would not want precision to be limited to 0.1 degrees for objects. I would evtl. accept this for gradients. If it is used for both, we should think about the orientation (also for shear)... Sincerely, Armin -- ALG
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
On 30.07.2012 19:14, Armin Le Grand wrote: Hi Regina, On 30.07.2012 18:34, Regina Henschel wrote: Hi all, I want to suggest OASIS to change the definition of draw:angle. The draft mail follows below. What do you think about it? Kind regards Regina Draft of the mail to OASIS: For type 'Linear' section 19.218 defines "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." It actually means, that in the internal coordinate system (that with an upright y-axis), rotating this y-axis clockwise with the draw:angle gives the gradient vector. section 19.122 repeats this in a less exact form. For the angle itself it specifies: "The draw:angle attribute has the data type angle 18.3.1." And in section 18.3.1 you read, "An angle, as defined in §4.1 of [SVG]. An angle is a double value that may be followed immediately by one of the following angle unit identifiers: deg (degrees), grad (gradiants) or rad (radians). If no unit identifier is specified, the value is assumed to be in degrees." But that is wrong for the implementations in Apache OpenOffice, LibreOffice, and Microsoft Office. All of them allow in draw:angle only integers without unit and interpret them as 0.1deg. Calligra does not use draw:gradient but uses svg:gradient. Microsoft Office can read negative integers, but writes itself always non negative integers. Apache OpenOffice and LibreOffice read and write only non negative integers. Therefore I suggest to alter the definition of draw:angle in this way: Instead of the sentence "The draw:angle attribute has the data type angle 18.3.1." use the text "The draw:angle attribute has the date type integer. A value of n is interpreted as n*0.1 degrees." Sorry, I would not do that. This would limit the possible precision without needs in a format definition. If the precision in the cores is limited or not does not play a role for the definition (it will increase, we are on it). I would rather suggest to go with the SVG definition and propose that. It's always good to get closer to other graphic standards. It also needs to be evaluated to which orientation "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." leads. What does this mean? The Y-Axis goes down (X to the right), thus the correct mathematical orientation would go anti-clockwise, starting at 0.0 on the Y-Axis which is below the origin. It may be wrong, the same as the current object rotation (and shear) is wrong in this aspect, see our current UI and what it does for a 5 degree object rotation (and would need to be proposed to be changed, too). Argh, mixed things up. Y-Axis down, X to the right, the correct mathematical orientation would be clockwise starting at (1.0, 0.0) on the X-Axis, right of the center. Sorry for mixing things up. Fact is that we currently use the wrong orinetation in our Core, UI and file format, though. Make the experiment with a object, rotate it by 5 degrees, do the same in MS. Thus, when we are at it, we may need to correct the orientation of draw:angle, too. BTW: It is correct in the MS UI and their core data. Do the same 5 degree rotation there. I am currently not sure where draw:angle is used, is it the object rotation or the gradient rotation, or is it used for both? If used for both, I would not want precision to be limited to 0.1 degrees for objects. I would evtl. accept this for gradients. If it is used for both, we should think about the orientation (also for shear)... Sincerely, Armin -- ALG
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
[restoring Cc to libreoffice dev list] > >"The draw:angle attribute has the date type integer. A value of n is > >interpreted as n*0.1 degrees." > > Sorry, I would not do that. This would limit the possible precision > without needs in a format definition. > Tend to agree. Keep the double type, but define a unitless value as being n*0.1 degrees? That's backwards-compatible & future-proof. Cheers, -- Thorsten pgpIACNEgcSeo.pgp Description: PGP signature
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi Armin, Armin Le Grand schrieb: On 30.07.2012 19:14, Armin Le Grand wrote: Hi Regina, On 30.07.2012 18:34, Regina Henschel wrote: Hi all, I want to suggest OASIS to change the definition of draw:angle. The draft mail follows below. What do you think about it? Kind regards Regina Draft of the mail to OASIS: For type 'Linear' section 19.218 defines "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." It actually means, that in the internal coordinate system (that with an upright y-axis), rotating this y-axis clockwise with the draw:angle gives the gradient vector. section 19.122 repeats this in a less exact form. For the angle itself it specifies: "The draw:angle attribute has the data type angle 18.3.1." And in section 18.3.1 you read, "An angle, as defined in §4.1 of [SVG]. An angle is a double value that may be followed immediately by one of the following angle unit identifiers: deg (degrees), grad (gradiants) or rad (radians). If no unit identifier is specified, the value is assumed to be in degrees." But that is wrong for the implementations in Apache OpenOffice, LibreOffice, and Microsoft Office. All of them allow in draw:angle only integers without unit and interpret them as 0.1deg. Calligra does not use draw:gradient but uses svg:gradient. Microsoft Office can read negative integers, but writes itself always non negative integers. Apache OpenOffice and LibreOffice read and write only non negative integers. Therefore I suggest to alter the definition of draw:angle in this way: Instead of the sentence "The draw:angle attribute has the data type angle 18.3.1." use the text "The draw:angle attribute has the date type integer. A value of n is interpreted as n*0.1 degrees." Sorry, I would not do that. This would limit the possible precision without needs in a format definition. If the precision in the cores is limited or not does not play a role for the definition (it will increase, we are on it). Using decimals or using units will be an incompatible change. Neither of AOO, LO or MSO accept decimals or units. But the real problem is not the type, but the fact, that currently a stored value of 300 is interpreted as 30deg which is different from the spec. I would rather suggest to go with the SVG definition and propose that. It's always good to get closer to other graphic standards. In general I would say yes. But wouldn't it better to leave draw:gradient in our implementation as it is and implement for double precision and for all the other nice features like multiple stop colors svg:linearGradient and svg:radialGradient ? Those are already in the spec. It also needs to be evaluated to which orientation "The axis of the gradient is specified with the draw:angle attribute clockwise to the vertical axis." leads. What does this mean? Yes, that could be more precise. A picture with example would make it clear. Therefore I described in "It actually means, that in the internal..." how it is actually handled in all three AOO, LO, and MSO. The Y-Axis goes down (X to the right), thus the correct mathematical orientation would go anti-clockwise, starting at 0.0 on the Y-Axis which is below the origin. It may be wrong, the same as the current object rotation (and shear) is wrong in this aspect, see our current UI and what it does for a 5 degree object rotation (and would need to be proposed to be changed, too). Argh, mixed things up. Y-Axis down, X to the right, the correct mathematical orientation would be clockwise starting at (1.0, 0.0) on the X-Axis, right of the center. Sorry for mixing things up. Fact is that we currently use the wrong orinetation in our Core, UI and file format, though. Make the experiment with a object, rotate it by 5 degrees, do the same in MS. Again, that would only become precise in the spec with a picture with coordinate system and marked oriented angle. My proposal is not about all angles, but only for this special angle. Thus, when we are at it, we may need to correct the orientation of draw:angle, too. BTW: It is correct in the MS UI and their core data. Do the same 5 degree rotation there. I have not looked, what MS does in their own format, but for a discussion at LO I have looked how they read and write ODF. PowerPoint2013 does it this way: The angle of 0° in the UI means that the gradient vector goes from left to right in UI. The angle in the UI rotates this gradient vector clockwise on screen. Values from 0 to 359.9 are allowed. In file format it is the same as from LO (and AOO), for example: draw:angle="700" results from PP UI-angle=20° clockwise on screen LO UI-angle=70° counterclockwise on screen draw:angle="3300" results form PP UI-angle=120° clockwise on screen LO UI-angle=330° counterclockwise on screen I am currently not sure where draw:angle is used, is it the object rotation or the gradient rotation, or is it used for both? If used for bot
RE: Definition of draw:angle in ODF1.2 does not fit to implementation
There appear to be three considerations: 1. What is type and unit of draw:angle in the element? In ODF 1.0, ODF 1.1, and ISO/IEC 26300:2006 (now aligned with ODF 1.1), the type is integer and there is no explanation of the scale of the unit. ODF 1.2 gives special attention to the integer case and observes that the unitless integer is all that works for down-level compatibility with ODF 1.1 consumers. If it is to be decreed that all/most implementations are correct and the specification has been left incorrect since 2005, that is a very difficult situation. I assume the correct statement is that the unit for draw:angle is 0.1 degree. 2. Orientation? The orientation leaves much to be described, since it is a vector that is rotated, not an axis. It appears that practice and what little is said in the specifications satisfy standard geometric practice, as follows: a. Consider a vector that lies along the X axis with orientation in the positive-X direction. b. A positive rotation of that vector by 90 degrees will place the vector along the Y axis with the positive-X points now at the same positions on the positive-Y axis, etc. The draw-angle will be 90 degrees (however expressed). c. More generally, the angle is that of the positive-gradient vector (from the origin) with the positive-X vector (from the origin), as measured from the positive-X vector rotating toward (and through, if necessary) the positive-Y vector direction. (This is anti-clockwise in the standard geometric orientation. When projected onto the page, this appears to be clockwise because the origin tends to be in the upper left corner and the positive-Y direction is downward, the positve-X direction is rightward.) I suspect this can be clarified easily in all of ODF 1.0 through ODF 1.2, since there seems to be no conflict with implementations. Conversions to and from other formats need to be attentive to any difference in the reference orientation of axes and definition of the angle. 3. Non-Integer Types and Values? Allowing fractional values and units in draw:angle seems to be problematic and it does not directly deal with the integer type expression of 0.1-degree intervals. I agree that should be done by switching to SVG cases when available (and there should be more alignment of that in ODF 1.3). This means that draw:angle should probably continue to be expressed in plain integers with a clarification that the unit is 0.1-degrees. That would at least limit the damage of this persistent discrepancy between practice and the specification. - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Monday, July 30, 2012 11:29 To: ooo-dev@incubator.apache.org Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation [ ... ] Using decimals or using units will be an incompatible change. Neither of AOO, LO or MSO accept decimals or units. But the real problem is not the type, but the fact, that currently a stored value of 300 is interpreted as 30deg which is different from the spec. I would rather suggest to go with the SVG >> definition and propose that. It's always good to get closer to other >> graphic standards. In general I would say yes. But wouldn't it better to leave draw:gradient in our implementation as it is and implement for double precision and for all the other nice features like multiple stop colors svg:linearGradient and svg:radialGradient ? Those are already in the spec. >> >> It also needs to be evaluated to which orientation "The axis of >> the gradient is specified with the draw:angle attribute clockwise to the >> vertical axis." leads. What does this mean? Yes, that could be more precise. A picture with example would make it clear. Therefore I described in "It actually means, that in the internal..." how it is actually handled in all three AOO, LO, and MSO. >> >> The Y-Axis goes down (X to the right), thus the correct mathematical >> orientation would go anti-clockwise, starting at 0.0 on the Y-Axis which >> is below the origin. It may be wrong, the same as the current object >> rotation (and shear) is wrong in this aspect, see our current UI and >> what it does for a 5 degree object rotation (and would need to be >> proposed to be changed, too). > > Argh, mixed things up. Y-Axis down, X to the right, the correct > mathematical orientation would be clockwise starting at (1.0, 0.0) on > the X-Axis, right of the center. > Sorry for mixing things up. Fact is that we currently use the wrong > orinetation in our Core, UI and file format, though. Make the experiment > with a object, rotate it by 5 degrees, do the same in MS. Again, that would only become precise in the spec with a picture with coordinate system and marked oriented angle. My proposal is not about all angles, but only for this special angle. [ ... ]
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi Dennis, On 30.07.2012 22:21, Dennis E. Hamilton wrote: There appear to be three considerations: 1. What is type and unit of draw:angle in the element? In ODF 1.0, ODF 1.1, and ISO/IEC 26300:2006 (now aligned with ODF 1.1), the type is integer and there is no explanation of the scale of the unit. ODF 1.2 gives special attention to the integer case and observes that the unitless integer is all that works for down-level compatibility with ODF 1.1 consumers. If it is to be decreed that all/most implementations are correct and the specification has been left incorrect since 2005, that is a very difficult situation. I assume the correct statement is that the unit for draw:angle is 0.1 degree. 2. Orientation? The orientation leaves much to be described, since it is a vector that is rotated, not an axis. It appears that practice and what little is said in the specifications satisfy standard geometric practice, as follows: a. Consider a vector that lies along the X axis with orientation in the positive-X direction. b. A positive rotation of that vector by 90 degrees will place the vector along the Y axis with the positive-X points now at the same positions on the positive-Y axis, etc. The draw-angle will be 90 degrees (however expressed). c. More generally, the angle is that of the positive-gradient vector (from the origin) with the positive-X vector (from the origin), as measured from the positive-X vector rotating toward (and through, if necessary) the positive-Y vector direction. (This is anti-clockwise in the standard geometric orientation. When projected onto the page, this appears to be clockwise because the origin tends to be in the upper left corner and the positive-Y direction is downward, the positve-X direction is rightward.) It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it is mathematically wrong oriented (thus, projected on the page, anti-clockwise). Thus, when just want to stay compatible and extend/correct the definitions, defining it as integer, 0.1 degrees and mathematically (non-projected to page) clockwise rotation would describe the current behaviour. Unfortunately this 'wrong' orientation is problematic. As long as it is only locally used it can simply be mirrored. The problem comes up when working with transformations; when receiving the transformation of an graphic object and decomposing it to extract rotation, that rotation will be mathematically correctly oriented. It has to be since else linear combination of transformations would not work. This is not in the environment of gradients, but in general all angles in ODF have this problem (probably for historical reasons, the UIs use the same wrong orientation). Our competitor does not have that error. Isn't this correctable for all angles e.g. for ODF1.3 and can be handled by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3? I suspect this can be clarified easily in all of ODF 1.0 through ODF 1.2, since there seems to be no conflict with implementations. Conversions to and from other formats need to be attentive to any difference in the reference orientation of axes and definition of the angle. 3. Non-Integer Types and Values? Allowing fractional values and units in draw:angle seems to be problematic and it does not directly deal with the integer type expression of 0.1-degree intervals. I agree that should be done by switching to SVG cases when available (and there should be more alignment of that in ODF 1.3). This means that draw:angle should probably continue to be expressed in plain integers with a clarification that the unit is 0.1-degrees. That would at least limit the damage of this persistent discrepancy between practice and the specification. - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Monday, July 30, 2012 11:29 To: ooo-dev@incubator.apache.org Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation [ ... ] Using decimals or using units will be an incompatible change. Neither of AOO, LO or MSO accept decimals or units. But the real problem is not the type, but the fact, that currently a stored value of 300 is interpreted as 30deg which is different from the spec. I would rather suggest to go with the SVG definition and propose that. It's always good to get closer to other graphic standards. In general I would say yes. But wouldn't it better to leave draw:gradient in our implementation as it is and implement for double precision and for all the other nice features like multiple stop colors svg:linearGradient and svg:radialGradient ? Those are already in the spec. It also needs to be evaluated to which orientation "The axis of the gradient is specified with the draw:angle
RE: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi Armin, Thanks for your valuable comment. I had thought that the description using "clockwise" was in reference to the page appearance and not the abstract treatment (with "right-hand rule"). Perhaps I misunderstand where the origin is understood in the projection onto the page. MORE IMPORTANT CONCERN I think you raise a more important question concerning changing for ODF 1.3 and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF 1.3. I recommend that there be no breaking change of draw:angle between ODF versions. It is probably best to deprecate it while clarifying the orientation of the angle-opening rotation and the units of the angle. I think preventing down-level breakage is impossible without that and the support explanations will be a nightmare otherwise. It seems to me that the ODF 1.2 description is best corrected in an Errata and the problem made immediately known in an OIC Advisory. To correct the geometry for transformations, I suggest that another, rigorously-defined gradient element be introduced, preferably one from SVG. If there is a down-level concern, I would define the new element such that, when it and are both present, the new element pre-empts in ODF 1.3 and beyond. This way, a down-level implementation will presumably process the and ignore the element introduced in ODF 1.3, since it is not defined down-level. Would that break the knot better? - Dennis -Original Message- From: Armin Le Grand [mailto:armin.le.gr...@me.com] Sent: Wednesday, August 01, 2012 02:21 To: ooo-dev@incubator.apache.org Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation Hi Dennis, On 30.07.2012 22:21, Dennis E. Hamilton wrote: [ ... ] > (This is anti-clockwise in the standard geometric orientation. When > projected onto the page, this appears to be clockwise because the origin > tends to be in the upper left corner and the positive-Y direction is > downward, the positve-X direction is rightward.) It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it is mathematically wrong oriented (thus, projected on the page, anti-clockwise). Thus, when just want to stay compatible and extend/correct the definitions, defining it as integer, 0.1 degrees and mathematically (non-projected to page) clockwise rotation would describe the current behaviour. Unfortunately this 'wrong' orientation is problematic. As long as it is only locally used it can simply be mirrored. The problem comes up when working with transformations; when receiving the transformation of an graphic object and decomposing it to extract rotation, that rotation will be mathematically correctly oriented. It has to be since else linear combination of transformations would not work. This is not in the environment of gradients, but in general all angles in ODF have this problem (probably for historical reasons, the UIs use the same wrong orientation). Our competitor does not have that error. Isn't this correctable for all angles e.g. for ODF1.3 and can be handled by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3? [ ... ]
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
On 01/08/12 20:38, Dennis E. Hamilton wrote: > Hi Armin, > > Thanks for your valuable comment. > > I had thought that the description using "clockwise" was in reference to the > page appearance and not the abstract treatment (with "right-hand rule"). > Perhaps I misunderstand where the origin is understood in the projection onto > the page. > > MORE IMPORTANT CONCERN > > I think you raise a more important question concerning changing for ODF 1.3 > and understanding a transformation between ODF 1.0/1.1/1.2/IS 26300 and ODF > 1.3. > > I recommend that there be no breaking change of draw:angle between ODF > versions. It is probably best to deprecate it while clarifying the > orientation of the angle-opening rotation and the units of the angle. I > think preventing down-level breakage is impossible without that and the > support explanations will be a nightmare otherwise. It seems to me that the > ODF 1.2 description is best corrected in an Errata and the problem made > immediately known in an OIC Advisory. > > To correct the geometry for transformations, I suggest that another, > rigorously-defined gradient element be introduced, preferably one from SVG. there are already the svg:linearGradient and svg:radialGradient elements in ODF 1.2, for example playing with Calligra Stage 2.4.3 i was able to produce a ODF presentation document with this, which seems to do fine without any explicit angle at all: >> > svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%"> >>> svg:offset="0.473324" svg:stop-color="#00ced1"/>> svg:offset="0.589196" svg:stop-color="#00ff00"/> >> >> > svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%"> >>> svg:offset="1" svg:stop-color="#00ff00"/> >> unfortunately it seems that OOo derived suites only support the _other_ ODF specific gradient element(s) that have this draw:angle attribute. i don't actually know anything about graphics, so i'll let Armin judge whether that SVG stuff in ODF 1.2 is sufficient :) > If there is a down-level concern, I would define the new element such that, > when it and are both present, the new element pre-empts > in ODF 1.3 and beyond. This way, a down-level implementation > will presumably process the and ignore the element introduced > in ODF 1.3, since it is not defined down-level. > > Would that break the knot better? _if_ something new is needed in ODF then that would be my general approach as well: don't change semantics of existing markup in an incompatible way, but deprecate it and add new markup as necessary with improved semantics. the advantage is that existing products can then write both representations in a new version, and the deprecated markup can still be understood by older versions. > - Dennis > > -Original Message- > From: Armin Le Grand [mailto:armin.le.gr...@me.com] > Sent: Wednesday, August 01, 2012 02:21 > To: ooo-dev@incubator.apache.org > Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation > > Hi Dennis, > > On 30.07.2012 22:21, Dennis E. Hamilton wrote: > [ ... ] >> (This is anti-clockwise in the standard geometric orientation. When >> projected onto the page, this appears to be clockwise because the origin >> tends to be in the upper left corner and the positive-Y direction is >> downward, the positve-X direction is rightward.) > > It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it > is mathematically wrong oriented (thus, projected on the page, > anti-clockwise). > > Thus, when just want to stay compatible and extend/correct the > definitions, defining it as integer, 0.1 degrees and mathematically > (non-projected to page) clockwise rotation would describe the current > behaviour. > > Unfortunately this 'wrong' orientation is problematic. As long as it is > only locally used it can simply be mirrored. The problem comes up when > working with transformations; when receiving the transformation of an > graphic object and decomposing it to extract rotation, that rotation > will be mathematically correctly oriented. It has to be since else > linear combination of transformations would not work. > > This is not in the environment of gradients, but in general all angles > in ODF have this problem (probably for historical reasons, the UIs use > the same wrong orientation). Our competitor does not have that error. > > Isn't this correctable for all angles e.g. for ODF1.3 and can be handled > by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values > easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3? > > [ ... ] > >
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hello, On 01/08/12 22:16, Michael Stahl wrote: >>> >> svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%"> >>>>> svg:offset="0.473324" svg:stop-color="#00ced1"/>>> svg:offset="0.589196" svg:stop-color="#00ff00"/> >>> >>> >> svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%"> >>>>> svg:offset="1" svg:stop-color="#00ff00"/> >>> > > unfortunately it seems that OOo derived suites only support the _other_ > ODF specific gradient element(s) that have this draw:angle attribute. > > i don't actually know anything about graphics, so i'll let Armin judge > whether that SVG stuff in ODF 1.2 is sufficient :) There is a little tiny problem in there. The draw:gradient element is more verbose then the svg:*Gradient semantics. You can express square, elliptical, axial ... gradients that way. The down-side is that, due to the implementation in the time of the specification, this allows only bi-colour gradients. SVG on the other hand is much less expressive in what the "shape" of the gradient concerns, but it is allowing a multitude of stops with different colours. The svg:*Gradient semantics in the ODF specification is not exactly the corresponding to the SVG fully, but is only a subset of the features. The specification allows also only 2 colours per gradient. So first good thing would be to actually adopt the complete gradient semantics from SVG. This would not be a huge burden for the implementers I guess and would allow more complicated gradients then what we have currently. >> If there is a down-level concern, I would define the new element such that, >> when it and are both present, the new element pre-empts >> in ODF 1.3 and beyond. This way, a down-level >> implementation will presumably process the and ignore the >> element introduced in ODF 1.3, since it is not defined down-level. >> >> Would that break the knot better? > > _if_ something new is needed in ODF then that would be my general > approach as well: don't change semantics of existing markup in an > incompatible way, but deprecate it and add new markup as necessary with > improved semantics. > > the advantage is that existing products can then write both > representations in a new version, and the deprecated markup can still be > understood by older versions. Also, one could be pro-active and simply refer to SVG for this stuff. Since in SVG 2.0, there will be some more gradient types that would be nice to support if LO drawing application wants to look like a serious tool to the graphics folks. Cheers F.
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
d ignore the element introduced in ODF 1.3, since it is not defined down-level. We can use the SVG basic data type, no need for an own, new definition. Would that break the knot better? Yes, I think so. - Dennis -Original Message- From: Armin Le Grand [mailto:armin.le.gr...@me.com] Sent: Wednesday, August 01, 2012 02:21 To: ooo-dev@incubator.apache.org Subject: Re: Definition of draw:angle in ODF1.2 does not fit to implementation Hi Dennis, On 30.07.2012 22:21, Dennis E. Hamilton wrote: [ ... ] (This is anti-clockwise in the standard geometric orientation. When projected onto the page, this appears to be clockwise because the origin tends to be in the upper left corner and the positive-Y direction is downward, the positve-X direction is rightward.) It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it is mathematically wrong oriented (thus, projected on the page, anti-clockwise). Thus, when just want to stay compatible and extend/correct the definitions, defining it as integer, 0.1 degrees and mathematically (non-projected to page) clockwise rotation would describe the current behaviour. Unfortunately this 'wrong' orientation is problematic. As long as it is only locally used it can simply be mirrored. The problem comes up when working with transformations; when receiving the transformation of an graphic object and decomposing it to extract rotation, that rotation will be mathematically correctly oriented. It has to be since else linear combination of transformations would not work. This is not in the environment of gradients, but in general all angles in ODF have this problem (probably for historical reasons, the UIs use the same wrong orientation). Our competitor does not have that error. Isn't this correctable for all angles e.g. for ODF1.3 and can be handled by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3? [ ... ]
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
Hi all, Armin Le Grand schrieb: Hi Dennis (and others), [..] We should not mix up varios themes here (maybe I started doing so, I apologize). We have two things here: (a) Non-SVG Gradient definitions (old ones) (b) Angle definitions in various places There is no general problem with (a), except the contained angle and it's orientation. Thus I talk more about (b) where (b) is about the old gradients with use currently, but also start/end angles in circle/ellipse shapes. The Object rotation does not have a direct and single rotation attribute (AFAIK, there is svg:x, svg:y, svg:width/height, but no svg:angle), but has to use (and does use) a transformation when rotation is needed (which uses angles correctly, no problem there). Using a 2nd 'rigorously-defined' angle would be sufficient here. As mentioned in earlier mails, SVG has as basic data type (see SVG 4.2). It is already listed in ODF 1.2, see 18.3.1 of ODF spec (Does this mean it could already be used?). It is even referenced as data type in draw:angle, draw:start-angle and draw:end-angle (!), see e.g. 19.112 draw:angle in ODF1.2 which says: 'The draw:angle attribute has the data type angle 18.3.1'. When this would be true, draw:angle would not even be needed since it's identical to svg:angle already (which it is not, another error?). Thus I suggest allowing both in and , with --- is the inverted rotation in 10th of a degree as integer value (no longer reference 18.3.1 and say it's equal). I support the idea to define it directly for the 0.1 degree cases, independently of a reference. I'm not sure, whether "invert rotation" is really clear. Is it possible to add a picture to the spec? Then it would be possible to show the axis, the gradient vector and a concrete angle. is the rotation as defined by SVG (including being float and supporting deg, rad and grad). If is present, it has precedence over . For compatibility, please support both when creating ODF documents. --- I have searched in the spec where the data type angle is referenced. I add my findings here. All tests are only for AOO. Other candidates wit this problem are (not sure when marked with '?'): 19.140 draw:end-angle 19.213 draw:start-angle They are used with unit 1 degree. They use decimal values. The values in the UI are the same as in file format. A positive angle in file format is shown as counterclockwise on screen. 19.226 draw:text-rotate-angle (?) 20.95 draw:caption-angle (?) For both I don't know an object that uses it. How can I generate such an object? 20.339 style:rotation-angle (?) used for text direction of axis tick labels in charts. A positive value in file format is shown counterclockwise on screen. 20.375 style:text-rotation-angle (?) Used for character rotation 90° or 270°. I know no other use. (20.2) chart:angle-offset (used in Pie-chart) All three use unit 1 degree. style:text-rotation-angle has a constraint, that the value must be integer. 20.17 dr3d:end-angle (used in 3D rotation objects for not full rotation) 19.209 draw:rotation (used for hatches) 19.112 draw:angle (used for gradient and opacity) All three use unit 0.1 degree. The orientation of draw:rotation and draw:angle is counterclockwise on screen for a positive angle in file format. (19.161) draw:extrusion-rotation-angle (used for custom shapes in extruded state) (19.104) dr3d:shadow-slant (used for shadow of 3D-scene) Both use unit 1 degree. draw:extrusion-rotation-angle has no UI with direct input but uses buttons with 5 degree steps. [..] Kind regard Regina
Re: Definition of draw:angle in ODF1.2 does not fit to implementation
be needed > since it's identical to svg:angle already (which it is not, another error?). > > Thus I suggest allowing both in and , with > > --- > > is the inverted rotation in 10th of a degree as integer value > (no longer reference 18.3.1 and say it's equal). > > is the rotation as defined by SVG (including being float and > supporting deg, rad and grad). > > If is present, it has precedence over . For > compatibility, please support both when creating ODF documents. > > --- > > Other candidates wit this problem are (not sure when marked with '?'): > > 19.140 draw:end-angle > 19.213 draw:start-angle > > 19.226 draw:text-rotate-angle (?) > 20.95 draw:caption-angle (?) > 20.339 style:rotation-angle (?) > 20.375 style:text-rotation-angle (?) > > >> If there is a down-level concern, I would define the new element such >> that, when it and are both present, the new element >> pre-empts in ODF 1.3 and beyond. This way, a down-level >> implementation will presumably process the and ignore the >> element introduced in ODF 1.3, since it is not defined down-level. > > > We can use the SVG basic data type, no need for an own, new > definition. > > >> Would that break the knot better? > > > Yes, I think so. > >> - Dennis >> >> >> -Original Message- >> From: Armin Le Grand [mailto:armin.le.gr...@me.com] >> Sent: Wednesday, August 01, 2012 02:21 >> To: ooo-dev@incubator.apache.org >> Subject: Re: Definition of draw:angle in ODF1.2 does not fit to >> implementation >> >> Hi Dennis, >> >> On 30.07.2012 22:21, Dennis E. Hamilton wrote: >> [ ... ] >> >>> (This is anti-clockwise in the standard geometric orientation. When >>> projected onto the page, this appears to be clockwise because the origin >>> tends to be in the upper left corner and the positive-Y direction is >>> downward, the positve-X direction is rightward.) >> >> >> It is consistent throughout all AOO/LO/OOo versions. Unfortunately, it >> is mathematically wrong oriented (thus, projected on the page, >> anti-clockwise). >> >> Thus, when just want to stay compatible and extend/correct the >> definitions, defining it as integer, 0.1 degrees and mathematically >> (non-projected to page) clockwise rotation would describe the current >> behaviour. >> >> Unfortunately this 'wrong' orientation is problematic. As long as it is >> only locally used it can simply be mirrored. The problem comes up when >> working with transformations; when receiving the transformation of an >> graphic object and decomposing it to extract rotation, that rotation >> will be mathematically correctly oriented. It has to be since else >> linear combination of transformations would not work. >> >> This is not in the environment of gradients, but in general all angles >> in ODF have this problem (probably for historical reasons, the UIs use >> the same wrong orientation). Our competitor does not have that error. >> >> Isn't this correctable for all angles e.g. for ODF1.3 and can be handled >> by a XML transformation ODF1.2 <-> ODF1.3 by mirroring all angle values >> easily? If yes, Shouldn't we take the chance to clean this up in ODF1.3? >> >> [ ... ] >> >> >> > >
