john cliff schrieb:
2008/9/3 Maximilian Albert <Anhalter42@...173... mailto:Anhalter42@...173...>
bulia byak schrieb: > I think we will need to store widths not per node, but as a list of > length along path/width pairs, with length measured in percentages > of the total length of subpath That's an excellent idea. Since I had something like Pajarico's other suggestion in mind (see different email), I was thinking about how to store per-node information. But separating the width info from nodes and storing it in the described way will make the LPE very powerful and flexible.Its an excellent idea until you make any change that substantially alters the path length, at which point all your widths 'slide' along the path when you didnt want them to...
Good point. An ad-hoc [1] correction could be to store the info in a way that more closely follows 2geom's way of storing path data. Namely, when we think of the path as parametrized by time, each node is on an integer time value. I.e., the initial node is at t=0, the next one at t=1 and so on. Thus a length-along-path value of 1.8 would represent a location on the segment between the second and third node (closer to the latter). This representation is much less susceptible to length adjustments and we can deal with node insertion/deletion more easily.
Still, since we need to catch events like node insertion/deletion and perform additional calculations for paths which have calligraphic LPE applied (as opposed to "regular" paths), I feel it might be worthwhile to encapsulate such paths in a separate SPItem. I don't know whether this is true but I thave the feeling that this would make the implementation more robust and extensible; any opinions from experts?
Max
[1] Disclaimer: I haven't thought about it deeply; maybe it has flaws in some other respect.