lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Design flaw in Rest_collision


From: address@hidden
Subject: Re: Design flaw in Rest_collision
Date: Mon, 5 Nov 2012 13:41:35 +0100

On 5 nov. 2012, at 11:15, Werner LEMBERG <address@hidden> wrote:

> 
>> No, we're talking about the height of something like rests.1
>> compared to rests.1o in the Feta font.
> 
> OK.
> 
>> The question is if these two glyphs have a different Y-extent
>> (rests.1 versus rests.1o).
> 
> From feta20.log, beautified:
> 
>  whole rest                 0  7.5  3.125    0        7.5  0  0
>  whole rest (outside staff) 0  7.5  3.125    0.50005  7.5  0  0o
>  half rest                  0  7.5  0        3.125    7.5  0  1
>  half rest (outside staff)  0  7.5  0.50005  3.125    7.5  0  1o
> 
> So the answer is yes: The height (resp. the depth) is larger for
> outside-staff glyphs.
> 

Ok.

So we officially have a circular dependency: in order to know the height (for 
collision resolution) we need to know the extent, but in order to know the 
extent (because of the glyph) we need to know the height.

There are several comments in rest.cc that suggest that the original author 
(Han-Wen) was aware of this and wrote some code to avoid its popping up, but 
the dependency is still there.

One way to resolve it is to make the assumption in rest-collision.cc that grobs 
are not using custom stencils, in which case one would not need to call 
Grob::extent but could rather call a new brew stencil function that takes as 
its argument a boolean for ledgered or not.  But this is not lilypond-ish in 
spirit as it hardcodes font into layout.

It's an interesting problem...solutions are welcome!  Obviously it's not 
critical, but my long-term goal is to get rid of translate_axis and this is a 
prime example of how calls to translate_axis can obfuscate circular 
dependencies in the code (without the call to translate_axis in 
Rest_collision::force_shift_callback_rest, which in effect does nothing except 
fill the dim cache, this problem would show up all over the place).

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]