[smufl-discuss] Re: Please restore immutable code points

[Joseph Berkovitz]

Daniel,

+1… I would like to second Michael’s suggestion on this point. The canonical names are very useful but I don’t think this mapping should be absolutely required.

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC
"Your music, everywhere"

On Dec 19, 2013, at 11:12 AM, Good, Michael <[hidden email]> wrote:

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

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