> >Good idea. But this means you must explicitly state all 22 "Alkmar Allah" > >elements. This can't be the sense/usage of SVG-coding. :-( > >I want to have a logical strcutred SVG code reflecting the geometric > >constrcution, not a meaningless heap of coordinates of 3 pathes for 3 > >colors ! :-(( > > Alas, SVG does not define any way of constructing a single path out of > cloned segments, so this is not possible in general. Sorry, this comment I don't understand at all. Maybe a misunderstanding?
> While I haven't looked at the internals of the rsvg renderer (or any > other SVG renderers, for that matter), I doubt that two cloned paths are > any easier to render than a single path with twice as many nodes. While > in some special cases there might be optimizations that could be made, > few of those optimizations are generally applicable, given that, in > general, the two clones might be very differently transformed and might > be drawn on very different backgrounds. Yes might! But maybe very similar and on some background, as in many internal same-repeating geometric structures of artifically objects. And then an "intelligent" algorithm can take significant advantages. It's like the problem of data decompression. ;) Thanks for your detailed explanation of typical currently rendering in practise. Achim _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
