[smufl-discuss] Re: Glyph registration proposal

[Joseph Berkovitz]

On Jul 8, 2013, at 11:39 AM, "Daniel Spreadbury" <[hidden email]> wrote:

> Joe wrote:
>
>>> I am not sure if this should apply for clefs. My intuition is,
>> that the clefs should be placed so, that the note that the clef
>> refers to, is on the baseline (e.g. F-clef placed so, that one dot
>> is above and the second below the baseline). Then, there would be no
>> need for additional vertical adjustment for clef changes/cue clefs.
>> (Even if clef changes would be encoded, there are still cue clefs to
>> be positioned correctly)
>>
>> This idea also works (and is in fact the approach taken internally
>> by Noteflight). But for clefs that don't refer to a "target note"
>> such as TAB or percussion clefs, such a rule could become a bit
>> arbitrary. So I don't have a strong feeling about it, either way.
>
> For what it's worth, Opus and Petrucci follow Emil's recommendation, while
> Sonata follows Joe's proposal. Perhaps it does make sense for us to follow
> the majority rule here? I think this change would get my vote.

Actually I'd like to join you and Emil on this one. I wasn't sure how people would feel about the target-note idea.

It also makes the handling of the C clefs more elegant.

So maybe we should make this change unless additional folks pipe up and disagree. Note that this requires the spec to explicitly state that all "target-note-free" clefs such as the percussion or TAB clefs should place the baseline at their vertical center.

>
>>>> TIME SIGNATURES
>>
>> I agree with your point -- I think this was an oversight in my
>> proposal. You are correct, time signature digits conceptually fit
>> within a vertical extent, or are centered around some baseline.
>
> How should fonts that require or prefer larger digits work? For example,
> several handwritten fonts feature time signature digits that protrude
> above and below the staff, but still abut at the middle staff line. If
> these digits were drawn centered on the 2nd and 4th staff lines per Emil's
> proposal, this wouldn't be possible. Unless I'm missing something (which
> is by no means unlikely).

Hmm. I think you're right. Maybe we should leave things as is (i.e. digits have the usual textual-glyph relationship to baseline) and require apps to use bounding boxes to arrange digits on either side of the staff center line, with some padding.

I also think it would be useful if external metadata could supply an overall ascent metric for time signature digits.

[RESTS]

>> I think this would also be a good change to my proposal.
>
> I'm not sure about this. The positioning of e.g. a bar rest is different
> when on a one-line staff than on a five-line staff, since a bar rest hangs
> from a one-line staff, but a half rest sits on top of a one-line staff,
> which is the exact opposite of their normal positions relative to each
> other in the more common five-line staff case. For what it's worth, Joe's
> proposal also appears to be the convention followed by Opus, Sonata and
> Petrucci.
>
> My vote would be to stick to Joe's original proposal in this area.

This is a good argument. Application code needs to make some of these fine-tuning decisions for various size staves. So I suppose I will stick with my original proposal too.

…joe
#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>