- From: Maxim Shemanarev <mcseem@antigrain.com>
- Date: Wed, 22 Jun 2005 20:47:30 -0400
- 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 UTC