Re: strut problem, Re: strut problem, Re: strut problem, Re: strut problem

[Jean Abou Samra]


> Le 19 nov. 2022 à 08:04, Werner LEMBERG <wl@gnu.org> a écrit :
> 
>> 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.


YAGNI. Just use ly:stencil-outline.

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.


>> 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.



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.


>> 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]]
> ```


Note that markup commands don’t support optional arguments.

\with-replaced-skyline sounds a lot like

\with-outline \translate #'(offset . 0) markup2 markup1

(which also changes horizontal skylines).

\with-added-skyline sounds like

\with-outline \overlay { markup1 \translate #'(offset . 0) markup2 } markup1

Supporting the 'extent' parameter would take some modifications to the C++ 
code. Do you have a specific use case for it?



Jean