[smufl-discuss] Please restore immutable code points

[Good, Michael]

Hi Daniel,

SMuFL 0.7 is very impressive! Things sure have come a long way over the
past year. Mark Adler and I have some suggestions for further improvements
which I'll be sending in future emails. Those are things like adding a few
glyphs added here, subtracting a few glyphs there, plus some metrics and
metadata tweaks.

I first wanted to discuss one fundamental issue introduced in SMuFL 0.7
which I believe greatly decreases SMuFL's usefulness. I hope that this
change can be undone for SMuFL 0.8. This is the statement that code points
may change between revisions, and that canonical names should be used
instead (p. 13).

Canonical names are a wonderful addition to SMuFL. They will make life far
easier for referencing SMuFL features from MusicXML, and provide a nice
possibility for mapping current pre-SMuFL fonts to a standardized mapping.
If people want to use them to track changing code points between SMuFL 0.7
and 1.0, that's fine.

Once SMuFL 1.0 is released, though, code points should never change. The
one exception would be if SMuFL eventually moves from the private area
directly into the Unicode standard. New code points may be added, and
maybe even some old code points get deprecated, but they should never
change.

One of the fantastic powers of Unicode is that you can take a single
32-bit code point and know what it means without depending on context. You
don't need to know a Windows code page or a Mac character encoding. You
don't need to refer to a metadata or mapping file. The code point is a
unique identifier and contains what you need to identify the semantics in
a single quick atomic operation.

If code points are mutable between versions, we start moving back to where
we were before SMuFL, or before Unicode. SMuFL is no longer an accurate
name because there's no longer a standardized font layout. Instead it
should be SMuFT for a standard music font taxonomy. In order to interpret
the semantics of a 32-bit number, you need access to metadata that you may
or may not have. A simple, atomic, context-free operation has become more
complex, transactional, and context-sensitive. This single decision could
adversely affect the speed and reliability of all SMuFL software, and
complicate the free and easy substitution of fonts that it is supposed to
empower.

I really can't see any significant corresponding benefit to this decision.
The documentation may be marginally improved, but Unicode has had no
problems that I know of by documenting new glyphs in an "Additional xyz
symbols" range. Add more padding in different glyph ranges if you like to
help avoid this, but it's no big deal if similar glyphs get split up into
a couple different ranges over the years.

I hope you will please reconsider this change that was introduced in 0.7
and revert back to the way things were in earlier SMuFL versions. Perhaps
the spec could make even more explicit that code points will not change
once SMuFL 1.0 is released, though new code points may be added.

Thank you very much for your consideration of this request.

Best regards,

Michael Good
VP of Research and Development
MakeMusic, Inc.



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