RE: Markers and all

Hi, Maxim, Andreas, et al-

First, Maxim, let me say that Andreas and I and others have been barking up
this tree for years, and I'm very glad to have your support, as an
implementor.

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

>From an API perspective, is is possible simply to have one type of marker,
that is treated differently by the renderer depending on the parameters
indicated? So, as a developer, you just use marker, but if the viewer sees
that it uses opacity or color inheritance, it adjusts accordingly. This
would not require a change in the Spec, per se, but ony in how that viewer
behaves.


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

Sounds nice. :) Still, if there's some way to use behavior as I mentioned
above, it would give us the best of both worlds.


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

I really like this idea. However, I think it's a bit late in the game to
change the behavior of 'marker-mid' (even if it is decptively named); so,
maybe 'marker-mid' and 'marker-vertex' could be equivalent (as they are
now), and a new attribute, 'marker-midpoint' could be introduced.


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


There are already various shortcuts in SVG to do things with simplified
syntax (the text attribute 'rotate' taking the place of
'transform="rotate(n)"' springs to mind), so I don't see why there couldn't
be shortcut syntax for some of the more common usecases of VE, such as this
one. It's not so much adding functionality (which leads to feature-creep) as
it is optimizing the usage of existing functionality.


Regards-
Doug

doug . schepers  @ vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Monday, 27 June 2005 15:34:36 UTC