[smufl-discuss] Re: Registration of articulation glyphs

[Adler, Mark]

Generally, I favor keeping SMuFL's current registration for articulations.
As Daniel pointed out, there doesn't seem to be much of a benefit in
changing it. Most existing music fonts employ similar metrics to SMuFL's
articulations. By keeping the current registration, you reduce the pain
for users of any established application that want to update old files
with a SMuFL compliant font. While it is easy enough in Finale to import a
library of offsets for conversion of MakeMusic's older fonts, or handle
conversion under the hood, it becomes more problematic when users want to
convert older 3rd party and publisher proprietary fonts.

Mark
MakeMusic






On 1/23/14 10:07 AM, "Daniel Spreadbury" <[hidden email]> wrote:

>Maurizio wrote:
>
>> All articulation glyphs (U+E460 - U+E476) are VERTICALLY registered to
>sit
>> on the base line.
>>
>> 1) At least for "staccato" and "tenuto" (U+E461 - E462) and maybe other
>> glyphs too, this might be inconvenient: if used inside a staff, they are
>> vertically placed in the middle of the space right above or below the
>note
>> head (e.g.: in treble clef, C note in the 3rd space, either glyph
>>should
>be
>> centred in the 4th space).
>>
>> Having them registered to sit on the base line requires computing their
>> height to be able to centre them; also, different adjustments are
>>needed
>if
>> placed above the note head or below. Of course, it can be done, but it
>is
>> perhaps an unnecessary complication: would it not be the case to centre
>them
>> on the base line?
>
>On the subject of glyph registration I don't generally have any specific
>axe to grind; it's easy enough for us to adapt the way we position glyphs
>relative to each other to any reasonable set of guidelines, but I suspect
>these kinds of changes have a rather greater potential impact on the
>developers of more mature existing applications, so I wonder whether the
>folks at MakeMusic, Noteflight et al would like to comment on this
>proposal?
>
>From my perspective, it doesn't seem to me that centering articulations
>either on the x-axis or the y-axis on the baseline is a no-brainer: you
>still have to measure the glyph to determine whether or not it fits
>within
>a staff space (which is not guaranteed for all fonts), or how much space
>needs to be left between the top or bottom of a note and the top or
>bottom
>of the articulation, which cannot be a fixed distance for all
>articulations.
>
>> 2) For glyphs with an "above" and a "below" variant ("staccatissimo",
>> "wedge", "marcato", ...), the current setup requires different
>processing
>> for the two variants. Again, it can be done, but is it really necessary?
>> Having the "above" and "below" variant registered to be vertically
>> symmetrical one to another wold surely simplify the usage of the font
>(if
>> the "above" variant sits on the base line, the "below" variant should
>'hang'
>> from it).
>
>I like the logic of this suggestion, but again, I think we need to hear
>from some other developers about what kind of impact this might have on
>existing software. The current registration for these glyphs follows the
>approach taken going as far back as e.g. Sonata.
>
>> 3) They are also HORIZONTALLY registered to be on the right side of the
>y
>> axis. As they are almost all and always horizontally centred on the note
>> head, having the glyphs centred around the y axis would again surely
>> simplify their usage.
>
>This seems like a reasonable idea, though it's also not difficult to
>measure the width of a glyph and then move its x-position by half of its
>width. More feedback from others in the community is needed, I think!
>
>Thanks again for the suggestions,
>
>Daniel
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg,
>Germany
>Phone: [phone] | Fax: [phone] | www.steinberg.net
>President / Managing Director: Andreas Stelling
>Managing Director: Kazunori Kobayashi, Hiroshi Sasaki
>Registration Court: Hamburg HRB 86534
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
>#############################################################
>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]>
>

#############################################################
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]>

[Maurizio M. Gavioli]

Adler, Mark wrote

Generally, I favor keeping SMuFL's current registration for articulations. As Daniel pointed out, there doesn't seem to be much of a benefit in changing it. Most existing music fonts employ similar metrics to SMuFL's articulations. By keeping the current registration, you reduce the pain for users of any established application that want to update old files with a SMuFL compliant font. While it is easy enough in Finale to import a library of offsets for conversion of MakeMusic's older fonts, or handle conversion under the hood, it becomes more problematic when users want to convert older 3rd party and publisher proprietary fonts.

Mark
MakeMusic

I think I understand the concern. In fact, with MuseScore, we faced a similar issue, but in the opposite direction: our articulation glyphs (which we inherited from Lilypond) were in many cases centred on the origin and, after moving to SMuFL, we are getting 'misplaced' glyphs.

In principle, backward compatibility with legacy fonts does not strike me as a so compelling reason. For any given legacy, code point mapping is likely to be different; even more, it is not guaranteed that a one-to-one correspondence between the legacy font glyph set (whatever it is) and the SMuFL one exists, so adapting from one to the other is not a trivial task anyway and supporting both is going to be even more complex.

Also, SMuFL is striving to be a platform-agnostic and legacy-agnostic standard (or at least it seems to me it is) and to be bound by habits rather than looking for the most logic solution isn't perhaps a bit too conservative?

The current SMuFL registration for these glyphs means retrieving the bounding box of each glyph and calculating its geometric middle point (horizontally, vertically or both). As I said, it can be done (even rather easily), but this is almost the same as not prescribing any given registration at all; where is the gain?

In addition, the geometric middle point does not necessary coincide with the optical middle point (this is more evident for asymmetrical glyphs like "articAccent"), but the optical middle point is very hard to calculate if it does not fall on a defined standard position (the point (0,0) seems the most obvious candidate for such a position, but the important element is that it should be known beforehand).

So, the current solution seems to me neither as simple as it could be for 'simple' applications (or 'simple' cases) nor as complete as it could be for 'sophisticated' applications. Of course, it is just an opinion, but is there any chance to reconsider the matter?

Thank you,

Maurizio M. Gavioli