Re: [css3-transforms] scale 0 on non-scaling strokes

>
>
> >
> >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#NonScalingStroke