From: Rik Cabanier <cabanier@gmail.com>

Date: Sun, 13 May 2012 21:14:10 +0300

Message-ID: <CAGN7qDAdmviQiDFf8pAY4oMBWNACvYYK35s5uu1nbUfoGyA5iQ@mail.gmail.com>

To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>

Cc: public-fx@w3.org

Date: Sun, 13 May 2012 21:14:10 +0300

Message-ID: <CAGN7qDAdmviQiDFf8pAY4oMBWNACvYYK35s5uu1nbUfoGyA5iQ@mail.gmail.com>

To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>

Cc: public-fx@w3.org

> > > > > >But it would be mathematically correct though. > >When you skew to 90 degrees, the shape's length becomes infinite. So: area > >divided by infinity becomes 0 > > Mathematically you have to determine the limes to infinite skewing/ 90 deg. > If for all 'finite skews' the fill area is constant, it will be the same > for > infinity as well. > I agree that there is a difference in appearing to disappear and adding code to make it so. > But of course presumable the part remaining in the viewport can > become effectively 0, but it still can have a 1D-structure as > border/stroke, > that can be asumed to be present for nonscaling-stroke. > You're correct. I assumed that a non-scaling stroke still was skewed. Reading the spec [1], I agree that it is not skewed so it should be a stroked infinite line. However, if the non-scaling stroke follows the steps listed in the spec, it will still disappear: The resulting outline is transformed back to the user coordinate system<http://www.w3.org/TR/SVGTiny12/intro.html#TermUserCoordinateSystem> The spec is unclear here. I *think* it implies that the shape transformed back by applying the inverse of the CTM and attaching the CTM hence still disappearing. Instead, the CTM should be attached to the paint of the stroke and then fill is called. Alternatively the shape is drawn in host ctm, then the original CTM set followed by calling fill. > Obviously it is always possible, to define specific rules for > specific angles, for example no rendering, if angle in degrees > is divisible by 9 - but does it really help authors, really wanting > to use a combination of nonscaling-stroke and skewing? > And of course angles like 90 deg for skewing is less a problem > than transforms with non-invertable matrices (determinant 0) - > because authors should expect trouble here, if they do not > avoid such skewing angles ;o) This is one of the reasons I don't like skew. Spec that have discontinuities (flickering/going to infinity) are broken. > Admittedly it is difficult to deal > with infinity numerically - therefore some more mathematical > exploration of the problem and resulting hints for implementors > are a good idea here. At least, the problems I have already seen > (funny dancing shapes) in current SVG implementations seem to > be related to rounding problems or the limited internal number > range, therefore just to move out 90 deg may not solve all practical > implementation problems here anyway. This is something that will improve as browsers get more better graphics engines which is definitely happening. > Infinity is a nasty thing, > not only for computers. Too bad it's too late to get rid of skew... [1] http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStrokeReceived on Sunday, 13 May 2012 18:14:40 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:57:11 UTC
*