On 5 nov. 2012, at 11:15, Werner LEMBERG <w...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
