Re: where X-extent of noteheads is set?

[Janek Warchoł]

2011/7/18 Neil Puttock <address@hidden>:
> 2011/7/18 Janek Warchoł <address@hidden>:
>
>> 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 address@hidden <address@hidden>:
>
>> 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

breve extent exmaple 1.preview.png
Description: PNG image

breve extent exmaple accidental.preview.png
Description: PNG image