[smufl-discuss] Re: Request for comment: Proposal for SMuFL metadata files

[TW]

Hi Daniel,

thanks for that work, I consider proper metadata extremely important.


2013/10/28 Daniel Spreadbury <[hidden email]>:
>
> 1. A canonical set of glyph names for the mandatory glyphs in SMuFL,
> mapped to their Unicode code points. Glyph names are specified using lower
> camel case.
>


I see that you chose to specify the hex values as strings, like

    "4stringTabClef": {
        "codepoint": "U+E07B"
    }

I'm wondering whether most of the time, you'd need the numerical value
rather than a string and therefore

    "4stringTabClef": {
        "codepoint": 12411
    }

might be worth considering.  Any opinions on that?


> 2. A means to group similar glyphs together into classes. This may be
> useful for applications that intend to support SMuFL-compliant fonts to
> know, for example, which glyphs are noteheads, which are clefs, etc., to
> help make decisions about glyph positioning.
>
> For SMuFL-compliant fonts, we have devised a format that captures
> information that cannot be directly defined in the font's data. The
> metadata file includes suggested engraving defaults that are complementary
> with the font designer's intentions for things like line thickness, etc.,


It's so good to have that info in the font metadata!  All these things
need to work well with the font.

Wouldn't it be more flexible to replace barlineSeparation with two
values, one for double barlines and one for ending/repeat barlines?
I'd not be surprised if sooner or later a font designer would want to
distinguish between the two, or even between end, repeat and double
repeat.  Would it be worth to preemptively account for that?  Or
should there be something like CSS vendor prefixes to allow font
designers to introduce their own settings without messing things up,
causing problems with later versions of SMuFL?

This might be nitpicking, but in technical specifications, that's
probably what is needed:  The description of barlineSeparation could
be more precise.  "Distance" could be interpreted as the distance
between the line centres or the width of the actual gap.  I guess the
latter is intended.  This might be a candidate for a clarifying
illustration.


> as well as attachment points to help software vendors ensure good
> connections between (say) stems and flags, and stems and noteheads.
>


I think there needs to be similar info for the attachment of bracket
top/bottom glyphs to the bracket line, unless it's specified that
their point of origin shall precisely coincide with the proper corner
of the rectangle it's attached to.  However, there is nothing
demanding that on p. 19-21 or p. 26.

Similar "winglets" are occasionally found on handwritten style repeat
barlines, described e.g. by George Heusstenstamm: The Norton Manual of
Music Notation, p. 158.  I think they should be added to the glyph
set, together with the proper attachment info or point-of-origin
requirements.  An additional set of symbols might be needed for
double-repeats.

AFAIKS the distance of repeat dots from the barline can currently not
yet be specified.  Looking at repeat dots, it seems we only have
double dots right now, but for non-five-line staffs we should have
single dots to be flexible and achieve other dot constellations:

http://ukulelehunt.com/wp-content/uploads/2008/01/rept12.gif
http://media.wiley.com/Lux/86/105586.image0.jpg
http://upload.wikimedia.org/wikipedia/commons/1/1d/Attaingnant--branle-de-poictou.png

(Those examples were collected in the MuseScore forum[1])

I think as segno serpents can be superimposed on barlines, their
position relative to the barline should also be definable so that they
align as intended (or their point of origin should be prescribed).

Wouldn't combining G clefs need some attachment info for the numbers
as well?  (Which numbers are meant to be used, BTW?)


Another question concerning loosely related proportions:  On page 21,
I read: "Letters for dynamics (and for D.C./D.S. in the repeats range)
should be scaled such that the caps height is around 0.75 em, and the
x-height is around 0.5 em."

What is the intention of this sentence?  Isn't it up to the font
designer to define the proportions of those text glyphs relative to
the staff size?


SMuFL has a lot of codepoints for for providing the same glyph
multiple times, in flipped/rotated/mirrored forms and possibly
repeated in another range.  I think for applications where file size,
memory or bandwidth is of concern, it would be useful if there was
metadata for the "clones" that points to their "original", ideally
together with transformation info, e.g. using a CSS transformation
matrix[2].  Like this, the application could choose whether to use the
pre-transformed glyphs or strip the clones and transform the
originals.

If the font designer chose not to render the flipped/mirrored a symbol
as a transformed clone of the original but in a slightly modified
form, such pointing/transformation metadata must of course not be
provided.


I saw one inconsistency between smufl-0.7-draft.pdf and
glyphnames.json:  "alternate_codepoint" vs. "alternateCodepoint".


Keep up the great work!
Thomas


[1] http://musescore.org/en/node/17840#comment-64703
[2] http://dev.w3.org/csswg/css-transforms/#typedef-transform-function

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