Re: Issue 3330: redo much of the stencil stacking/spacing/empty-check (issue 8869044)

[dak]

On 2013/05/05 01:50:23, Keith wrote:

> If you know how to keep track of a cursor position in Scheme, the you
could put
> the implementation of backspace in stack-stencil-line and any other
functions
> that assemble a line of stencils.

> That would probably be easier for future programmers to understand
than the
> encoding of backspaces in half-empty stencils, implemented by the
function (now
> misleadingly) called add_at_edge().

add_at_edge is not actually named misleadingly in the current iteration
since the only information of the base grob that is being used for
placement is indeed only the location of the given edge, independent
from its absolute position and other edges.

The _added_ stencil is checked for backspacing metrics and similar.

Now if we are talking about empty extents, they don't have edges to talk
about, so we are actually more or less free to choose behavior that
makes sense.

Maintaining a "cursor position" in stack-stencil-line and friends means
that you can't assemble partial lines yourself in a manner blending in.
That's bad.

There is a simple way out: maintain "cursor positions", namely x and y
escapements (or better, escapements for every of the four edges)
explicitly in each stencil.  Fonts actually carry this kind of
information for each glyph, but LilyPond discards it.

That is the way that LilyPond should really go in the long run.  In the
mean time, encoding escapement-only information into grobs with partly
empty extent at least gives us a natural-behaving variant of hspace and
vspace.

I was actually going to rewrite much of the line wrapping functions as
well in order to stop them from keeping separate line width
calculations.  Adding one stencil to a line and measuring it is an O(1)
operation, so there is no point in keeping a separate tally: one has to
assemble the line anyway.

Justification can simple be done by assembling the line twice with
different values of spacing and extrapolating the correct spacing from
there.

Not having to keep tallies will make the code robust even if we
eventually do get escapements into stencils.  Also the code does not
need to know itself any more about the specifics of hspace and vspace.

Indeed, the last few iterations removed quite a lot of explicit (and
partly inconsistent) treatment of empty stencils: there is no need to
weed them out when add_to_stencil does the right thing with them.

https://codereview.appspot.com/8869044/