> A stencil has an X extent, a Y extent and a stencil expression
> (Scheme list). That's all.
>
> Think of it in another way. If LilyPond gave non-empty skylines to
> stencils with empty extents, a grob with its stencil set to
> #empty-stencil would stop taking no space. Instead, it would take
> the space of a point and start influencing the spacing. I think it
> should be clear that this is a bad idea.
OK, understood. It would be necessary to add another property to
stencils, say, an 'active' flag, so that they can be intentionally
taken out of a skyline.
> Can we take a step back? What are the use cases for \strut in the
> first place? Maybe we can invent something that works more sanely
> and fits the same purposes.
What I want is to have the `\strut` command work in general. If this
is not possible – for the reason you've outlined – it should be
deprecated, together with some documentation that explains why struts
don't work (or are the wrong concept) in LilyPond.
> For example, you could have a markup command that takes a string and
> typesets it while giving it the extents + outline of a box around it
> encompassing the height of potential ascenders and descenders.
Maybe a more generic solution?
```
\with-added-skyline markup1 markup2 [offset [extent]]
\with-replaced-skyline markup1 markup2 [offset [extent]]
```
Print `markup1` but give it a modified vertical skyline. Both
functions overlay the skyline of `markup2` on top of `markup1`;
`\with-added-skyline` takes the maximum of both, while
`\with-replaced-skyline` replaces the skyline of `markup1` with the
one from `markup2`.
For computing the new skyline, `markup2` is shifted horizontally by
`offset` (default is 0), and only `extent` (an interval) is taken
from it (default is the extent of the complete `markup2`).
Note that `markup2` must have a non-zero extent to take any effect.
No idea whether such functions make sense in the long run...
Werner
