- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 19 Mar 2015 10:17:50 -0700
- To: Jelle Mulder <jelle.mulder2@outlook.com>
- Cc: www-svg <www-svg@w3.org>
On Wed, Mar 18, 2015 at 10:19 PM, Jelle Mulder <jelle.mulder2@outlook.com> wrote: > Most Hatch patterns can easily be made using dash arrays with a line width > of 100%, can be made any angle and a cross hatch is just two lines of code. > There are obvious limits to this method as it cannot be used as a fill, but > you'd need to clip your pattern, making it a bit of a hassle. It does > however give vastly better results than using patterns and are easier to > read. I was wondering if the variant line width in SVG2 would also allow for > dash arrays using those. Note that I wasn't trying to ask for any new feature with my email. We *already have* the <hatch> element, which solves hatch patterns quite well. We don't need to worry about hacks involving super-fat dashed lines and clipping. > Come to think of it, some filter for stochastic patterning would be nice as > well. In combination with filters for color conversion (from sRGB to CMYK or > hexachrome for example, with color separation to get the right layer). I > guess you don't need to support that in the browser, but it would be nice to > have it defined in the standard for the non browser use cases that abound > for SVG and are so ill addressed. The current work arounds are a bit of a > pain, working with CMYK kind of cumbersome, but having some filter method > would allow for a wide variety of implementations. I can imagine stochastic > raster, color conversion, color separation with/without black overprint and > things like that. If you can hang some color profile into the filter using > the specs for an output device, that would probably save a lot of hassle for > the author and solve a few problems in the input and output work flow for > graphics designers. Yeah, there've been discussions about stochastic patterning before. That's obviously a separate topic. ^_^ > I understand that the limited view of the browser vendors in this group and > other industrial monopolist will have objections to such an idea, This is not true, useful, or kind. Please keep a professional tone on this mailing list. ~TJ
Received on Thursday, 19 March 2015 17:18:38 UTC