From: Mihaela <myhaella5@ya...>  20080609 17:00:13

Aaron Spike wrote: > Mihaela wrote: >> I thought the lsystem syntax was unique, but I found different >> formulation for scaling on another website, does it matter which one >> is adopted in Inkscape? > > It probably doesn't matter. Perhaps we should try to find out which > syntax is more popular (and thus which has more examples on the web). > Or if possible we could implement both. Can you summarize the > different syntaxes you've found? I haven't had time to go through all of them in detail but I think I found more than 2 different approaches. I plan to dive into python as soon as I get some free time, and then I'll look deeper into this also. Until then I'll stick to what's already there in your script ignoring everything else. > I think we need to switch from iterated loop over the pattern string > to a counted loop. Then when we see @ we know to advance until we've > used all the possible numeric characters. This could even be done with > a regular expression. > > Aaron > I don't have enough python knowledge to do it myself (yet), I think I've been able to come up with is an algorithm how the @ resize factor might be implemented, then if it makes any sense to anyone else they might do the python cooking: *SYNTAX* Because of the way the script goes through the rules it would probably be best to syntax the resize rules like this: @0.8F  first comes the @ that signals you are about to get the resize factor, then resize factor itself (0.8 in this case) and then the element (line) we want to resize (F in this case). *RECURSE* This is how the recurse part of the script works atm: it spits out the final generation rule to be drawn, level can tell you each element's generation (age), i.e. level counts how many times an element is replaced by the rule. The recurse part should be modified to detect @ in the last generation rule, and recalculate every resize factor following the @ according to this formula: resize factor=(resize factor)^level So the recurse part of the script now spits out the final generation rule where every element we want resized has its resize factor calculated according to its age. Lets say this is our rule (axiom is F, I used spaces just to visually help separate the elements, there are no spaces in real formulas): F=@0.7A @0.5F @0.3A Only the middle element (F) is recursed, its level is increased (is older one generation) so its factor is recalculated, the second generation is: @0.7^1A @0.7^2A @0.5^2F @0.3^2A @0.3^1A that is: @0.7A @0.49A @0.25F @0.09A @0.3A *COMPOSE PATH* The second thing to modify is the compose_path part of the script. Another c must be added (for @), make it get the number behind @ and multiply it with the element length (step size). Maybe the randomize feature might also be applied here? This way the resize factor can be set for every element of the rule separately, so I think it's more flexible than some of the other solutions I've seen. 