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:linearGradient draw:name="gradient1" svg:spreadMethod="pad" >> svg:x1="65.9558%" svg:x2="39.8039%" svg:y1="24.8957%" svg:y2="70.0815%"> >> <svg:stop svg:offset="0.11" svg:stop-color="#dc143c"/><svg:stop >> svg:offset="0.473324" svg:stop-color="#00ced1"/><svg:stop >> svg:offset="0.589196" svg:stop-color="#00ff00"/> >> </svg:linearGradient> >> <svg:linearGradient draw:name="gradient2" svg:spreadMethod="pad" >> svg:x1="0%" svg:x2="166.923%" svg:y1="0%" svg:y2="164.085%"> >> <svg:stop svg:offset="0" svg:stop-color="#ffffff"/><svg:stop >> svg:offset="1" svg:stop-color="#00ff00"/> >> </svg:linearGradient> 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 <draw:gradient> are both present, the new element pre-empts > <draw:gradient> in ODF 1.3 and beyond. This way, a down-level implementation > will presumably process the <draw:gradient> 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-...@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? > > [ ... ] > > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
