W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: vector effects

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 12 Nov 2004 23:52:04 +0000 (UTC)
To: Philippe Lhoste <PhiLho@GMX.net>
Cc: Andreas Neumann <neumann@karto.baug.ethz.ch>, www-svg@w3.org
Message-ID: <Pine.LNX.4.61.0411122332470.8631@dhalsim.dreamhost.com>

On Thu, 11 Nov 2004, Philippe Lhoste wrote:
> Ian Hickson wrote:
> > > set back means that a stroke is not stroked with a certain offset to 
> > > a vertex or end point. F.e. you could have a gap before drawing a 
> > > marker. I think, that's a very useful feature for high-quality 
> > > graphics
> > 
> > Oh, right. Why does this need to be supported explicitly? You can do 
> > it today just by having multiple lines, some of which are shorter than 
> > others. Sure, animating it requires more thought, but exactly how 
> > common is it that this will be animated?
> 
> Yes, why have markers, to start with? :-)
> Just compute, manually or with an authoring tool, where to put symbols 
> on the path, with correct rotation.

Indeed, if we were giving SVG 1.0 last call comments, I might well be 
suggesting that, or at least a massive simplification of the markers 
model. I started planning tests for that feature, and there are so many 
variables involved that the number of tests that would be needed to 
properly test the markers model numbered in the thousands.


> > How is this different from having a shape <use>d several times with 
> > different cascaded values for 'stroke' and 'fill' and different 
> > applied transforms? (I'm not saying it is, I'm just trying to 
> > understand exactly what the use case is here.)
> 
> This is probably seen as bad use, at least in the case of text: if you 
> repeat a text several times just to make an effect, it would hurt 
> accessibility.

It would be trivial for ATs to remark on the duplicate <use> and only show 
it once.


> > > I'm not denying tha there are use cases for the vector effects work. 
> > > All I'm saying is that to handle 90% of these use cases, it seems 
> > > like a significantly simpler model could be used, instead of 
> > > introducing something that, frankly, is frightening in its 
> > > complexity.
> > > 
> > > thats why it is not in the SVG basic profile, but in the full 
> > > profile. We, as the SVG users would already appreciate, if 
> > > Mozilla/Opera would implement at least the SVG Basic profile.
> > 
> > And once we've implemented the Basic profile, we will immediately 
> > receive requests to implement the Full profile.
> 
> Of course, but at least that would be a good starting point, consistent 
> and all. :-)

Right, but my point is at the end of the day, the full model is all that 
matters. So the full model shouldn't be so complicated that Web browser 
manufacturers don't want to do it.


> > There is only one profile that matters, and that's the whole thing. 
> > Anything that isn't implemented simply shouldn't be in the spec. If it 
> > isn't implemented, authors can't use it, and thus the spec is 
> > basically lying if it claims that the language has that feature.
> 
> The fact it cannot be implemented simply doesn't mean it won't be 
> implemented at all... Most of the spec. is probably already existing in 
> commercial vector drawing programs, so it is doable.

Commercial vector drawing programs are not the same thing as Web browsers. 
SVG is a W3C language, which means its primary use case is the Web.

There is commercial software available that does full 3D rendering of 
movie-quality scenes with accurate fur and water and so forth (such as 
Pixar's RenderMan). But that doesn't mean that Web browsers should support 
that. There are programs that do ultra-high quality professional 
typography, with hyphenation dictionaries, drop-cap alignment, etc, but 
that doesn't mean CSS has to do professional-level typography.

SVG doesn't have to be the high-end industry-standard vector graphics 
interchange language for the professional graphics artist. It has to be 
the Web vector format, optimised for easy implementation and ease of 
authoring, and integration into other Web languages. This is where I'm 
coming from as far as my comments go.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 November 2004 23:52:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC