Background directives and include files?
Posted: Sat Mar 31, 2007 4:40 pm
What is the expected behavior of background directives in include files?
I had assumed that, like startshape, every background after the first one would be ignored. However it seems as if each one is overwriting the one before, which is unexpected, because it means you can't edit the background in the top-level design - you have to hunt through your include files. It also means that cfdg files can have their own startshape, but not their own background - if you plan on reusing them in another design, the background needs to come out.
If backgrounds behaving in this way is the intended behavior, can we always check the last-included library for its last-included library (etc.), or does the order of assembling included files ever change based on whether the library path is relative, absolute, in the default folder etc.?
Personally I'd prefer declaring the background in the top-level design and ignoring the rest. However, if you reading subsequent backgrounds, it might be more context-free-ish to make the values cumulative: e.g. background { b -1 } + background { b .5 sat 1 h 30 } + background { b .1 sat .1 h 340 } = background { b -.6 sat 1.1 h 370 } (which gives you real values of b .4, sat 1, h 10)....
I had assumed that, like startshape, every background after the first one would be ignored. However it seems as if each one is overwriting the one before, which is unexpected, because it means you can't edit the background in the top-level design - you have to hunt through your include files. It also means that cfdg files can have their own startshape, but not their own background - if you plan on reusing them in another design, the background needs to come out.
If backgrounds behaving in this way is the intended behavior, can we always check the last-included library for its last-included library (etc.), or does the order of assembling included files ever change based on whether the library path is relative, absolute, in the default folder etc.?
Personally I'd prefer declaring the background in the top-level design and ignoring the rest. However, if you reading subsequent backgrounds, it might be more context-free-ish to make the values cumulative: e.g. background { b -1 } + background { b .5 sat 1 h 30 } + background { b .1 sat .1 h 340 } = background { b -.6 sat 1.1 h 370 } (which gives you real values of b .4, sat 1, h 10)....