[Top][All Lists]
[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
- Re: Design flaw in Rest_collision, (continued)
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/05
- Re: Design flaw in Rest_collision, David Kastrup, 2012/11/05
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/05
- Re: Design flaw in Rest_collision, David Kastrup, 2012/11/05
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/05
- Re: Design flaw in Rest_collision, David Kastrup, 2012/11/05
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/05
- Re: Design flaw in Rest_collision, Werner LEMBERG, 2012/11/05
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/05
- Re: Design flaw in Rest_collision, Werner LEMBERG, 2012/11/05
- Re: Design flaw in Rest_collision,
address@hidden <=
- Re: Design flaw in Rest_collision, Keith OHara, 2012/11/05
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/06
- Re: Design flaw in Rest_collision, Keith OHara, 2012/11/07
- Re: Design flaw in Rest_collision, address@hidden, 2012/11/07