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

[dspreadbury]

Thomas wrote, among other things:

> Wouldn't it be more flexible to replace barlineSeparation with two
> values, one for double barlines and one for ending/repeat barlines?

I don't have any particular axe to grind on this point. If it's legitimate
for the font designer to recommend a different separation for different
kinds of barlines, then we should provide separate values. I would rather
have a handful more values than encourage vendor-specific extensions. All
of these values are optional in any case.

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

Generally speaking the distances used in the SMuFL documentation are from
the middles of lines, but perhaps in this case the gap between the
bounding boxes of the glyphs is more useful.

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

I will add a clarification on that point to the guidelines for glyph
registration.

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

I will add an optional "repeatBarlineDotSeparation" parameter to the
metadata specification. We should likewise have a glyph for a single dot
in the 'Repeats' range for consuming applications to position themselves.
 
> 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).

Is it the case that segno serpents should always be centered either above
or directly superimposed on a barline? If so, then they should probably be
registered such that x=0 is the nominal center of the glyph.

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

In the recommended ligatures, the tuplet numbers are used. Yes, it
probably makes sense for there to be an anchor for the position at which
the top or bottom of a number glyph's bounding box should be positioned,
for the cases where the font does not provide ready-made ligatures (as
Bravura, for example, does).

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

Yes, but this is intended to assist the font designer in achieving the
correct (or at least, conventional) scale factor for things like dynamics,
which tend to be around two spaces tall.

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

Sorry, I don't really see the benefit here. What kind of real-world
application would need this distinction, i.e. need to know which other
glyph to rotate rather than which glyph to display non-rotated?

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