On 27 août 2013, at 07:18, "Keith OHara" <k-ohara5...@oco.net> wrote:
> On Mon, 26 Aug 2013 02:11:28 -0700, Mike Solomon <m...@mikesolomon.org> wrote: > >> >> I think that if we can devise a better system, the creation of a new stencil >> primitive is unnecessary. If we agree that we should implement a system >> where stencils are carriers of their own skylines, then we should fix this >> bug using that system. >> > > In any system of building skylines from markup, we want to regain the > spacing-control that we had with > \with-dimensions #(0 . 1) #(0 . 1) "text" > and maybe we might have in the future > \with-shape {/* shape for purposes of spacing around music */} "text" > > Maybe someday both of these will be implemented using a skyline-generator and > skyline-remover > \combine > \transparent \make-shape {/* shape for spacing */} > \no-skyline "text" > > In any case we need a way to omit or ignore the usual skyline from some > markup. > > > (1) At the moment, the stencil expressions are assembled first, when markup > is interpreted, and then stencil_traverser() reads the stencil expression to > figure the skylines. So long as that approach remains in place we need some > sign in the stencil expression to be read by stencil_traverser() telling it > to omit the usual skyline around part of the stencil. (I could re-use > 'delay-stencil-evaluation, but think a new primitive is wiser.) > > > (2) If someday the skylines are assembled in parallel with > stencil-expressions when the markup is interpreted, then \with-dimensions or > \no-skyline could simply throw away the skyline it built for "text" (in the > examples above) and there is no need for a 'with-dimensions' primitive. > (There would still be primitives that move markup like 'translate-stencil' > for things like \concat {B\flat}.) > > > Are systems organized as in (2) better systems than the one we have organized > as in (1) ? > Good summary of the current state of things. I'd argue that (2) is better. The original function definition for \with-dimension does not need a special primitive because dimension information is encoded in the stencil in parallel with stencil-expressions when the markup is interpreted. The same could be true of skylines, with the caveat that skylines should only be generated and used when asked for to save computation time, and otherwise dimensions should be used. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel