W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-transforms] rendering of objects transformed with non-invertable matrix

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Mon, 23 Apr 2012 10:42:51 +0100
To: www-style@w3.org, public-fx@w3.org
Message-Id: <201204231142.51721.Dr.O.Hoffmann@gmx.de>
Dirk Schulze:

>
> SVG 2 will have the 'non-scaling-stroke' feature. And I am working on a
> possible issue with 'non-scaling-stroke' and 3D transforms [1].
>

fine.

> Anyway. How do you want to draw a figure on a singular matrix? 

Because SVG has only simple shapes (no really complex mathematical
shapes like fractals), the approach to find the right solution is simple
and always the same, a limes - you need this only theoretically, practically
you only have to apply the stroke to the remaining point (0D) or line (1D).
The alignment of the stroke of the point may depend on the shape and the
type of transformation - this needs to be checked. I think, stroked 1D 
residuals are less problematic than 0D, because they always have
an alignment itself in the 2D/3D world around it.

> You can't 
> draw the figure, so the value of 'vector-effect' doesn't matter at all:
>
> <svg xmlns="http://www.w3.org/2000/svg">
>   <rect width="100" height="100" vector-effect="non-scaling-stroke"
> transform="scale(0)" stroke-width="100" stroke="black" fill="none"/> </svg>

Well, here you can try to build the limes for scale(e), e -> 0 and because
the rectangle has no rounded corners you will end up with a square of with
the size and colour of the stroke (for rounded corners I did not check, if 
this results in differences - just do an animation with a proper browser to
get something like the limes and you will see, whether it matters or not).
Obviously in programs you may not want to calculate a limes - do you see
any numerical problems in getting the right result?


>
> In this example the transform of the rect has a singular matrix, caused by
> scaling by the factor of 0. Therefore the figure can't get painted at all.
> How can 'non-scaling-stroke' make a difference here? 

See above, the difference to scale(1e-10) will be typically minimal
on a viewBox with a size larger than for example 1.

> It doesn't even matter 
> if the ancestor node had this transform:
>
>
> <svg xmlns="http://www.w3.org/2000/svg">
>   <g  transform="scale(0)">
>     <rect width="100" height="100" vector-effect="non-scaling-stroke"
> stroke-width="100" stroke="black" fill="none"/> </g>
> </svg>
>


Note, that you may have similar problems with constrained
transformations. However, after I insisted, that such problems
may occur with non-invertable matrices, there was added some
text to SVG tiny 1.2 to avoid such situations.
Because non-scaling-stroke does not mention any inversions,
there was no need to mention such specific situations for the
vector-effect property, you only draw the stroke, whatever
remains from the shape - 1D or 0D.


> You can verify it in all current browsers with 'non-sclaing-stroke support'
> (Opera, Safari, Chrome) and Batik. At least from an implementation point of
> view you want the local to root transform to be invertible.

At least for Opera this is a well known bug (reported already in 2007,
bug-286641) - well for the others I did not test, because I assumed,
they do not yet care about SVG tiny 1.2 - maybe I should have a look
on Batik (but I think, it typically fails on SVG tiny 1.2 features,  therefore
I did no systematic tests).

Opera for example has many problems with stroke, wrong alignment
of the line-caps, problems with overlaps of strokes with a large width
compared to the characteristic size of the object, problems to render
small sized objects, if the characteristic size of the viewBox is small
as well - therefore no surprise, that non-sclaing-stroke is not 
carefully implemented as well ;o)
The SVG recommendations have a lot of undefined issues
concerning stroke properties (what is already mentioned in the
recommendations), therefore no surprise for low motivation to
get everything right with stroke ;o)
Therefore what is currently impelemented for stroke issues 
is not very reliable.

>
> Browsers use a different approach: quaternions [2]. 

If it avoids the problem, this sounds good ...

> I'll try to update this 
> paragraph in the next days. But even so, what do you want to draw on
> scale(0)?

See above, at least it is consistent with the current definition of 
non-sclaing-stroke and has non-trivial use cases, especially for
educational purposes and for example to check the quality of
some specific approximative spline animations - these are
only things, I usually care about, having not much to do with
non-sclaing-stroke - those authors, who really want to use
this feature for more obvious purposes may have more 
examples.


Olaf
Received on Monday, 23 April 2012 09:43:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:52 GMT