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

Re: Markers and all

From: Andreas Neumann <neumann@karto.baug.ethz.ch>
Date: Mon, 27 Jun 2005 09:06:43 +0200
Message-ID: <42BFA583.2000802@karto.baug.ethz.ch>
To: www-svg@w3.org


> 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.


yes, two different types of markers makes sense to me. I don't if it it 
would be rarely used, though. People use existing features for things 
that the implementor probably never thought about ... but you are right, 
the other type where the marker inherits fill and stroke properties, 
might be more common. However, in many cases the user might only want to 
inherit stroke or fill color and set the other one to fixed. For 
example, a circle marker should have a constant white fill, but the 
stroke of the circle should inherit the color of the stroke-color of the 
parent line.

> 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.
>
I agree that in many cases speed is more important than supporting 
exotic features. But to find the right balance is not always easy. As I 
am not an implementor of a rendering engine, I don't really know which 
cases are really computing expensive and which not.

>> 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.
>
it is probably hard to change existing SVG features, as they are already 
in use. One could call it marker-segmentmid or segmid. Sure, 
marker-vertex would make more sense in that light for marker-mid.

I agree that marker-dist would a useful additional marker feature. 
Currently we use text on a path, but thats probably slower and more 
complex to use than having a marker-dist feature.

Andreas


-- 
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093  Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
Received on Monday, 27 June 2005 07:06:51 GMT

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