Re: where X-extent of noteheads is set?

[Janek Warchoł]

Hi,

i think i know how to fix this
(http://code.google.com/p/lilypond/issues/detail?id=1546 and some
related problems); there are two things to do.

>>> 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.

This needs to be changed so that shift amount depends on notehead
extent.  Anyone willing to help me with this?  I'll read the code and
i guess that i won't have much trouble understanding it, but changing
architecture is not what i'm good at.


> 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?

I've done a very dirty test which showed that a properly set glyph
bounding box solves this perfectly (see in the attachment how the
bounding box should change).
However, there is a problem.  Currently bounding box is set by
procedure draw_outside_ellipse (defined in mf/feta-params.mf) - it is
not set in the definition of the glyph.  How to set glyph bounding box
to something different than outside_ellipse bounding box?

cheers,
Janek

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

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

breve char box current.png
Description: PNG image

breve char box new.png
Description: PNG image