deformations pre and post RE: Rendering of non-uniform scaled diagonal lines

\

Tab
On Monday, March 07, 2016 1:30 AM
writing To: Jarek Foksa
and Cc-ing: Regina Henschel; and www-svg
concerning: Re: Rendering of non-uniform scaled diagonal lines

said something of the following sort..................

On Sun, Mar 6, 2016 at 10:32 AM, Jarek Foksa <jarek@boxy-svg.com> wrote:
> I can’t find the relevant section in the spec, but I would expect the stroke to be painted first, before applying group transforms, thus making the stroke look like a parallelogram.
>
> The spec defines <line> and <polyline> as "mathematically equivalent to a <path>”. I don't see any reason why they should be rendered differently than <path>.
>
> Chrome and the dev version of Inkscape seem to render this graphics correctly, I’m not sure about other apps.

Yup, the Chrome rendering (parallelograms when scaled non-uniformly) is correct.  Like filters, transforms are a post-painting operation (thus the stretching), and all shapes in SVG are just shorthands for some <path> (thus all the elements acting the same).

-------------

I've been thinking about these sorts of things recently and do wish that there were pre-rendered ways of dealing with feDisplacement. Specifically, if one applies a vector-based (let's say feTurbulence, either Perlin noise -- or something better -- which gives smooth chroma into an xy realm (like a polygon or a rect)), SVG filters would be more useful if the content being deformed were deformed as vectors rather than polygons. By this, I mean, if we applied the deformation to the coordinates that define a path rather than to the pixels of the path after rendering, it's a lot more consistent, semantically, with what an author intends.

Here's an example of what I mean: http://cs.sru.edu/~svg/Chapter05/G05xx48.svg
Regards
David

Received on Monday, 7 March 2016 07:06:44 UTC