Re: Proposal for Encoding Common Musical Notation in Unicode

Bertrand Émerit:

My name is Jim DeLaHunt. I am a software engineer who is subscribed to 
the W3C Music Notation group. Thank you for sharing your Unicode 
proposal with this list. I have a few comments for you. I hope you find 
them helpful.

On 2020-08-31 16:46, Bertrand Émerit wrote:
> Dear ladies and gentlemen,
>
> On September 30th I plan to submit the attached proposal to the 
> Unicode Consortium.…
> I will be honoured for any review or comment of the documents. Feel 
> free to forward as needed, and I would appreciate that you inform me 
> if you forward outside your organization.
>
> The proposal should fit nicely if not enrich (and certainly not make a 
> dent in, or replace) your current works, including SMuFL, MusicXML and 
> MEI.…


I have been following the Unicode Standard for a few years, as a 
participant on their lists. I see that you take the Unicode encoding 
process seriously. You have read the Unicode design principles, and 
section 12.11 “Musical Symbols”. Despite this care, I suspect that you 
will encounter resistance based on the design principle of "Plain text", 
and on the history of design decisions that music notation is outside 
the scope of Unicode.

The question of what is and is not "plain text" is a surprisingly 
difficult one. It is hard to make a concrete argument that music 
performance and music notation are in the same scope as, or a different 
scope from, letters and words and sentences. However, I suspect you will 
get qualitative arguments that music is out of scope for plain text. 
This will likely boil down to music being different than spoken 
language, and to people not presently embedding music notation in 
textual mechanisms. The presence of emoji in the Unicode Standard makes 
this argument harder, because emoji are pictures, which are different 
than spoken language. However, there is rich current practice of using 
emoji as pictures within textual mechanisms, dating back to Japanese 
mobile phones of the 2000's, and newspaper typography earlier.

Section 12.11 “Musical Symbols” is evidence that there was already a 
discussion about music notation being out of scope for Unicode. I would 
also point you to the analogous situation of mathematical markup.  
Mathematical expressions and layout are also out of scope for Unicode.  
The result was that parties interested in mathematical expressions got 
together and made a separate specification, MathML. I would argue that 
MusicXML, MNX, MEI, etc. are the analogues of MathML for music notation.

It looks like one of the motivations for this proposal is "to be able to 
let scores be text in textual documents and rendered by the text 
renderers of common platforms." I am concerned that having this proposal 
accepted into the Unicode Standard will not be sufficient accomplish 
this goal. You will also need the text renderers (or in OpenType font 
and Unicode terms, the text layout engine, the font format, and the 
glyph shaping engine) to add code which supports this proposal, and for 
those text renderers to get deployed on users' computers over time. Have 
you made contact with the leadership of these text renderers and got 
their interest?

There are other ways of mixing music notation and textual documents. 
This proposal is an approach that defines a form of music notation which 
fits within a text rendering environment. Your document points out 
another approach that renders music notation to an opaque image or 
visual form, and insert that in the textual documents. There are other 
approaches. TEI (an XML language for representing text documents) and 
MEI (an XML language for representing music notation) are working on 
ways in which MEI objects can be embedded in TEI documents. This creates 
a document representation which is richer than just TEI, and includes 
the full musical content of the MEI object. Another approach is 
application-level object linking. My word processor, LibreOffice, allows 
me to insert a Formula Object into a word-processing document. This 
provides a window into a mathematical expression editor, which contains 
the knowledge of representing expressions and rendering their correct 
appearance. It allows me to copy that Formula Object and paste into a 
compatible application's document, with the mathematical semantics 
preserved. You can imagine a word processor adding support for an MNX 
Object or an MEI object. That approach might address the user demand you 
are trying to serve.

I second Michael Good's suggestion that a next step be to create some 
software which demonstrates this encoding system in use. Writing 
software is in part an exploration of the problem space. You will 
understand the strengths and weaknesses of this approach much better 
when you can use it practically. You can use PUA codepoints temporarily 
for this prototyping. It would be powerful to get user feedback on how 
useful this integration approach is, in comparison with the "insert 
opaque image" approach or an MNX Object approach. What kinds of notation 
and formatting will it not be able to represent?  How severe are those 
limitations? What kinds of easy intermixing of notation with text will 
it permit? How beneficial are those opportunities?

This is a serious and interesting proposal. Thank you for putting it 
forward, and giving us all a new way of looking at the challenge of 
music notation. I would be happy to continue discussing it.

Best regards,
        —Jim DeLaHunt, software engineer, Vancouver, Canada

-- 
.   --Jim DeLaHunt, jdlh@jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
       multilingual websites consultant

       355-1027 Davie St, Vancouver BC V6E 4L2, Canada
          Canada mobile +1-604-376-8953

Received on Friday, 4 September 2020 01:05:15 UTC