2009/8/7 jf barraud <jf.barraud@...400...>:
My opinion is the following: the main point with the thing->path paradigm is that you cannot edit the style of the output.
That is, you cannot edit it with the LPE - the result simply always has the style of the source path. This is simple and automatic with current representation, because it is just the same element. With proposed representation, it will require extra coding to properly copy the style (which is not trivial, because a style may be a result of a complex layering of parent styles), though of course it will also open new possibilities.
This is by desing, and I'm happy this choice was made, and I think it was a smart choice: we now have our good working and simple to implement lpes!
That's exactly my point.
On the other hand, we will sooner or later want to have LOEs (live-"object"-effects) to allow more sophisticated effect (like interpolate shape+style between two objects).
I think we should keep lpes as they are and implement the more sophisticated LOEs. Once they work correctly, we'll can move the lpes to be special cases of LOEs.
Agreed, and I think this could be a compromise that we all can agree upon. Let's not jump the gun. If Krzysztof or anyone implements the switch-based infrastructure and proves it workable with at least one non-LPE object (such as TeX objects or something like that), then we can consider switching LPEs to that mechanism. Until then, let's not fix what isn't broken.
Btw, I think the good output for the example of bulia would be:
Your example fixes the problem with styles, but it still has the other issues I pointed out - inefficiency of nested switches, SVG elements inside non-SVG, and potential problems with svg:use.