>> 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. > > YAGNI. Just use ly:stencil-outline.
OK. > Are you mindful that ly:make-stencil is a low-level function? If you > use it, you need to have an understanding of how stencils work at > the low level. > > I don’t see what we would gain by changing those internals. No problem. I'm only thinking aloud :-) >> 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. > > As said above, LilyPond considers the outline of stencils in > addition to their extents (unlike LaTeX, AFAIK), and the skylines of > text with \strut will depend on where \strut is put. > > So I lean towards the second option. Me, too. https://gitlab.com/lilypond/lilypond/-/issues/6473 >>> 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]] >> ``` > > \with-replaced-skyline sounds a lot like > > \with-outline > \translate #'(offset . 0) markup2 markup1 > > \with-added-skyline sounds like > > \with-outline > \overlay { markup1 \translate #'(offset . 0) markup2 } markup1 Excellent, thanks. > Supporting the 'extent' parameter would take some modifications to > the C++ code. Do you have a specific use case for it? No. I was just envisioning the most general case. Werner
