deformations pre and post RE: Rendering of non-uniform scaled diagonal lines
"David Dailey" <[email protected]> Mon, 7 Mar 2016 02:05:53 -0500
| Newsgroups | gmane.comp.web.svg |
|---|---|
| Message-ID | <00b201d1783f$ca791260$5f6b3720$@net> |
\ 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 <[email protected]> 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