W3C home > Mailing lists > Public > www-svg@w3.org > June 2005

Re: Markers and all

From: Maxim Shemanarev <mcseem@antigrain.com>
Date: Wed, 22 Jun 2005 20:47:30 -0400
Message-ID: <00ab01c5778d$23558b30$0202a8c0@mcseemxp1>
To: <www-svg@w3.org>

Hi Andreas,
Thank you for your message!

> as to problem 1:
> I would suggest that the user can decide whether he wants to inherit the
> marker color (usually the fill of the marker) from the stroke-color or
> not. I see use-cases for both, where the marker should inherit from the
> stroke-color and where the marker color should stay fixed, independent
> from the stroke-color. Both ways should be possible.

Well I think there should be two fundamentally different types of markers. 
The first type is drawn separately every time it appears. It allows us to 
have any kind of content, including images, patterns, etc. It's expensive 
and rarely used.
The second type just adds the aggregate marker path to the stroke, so that 
it can be drawn only with current properties of the stroke. So that, if the 
stroke has a gradient, the markers will also have the same gradient.

> as to problem 2:
> I can't comment much on this, since I am not an implementor. Maybe a
> flag would be allowed to render it with a global opacity (with good
> performance) (the default case) or with a separate opacity where the
> user deliberately accepts a decrease in performance.

It's actually up to the rendering agent. I personally would sacrifice the 
trenslucency of the markers at all. Of course, it will remain possible to 
draw a translucent stroke itself with  markers. What I'd like to avoid is 
image transformations to draw markers. I know what SVG people will say. They 
will say that "SVG does not specify the way of drawing markers". But in 
practice there must be restrictions. Otherwise the whole thing will be as 
useless as Adobe SVG. Theoretically it works, but in practice it fails to 
render even a 30MB SVG file. It consumes about 450MB of memory and takes an 
hour to render it on a typical P-IV 2GHz. There's nothing fancy in this 
file, just plenty of basic shapes and paths. My renderer takes 35 megs, 16 
seconds to parse and 3 seconds to render.

> as to problem 3:
> I don't agree here. middle markers are very useful and there are many
> use cases. In cartography, f.e. middle marker could represent the poles
> in a powerline signature or of cablecars. In diagrams/charts middle
> markers can represent data points that would otherwise not be visible
> because the angle differences are not good enough. In interactive SVG
> applications (e.g. digitizing, drawing app) middle markers can represent
> the handles of vertices.

Right, I see you are right. It's not that easy. But I was confused with the 
term "marker-mid". In my opinion there should be the following:
 - marker-start, marker-end - as is now,
 - marker-mid - drawn at the middle of each subpath (good for diagrams),
 - marker-vertex - drawn at each vertex (good for financial charts),
 - marker-dist - drawn along the path uniformly distributed (good for 
GIS/cartography).
In the last case the distance can be absolute or relative to the length of 
the path. I know you can use textPath, but it's a kind of a hack.

> as to problem 4:
> I agree with your comments here - this should be addressed.

It's done in vectorEffects in SVG 1.2 (how to shorten paths) but it's pretty 
tedious to apply for every path with markers. There must be a simpler way to 
do this. My suggestion is to add
shortenPathStart="nnn" and shortenPathEnd="nnn" to *markers*. It especially 
makes sense in combination with markerUnits="strokeWidth"

> I would very much like to see these marker issues addressed in SVG 1.2
> (or at least some of them).

Well, I'm afraid in SVG 1.2 it will be solved via vectorEffects which is not 
always desirable. There must be simple solutions that cover 99% of needs. 
vectorEffects are also expensive alas.

McSeem
http://antigrain.com
Received on Thursday, 23 June 2005 00:47:37 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT