2011/7/18 Neil Puttock <n.putt...@gmail.com>:
> 2011/7/18 Janek Warchoł <lemniskata.bernoull...@gmail.com>:
>
>> i don't see anything called "stencil-width" in grob.cc...
>
> 78 if (get_property_data ("X-extent") == SCM_EOL)
> 79 set_property ("X-extent", Grob::stencil_width_proc);
>
> The C++ name is Grob::stencil_width; the addition of _proc uses the
> exported scheme version.
>
>> I don't want to read the value of extent, i want to modify how it's
>> calculated in case of noteheads.
>
> The extent comes directly from the font (i.e., using the bounding box
> of each glyph).Ah. This makes things more difficult i guess. >> I suppose that noteheads X-extent is wrongly calculated now. Judging >> by this >> http://lilypond.googlecode.com/issues/attachment?aid=-4756087064344904294&name=test.png&token=22aa1208ff6775e1780efcedc7e7e841&inline=1 >> , all noteheads are assigned the same X-extent, even though the glyphs >> have different widths. > > No, the problem is that the code doesn't account for differences in > font-size between heads; all the hard-coded shifts it calculates You mean the values in lines 264-291 of note-collision.cc? > (split equally between heads; heads move away from each other by the > same amount) are based on the assumption that meshing notes have the > same font-size. > Further to this (since I was thinking of collisions between CueVoice > and Voice), there are no rules in note-collision.cc which specifically > cater for heads with duration logs less than zero (apart from the > no-merge rule). Yes, neither different font-size nor different glyph widths seem to be cared for. 2011/7/18 m...@apollinemike.com <m...@apollinemike.com>: > >> I don't want to read the value of extent, i want to modify how it's >> calculated in case of noteheads. >> I suppose that noteheads X-extent is wrongly calculated now. Judging >> by this >> http://lilypond.googlecode.com/issues/attachment?aid=-4756087064344904294&name=test.png&token=22aa1208ff6775e1780efcedc7e7e841&inline=1 >> , all noteheads are assigned the same X-extent, even though the glyphs >> have different widths. >> Or maybe i don't understand how it works... > > The issue is in the metafont file: see line 160ish in feta-noteheads.mf. You mean that metafont's char box contains only the notehead, not the lines? I guess that the problem in general is that sometimes we want to include breve's lines in glyph width calculations, and sometimes not. Take this example: \new Voice << { c''1 } { \override Staff.NoteHead #'style = #'altdefault g'\breve } >> (i'm using double-lined breve to magnify the effect) the whole note and breve are "center-aligned" here - i.e. left-most edge of breve glyph is not aligned with left-most edge of whole note. I guess it's desired. So, in the case of calculating non-colliding note columns we want to ignore the lines. However, in all other cases we want to include them - for example in colliding note columns (like in 1546), in accidental calculations - see this, it looks quite bad now: \new Voice { \override Staff.NoteHead #'style = #'altdefault gis'\breve*1/2 ges' g'! } The question is - how this should be done? Should we include lines in metafont char box width, but add an exception to note column calculation? Or add an additional parameter? Like "X-extent-in-uncolliding-note-columns" (ugh!)? cheers, Janek
<<attachment: breve extent exmaple 1.preview.png>>
<<attachment: breve extent exmaple accidental.preview.png>>
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
