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) ?
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
