MakeMusic
SmartMusic Finale Garritan MusicXML

Standard Music Font Layout initiative

Moderator: Michael Good

Standard Music Font Layout initiative

Postby Daniel Spreadbury » Fri May 24, 2013 1:41 am

Dear list members,

Yesterday at the Music Encoding Conference in Mainz I announced an initiative I have been working on for the past few months as part of our work on a new scoring program for Steinberg. I am hoping to build a community of experts around the initiative, and so I would like to invite any list members who are interested in this project to get in touch with me.

You can see my slides from my conference presentation here:

<http://www.slideshare.net/dspreadbury/standard-music-font-layout>

There is also a web site for the Standard Music Font Layout (SMuFL), which you can find here:

http://www.smufl.org/

Thanks very much,

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534
Daniel Spreadbury, Steinberg
http://blog.steinberg.net
User avatar
Daniel Spreadbury
 
Posts: 13
Joined: March, 2014
Location: London, UK
Reputation: 0

Re: Standard Music Font Layout initiative

Postby L. Peter Deutsch » Fri May 24, 2013 7:56 am

Dear Daniel,

> http://www.smufl.org/

I think this is a wonderful initiative, but it is based on a premise that is so dreadfully destructive that I would rather see the entire project fail if it can't be overturned.

Think back just a few years to the horrible consequences of Microsoft "code pages" and the less horrible, but still terribly complex and awkward Apple
"Script Manager". It was these experiences and similar ones that led the many communities concerned with typography to develop Unicode. While Unicode is not perfect, and many applications don't implement it fully, it is now supported in all major OSs and languages, and has made a tremendous difference, especially on the Web.

Basing SMuFL on the Unicode Private Use Area is a huge step backwards. Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context. The consequence of this was that every library, application, and OS had to have machinery for keeping track of that context, passing it through APIs, and applying it when rendering was required. (As far as I know, only Apple actually did this systematically.) Users of fonts and applications had to "somehow just know" what code point mapping was to be applied. Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding.

I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

* "Some scoring applications cannot in any case access code points beyond
Unicode Plane 0." Fix them! It won't be any more work than trying to get them to adopt a new, uniform code point system, especially since (based on my examination of PDF output from multiple applications) they don't even
agree on how to parse visual symbols into code points (e.g., are stemmed
notes one glyph or two? or the combination of a staccato dot and an
accent?). The appropriate remedy here is that given the entrenchment of
16-bit representation, those applications can, and should, use UTF-16 for
strings (with surrogate pairs as needed), and 32-bit values for
characters. Even extending JavaScript to make this nearly transparent is
not difficult (I have a proposal nearly ready to submit to the JavaScript
committee, and would welcome collaborators). While fixing applications is not trivial, it is a better path than starting to splinter Unicode into a Babel of conflicting "standards" for the PUA.

* "Not targeting use in text-based applications– Although many characters
could be usefully used, it's impractical for end users to type characters
from the PUA anyway." What about copy and paste? And how users *type*
characters is a red herring. Specialized *input* mechanisms are a
completely separate topic from stored representation -- consider input of
Chinese characters.

Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them.

Please, please don't base SMuFL on the PUA. Please. Thank you.

L Peter Deutsch
L. Peter Deutsch
 
Posts: 205
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby David Webber » Fri May 24, 2013 10:12 am

L. Peter Deutsch wrote:Think back just a few years to the horrible consequences of Microsoft
"code pages"

This is not a valid analogy: 'code pages' were just to enable fonts for scripts with different 256 character sets. The proposal here is consistent with Unicode's aim of including all the characters you'd need in one font.

> Basing SMuFL on the Unicode Private Use Area is a huge step backwards.

It isn't perfect, but there may not be any other option.

L. Peter Deutsch wrote:Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context.

Well no. The 'bad old days' are exactly where we are now: at least those of us who need symbol fonts for music notation. This proposal aims to standardise the symbols (albeit within the private use area) so that different programs will be able to use the same fonts: all the program will need to do is have access to a list of fonts which conform to that particular usage of the private use area, and then it will be able to use any of them.

L. Peter Deutsch wrote:....Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding.

None of this is remotely relevant. If you have a MusicXML file (for example) you can parse it to find where the clefs, crotchets, and minims are in the music - it doesn't encode a character index or Unicode code point to tell you which character to draw. [This is quite different from an ascii text file which contains 1-byte numbers 65 66 67 ... which you have to assume correspond with certain glyphs.]

L. Peter Deutsch wrote:I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

* "Some scoring applications cannot in any case access code points beyond
Unicode Plane 0." Fix them! ...

Agreed.

Somebody wrote:they don't even agree on how to parse visual symbols into code points (e.g., are stemmed notes one glyph or two? or the combination of a staccato dot and an accent?).

It doesn't matter - all that is required is that the available glyphs are defined, and then software can use them in whatever combinations it needs.

L. Peter Deutsch wrote:The appropriate remedy here is that given the entrenchment of 16-bit representation, those applications can, and should, use UTF-16 for strings (with surrogate pairs as needed), and 32-bit values for characters....

I don't think unicode representations should be considered at all: the symbols will just go at given code points, which will allow programs to access the glyphs. Windows programs will be coded in terms of UTF-16LE
(with surrogate pairs as required). Other systems may use UTF-8 for all I know, or later UTF-32. The thing which sits between a program and the font file, is the font engine which must cope with this transparently. Music software shouldn't care about anything other than the code point.

L. Peter Deutsch wrote:* "Not targeting use in text-based applications– Although many characters could be usefully used, it's impractical for end users to type characters from the PUA anyway." What about copy and paste? And how users *type* characters is a red herring.

To a large extent yes. But some symbols need to be typed - eg in titles
'Sonata in Eb'. But software can provide assistance for these exceptional cases.

L. Peter Deutsch wrote:Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them. Please, please don't base SMuFL on the PUA. Please. Thank you.

As I see it, the current options are

1. Restrict applications to the current Musical Symbols area 2. Develop a convention for the private use area.

Last time I looked, the Unicode Musical Symbols area was inadequate. But even if you can get by with the glyphs which are there, if different fonts put the glyph origins in different places (and I see nothing to stop them) you're up the creek anyway. So the current Unicode spec isn't good enough for music notation applications.

That leaves option 2, which whilst not 100% desirable, isn't half as bad as you're painting it. If lots of music notation software starts using it, it may end up as a temporary measure which results in further development (by the appropriate organisation) of the Unicode musical symbols area. But if, for the moment, a wide variety of software authors can contribute to the development of the SMuFL standard, to make it as inclusive as possible, then in the long term Unicode can only benefit.

Dave

David Webber Mozart Music Software
http://www.mozart.co.uk/
David Webber
 
Posts: 148
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby Daniel Spreadbury » Fri May 24, 2013 10:27 am

All,

I'm in full agreement with David, who summarises the same points I would myself make: there's really no alternative to using the Private Use Area.

Although identified as a non-goal in the presentation I gave at the conference yesterday, I am not ruling out seeking ratification from the Unicode Consortium for the work we do on SMuFL in the fullness of time; indeed, there is precedent for initiatives to work in the PUA and develop a kind of transitional standard that is later presented to the Consortium and given its own "real" range. But I don't think we should start with that aim in mind at this early stage.

Might I suggest that further development about SMuFL move to the smufl-discuss mailing list, rather than clogging up the MusicXML list?

Thanks!

Daniel

wrote: ----- Sent by: Date: 2013-05-24 17:19


L. Peter Deutsch wrote:Think back just a few years to the horrible consequences of Microsoft
"code pages"

This is not a valid analogy: 'code pages' were just to enable fonts for scripts with different 256 character sets. The proposal here is consistent with Unicode's aim of including all the characters you'd need in one font.

> Basing SMuFL on the Unicode Private Use Area is a huge step backwards.

It isn't perfect, but there may not be any other option.

> Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context. <

Well no. The 'bad old days' are exactly where we are now: at least those of us who need symbol fonts for music notation. This proposal aims to standardise the symbols (albeit within the private use area) so that different programs will be able to use the same fonts: all the program will need to do is have access to a list of fonts which conform to that particular usage of the private use area, and then it will be able to use any of them.

L. Peter Deutsch wrote:....Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding.

None of this is remotely relevant. If you have a MusicXML file (for example) you can parse it to find where the clefs, crotchets, and minims are in the music - it doesn't encode a character index or Unicode code point to tell you which character to draw. [This is quite different from an ascii text file which contains 1-byte numbers 65 66 67 ... which you have to assume correspond with certain glyphs.]

L. Peter Deutsch wrote:I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

L. Peter Deutsch wrote:* "Some scoring applications cannot in any case access code points beyond Unicode Plane 0." Fix them!

Agreed.

David Webber wrote:they don't even agree on how to parse visual symbols into code points (e.g., are stemmed notes one glyph or two? or the combination of a staccato dot and an accent?).

It doesn't matter - all that is required is that the available glyphs are defined, and then software can use them in whatever combinations it needs.

L. Peter Deutsch wrote:The appropriate remedy here is that given the entrenchment of 16-bit representation, those applications can, and should, use UTF-16 for strings (with surrogate pairs as needed), and 32-bit values for characters....

I don't think unicode representations should be considered at all: the symbols will just go at given code points, which will allow programs to access the glyphs. Windows programs will be coded in terms of UTF-16LE
(with surrogate pairs as required). Other systems may use UTF-8 for all I know, or later UTF-32. The thing which sits between a program and the font file, is the font engine which must cope with this transparently. Music software shouldn't care about anything other than the code point.

Somebody wrote:* "Not targeting use in text-based applicationsâ€" Although many characters could be usefully used, it's impractical for end users to type characters from the PUA anyway." What about copy and paste? And how users *type* characters is a red herring.

To a large extent yes. But some symbols need to be typed - eg in titles
'Sonata in Eb'. But software can provide assistance for these exceptional cases.

L. Peter Deutsch wrote:Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them. Please, please don't base SMuFL on the PUA. Please. Thank you.

As I see it, the current options are

1. Restrict applications to the current Musical Symbols area 2. Develop a convention for the private use area.

Last time I looked, the Unicode Musical Symbols area was inadequate. But even if you can get by with the glyphs which are there, if different fonts put the glyph origins in different places (and I see nothing to stop them) you're up the creek anyway. So the current Unicode spec isn't good enough for music notation applications.

That leaves option 2, which whilst not 100% desirable, isn't half as bad as you're painting it. ÿIf lots of music notation software starts using it, it may end up as a temporary measure which results in further development (by the appropriate organisation) of the Unicode musical symbols area. ÿ But if, for the moment, a wide variety of software authors can contribute to the development of the SMuFL standard, to make it as inclusive as possible, then in the long term Unicode can only benefit.

Dave

David Webber Mozart Music Software
http://www.mozart.co.uk/

ÿÿPost your message to the list by sending it to .

ÿÿTo contact the list owner, send your message to ÿÿ ÿ .

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534
Daniel Spreadbury, Steinberg
http://blog.steinberg.net
User avatar
Daniel Spreadbury
 
Posts: 13
Joined: March, 2014
Location: London, UK
Reputation: 0

Re: Standard Music Font Layout initiative

Postby xan » Fri May 24, 2013 1:49 pm

Hi!

I'm not sure representing all those 800 glyphs in Unicode is practical. A product using MusicXML would have to find which one of those 800 glyphs to use to represent a note.

MusicXML already describes, for example, a note and its attributes by using XML attributes which is flexible and can easily be expanded to add more attributes if required. In this case, decoupling the semantics from the musical representation simplifies the software. I think SMuFL approach does the opposite, but then again I haven't looked at the details. So my apologies if I'm missing something.

For the ones of you who might be interested, here is my approach:

- I've looked at existing musical fonts and couldn't find an acceptable
(and free) one.
- So I used Type 3 (CR8 Software Solutions - I'm just a customer) to create the basic glyphs required. For example to define a quarter note you need a head, a stem and one flag plus how those basic glyphs are connected. The number of glyphs required using this approach is relatively small (even after adding digits and letters). All your software need is to provide a true type file with the basic glyphs and an XML file to define how to combine them.

If other people are using a similar approach it might be interested to define a simple norm that defines this Basic Musical Glyph map. For example, a true type file using this approach will always use Unicode 0038 to represent the G clef or Unicode 003E to define the upper flag.

Regards

Tino Rodriguez
http://45n93w.blogspot.com/


Dear Daniel,

> http://www.smufl.org/

I think this is a wonderful initiative, but it is based on a premise that is so dreadfully destructive that I would rather see the entire project fail if it can't be overturned.

Think back just a few years to the horrible consequences of Microsoft "code pages" and the less horrible, but still terribly complex and awkward Apple
"Script Manager". It was these experiences and similar ones that led the many communities concerned with typography to develop Unicode. While Unicode is not perfect, and many applications don't implement it fully, it is now supported in all major OSs and languages, and has made a tremendous difference, especially on the Web.

Basing SMuFL on the Unicode Private Use Area is a huge step backwards. Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context. The consequence of this was that every library, application, and OS had to have machinery for keeping track of that context, passing it through APIs, and applying it when rendering was required. (As far as I know, only Apple actually did this systematically.) Users of fonts and applications had to "somehow just know" what code point mapping was to be applied. Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding.

I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

* "Some scoring applications cannot in any case access code points beyond
Unicode Plane 0." Fix them! It won't be any more work than trying to get them to adopt a new, uniform code point system, especially since (based on my examination of PDF output from multiple applications) they don't even
agree on how to parse visual symbols into code points (e.g., are stemmed
notes one glyph or two? or the combination of a staccato dot and an
accent?). The appropriate remedy here is that given the entrenchment of
16-bit representation, those applications can, and should, use UTF-16 for
strings (with surrogate pairs as needed), and 32-bit values for
characters. Even extending JavaScript to make this nearly transparent is
not difficult (I have a proposal nearly ready to submit to the JavaScript
committee, and would welcome collaborators). While fixing applications is not trivial, it is a better path than starting to splinter Unicode into a Babel of conflicting "standards" for the PUA.

* "Not targeting use in text-based applications– Although many characters
could be usefully used, it's impractical for end users to type characters
from the PUA anyway." What about copy and paste? And how users *type*
characters is a red herring. Specialized *input* mechanisms are a
completely separate topic from stored representation -- consider input of
Chinese characters.

Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them.

Please, please don't base SMuFL on the PUA. Please. Thank you.

L Peter Deutsch
xan
 
Posts: 5
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby Daniel Spreadbury » Fri May 24, 2013 3:51 pm

xan wrote:I think SMuFL approach does the opposite, but then again I haven't looked at the details. So my apologies if I'm missing something.

I'd be interested to know what you think once you've taken the time to inform your opinion, but there's no hurry.

There isn't any intention that SMuFL should influence MusicXML directly; after all, as you say, MusicXML can happily declare the music semantically and provide hints for which music font should ideally be used to render the music.

SMuFL is intended to aid interoperability between music notation software by defining a common font format that is comprehensive, and not only worried about a handful of glyphs such as clefs and notes.

Daniel
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534
Daniel Spreadbury, Steinberg
http://blog.steinberg.net
User avatar
Daniel Spreadbury
 
Posts: 13
Joined: March, 2014
Location: London, UK
Reputation: 0

Re: Standard Music Font Layout initiative

Postby Nicolas Martin » Fri May 24, 2013 4:10 pm

Hi, It's a really great initiative.

We have began a similar analysis for our software but we found that using only a single true type font was not sufficient.

We are using a classification for all musical symbols (NoteHeads, Clefs, ), that define the symbols properties needed by an engraving engine (all note heads have two anchors, etc...)

Then a separate file is used to define for each symbol the mapping to a glyph and the values for its properties.

Kind Regards,

Nicolas Martin

2013/5/24
xan wrote:Hi!

I'm not sure representing all those 800 glyphs in Unicode is practical. A product using MusicXML would have to find which one of those 800 glyphs to use to represent a note.

MusicXML already describes, for example, a note and its attributes by using XML attributes which is flexible and can easily be expanded to add more attributes if required. In this case, decoupling the semantics from the musical representation simplifies the software. I think SMuFL approach does the opposite, but then again I haven't looked at the details. So my apologies if I'm missing something.

For the ones of you who might be interested, here is my approach:

- I've looked at existing musical fonts and couldn't find an acceptable
(and free) one.
- So I used Type 3 (CR8 Software Solutions - I'm just a customer) to create the basic glyphs required. For example to define a quarter note you need a head, a stem and one flag plus how those basic glyphs are connected. The number of glyphs required using this approach is relatively small (even after adding digits and letters). All your software need is to provide a true type file with the basic glyphs and an XML file to define how to combine them.

If other people are using a similar approach it might be interested to define a simple norm that defines this Basic Musical Glyph map. For example, a true type file using this approach will always use Unicode 0038 to represent the G clef or Unicode 003E to define the upper flag.

Regards

Tino Rodriguez
http://45n93w.blogspot.com/



Dear Daniel,

http://www.smufl.org/
>

I think this is a wonderful initiative, but it is based on a premise that is so dreadfully destructive that I would rather see the entire project fail if it can't be overturned.

Think back just a few years to the horrible consequences of Microsoft
"code pages" and the less horrible, but still terribly complex and awkward Apple "Script Manager". It was these experiences and similar ones that led the many communities concerned with typography to develop Unicode. While Unicode is not perfect, and many applications don't implement it fully, it is now supported in all major OSs and languages, and has made a tremendous difference, especially on the Web.

Basing SMuFL on the Unicode Private Use Area is a huge step backwards. Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context. The consequence of this was that every library, application, and OS had to have machinery for keeping track of that context, passing it through APIs, and applying it when rendering was required. (As far as I know, only Apple actually did this systematically.) Users of fonts and applications had to "somehow just know" what code point mapping was to be applied. Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding. I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

* "Some scoring applications cannot in any case access code points beyond Unicode Plane 0." Fix them! It won't be any more work than trying to get them to adopt a new, uniform code point system, especially since
(based on my examination of PDF output from multiple applications) they don't even agree on how to parse visual symbols into code points (e.g., are stemmed notes one glyph or two? or the combination of a staccato dot and an accent?). The appropriate remedy here is that given the entrenchment of 16-bit representation, those applications can, and should, use UTF-16 for strings (with surrogate pairs as needed), and 32-bit values for characters. Even extending JavaScript to make this nearly transparent is not difficult (I have a proposal nearly ready to submit to the JavaScript committee, and would welcome collaborators). While fixing applications is not trivial, it is a better path than starting to splinter Unicode into a Babel of conflicting "standards" for the PUA.
* "Not targeting use in text-based applications– Although many characters could be usefully used, it's impractical for end users to type characters from the PUA anyway." What about copy and paste? And how users *type* characters is a red herring. Specialized *input* mechanisms are a completely separate topic from stored representation -- consider input of Chinese characters.

Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them.

Please, please don't base SMuFL on the PUA. Please. Thank you.

L Peter Deutsch

------------------------------**------------------------------** Post your message to the list by sending it to .

To contact the list owner, send your message to [email protected]**com> .

<http://cgi.mail-list.com/u?**ln=musicxml&nm=nicolas.martin%**>
> 40arobas-music.com

-- Nicolas Martin Chef de projet // Arobas Music
http://www.guitar-pro.com
Nicolas Martin
 
Posts: 1
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby xan » Fri May 24, 2013 4:56 pm

Well... the devil is in the details.

Your page states:
"The aim of the Standard Music Font Layout (SMuFL) is to provide the basis for music font mapping for the age of Unicode and OpenType fonts"

Here are my comments.

- Unicode represents "text". It doesn't define how that text is displayed
(font). Your standard seems to use Unicode to define glyphs.
- Your standard maps over 800 Unicode characters to glyphs. A font will need to provide a representation of all those characters to be complete. That sounds like an expensive proposition.
- Your standard will live inside an application. To exchange music we already have several "standards" besides MusicXML. The software using your standard will parse the XML file and obtain the note's attributes
(for example). Then based on the attributes will obtain the corresponding Unicode character from your list and pull the glyph from the selected font file. So the way a read it aims at standardizing musical fonts, which I think is a good idea. There are several alternatives to this approach (use a standard library that draws the glyph is just an example). I'm not sure your solution is a cheap one.
- I'm not sure all musical symbols can be represented this way.

Regards Tino Rodriguez
http://45n93w.blogspot.com/



xan wrote:I think SMuFL approach does the opposite, but then again I haven't looked at the details. So my apologies if I'm missing something.

I'd be interested to know what you think once you've taken the time to inform your opinion, but there's no hurry.

There isn't any intention that SMuFL should influence MusicXML directly; after all, as you say, MusicXML can happily declare the music semantically and provide hints for which music font should ideally be used to render the music.

SMuFL is intended to aid interoperability between music notation software by defining a common font format that is comprehensive, and not only worried about a handful of glyphs such as clefs and notes.

Daniel
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 |
www.steinberg.net Managing Director: Andreas Stelling, Kazunori Kobayashi Registration Court: Hamburg HRB 86534
xan
 
Posts: 5
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby xan » Fri May 24, 2013 5:09 pm

Hi,

Thanks for your kind response. I had to use anchors too to be able to handle font sizes. Let's start a new thread instead of hijacking this one. We can explore the problems there.

Regards

Tino Rodriguez
http://45n93w.blogspot.com/


Hi, It's a really great initiative.

We have began a similar analysis for our software but we found that using only a single true type font was not sufficient.

We are using a classification for all musical symbols (NoteHeads, Clefs, ), that define the symbols properties needed by an engraving engine (all note heads have two anchors, etc...)

Then a separate file is used to define for each symbol the mapping to a glyph and the values for its properties.

Kind Regards,

Nicolas Martin

2013/5/24
xan wrote:Hi!

I'm not sure representing all those 800 glyphs in Unicode is practical. A product using MusicXML would have to find which one of those 800 glyphs to use to represent a note.

MusicXML already describes, for example, a note and its attributes by using XML attributes which is flexible and can easily be expanded to add more attributes if required. In this case, decoupling the semantics from the musical representation simplifies the software. I think SMuFL approach does the opposite, but then again I haven't looked at the details. So my apologies if I'm missing something.

For the ones of you who might be interested, here is my approach:

- I've looked at existing musical fonts and couldn't find an acceptable
(and free) one.
- So I used Type 3 (CR8 Software Solutions - I'm just a customer) to create the basic glyphs required. For example to define a quarter note you need a head, a stem and one flag plus how those basic glyphs are connected. The number of glyphs required using this approach is relatively small (even after adding digits and letters). All your software need is to provide a true type file with the basic glyphs and an XML file to define how to combine them.

If other people are using a similar approach it might be interested to define a simple norm that defines this Basic Musical Glyph map. For example, a true type file using this approach will always use Unicode 0038 to represent the G clef or Unicode 003E to define the upper flag.

Regards

Tino Rodriguez
http://45n93w.blogspot.com/



Dear Daniel,

http://www.smufl.org/
>

I think this is a wonderful initiative, but it is based on a premise that is so dreadfully destructive that I would rather see the entire project fail if it can't be overturned.

Think back just a few years to the horrible consequences of Microsoft
"code pages" and the less horrible, but still terribly complex and awkward Apple "Script Manager". It was these experiences and similar ones that led the many communities concerned with typography to develop Unicode. While Unicode is not perfect, and many applications don't implement it fully, it is now supported in all major OSs and languages, and has made a tremendous difference, especially on the Web.

Basing SMuFL on the Unicode Private Use Area is a huge step backwards. Rather than expanding Unicode, it takes us back to the bad old days where parts of the code space were routinely used for private, conflicting purposes that could only be known from context. The consequence of this was that every library, application, and OS had to have machinery for keeping track of that context, passing it through APIs, and applying it when rendering was required. (As far as I know, only Apple actually did this systematically.) Users of fonts and applications had to "somehow just know" what code point mapping was to be applied. Combining documents from multiple sources into a single document, or copy-and-paste, was in general impossible. Identifying what mapping(s) applied to (what parts of) documents required vendor- or even application-specific coding. I find the arguments against using Unicode planes beyond the BMP unpersuasive, and they have the harmful effect of weakening Unicode for temporary convenience of a few applications.

* "Some scoring applications cannot in any case access code points beyond Unicode Plane 0." Fix them! It won't be any more work than trying to get them to adopt a new, uniform code point system, especially since
(based on my examination of PDF output from multiple applications) they don't even agree on how to parse visual symbols into code points (e.g., are stemmed notes one glyph or two? or the combination of a staccato dot and an accent?). The appropriate remedy here is that given the entrenchment of 16-bit representation, those applications can, and should, use UTF-16 for strings (with surrogate pairs as needed), and 32-bit values for characters. Even extending JavaScript to make this nearly transparent is not difficult (I have a proposal nearly ready to submit to the JavaScript committee, and would welcome collaborators). While fixing applications is not trivial, it is a better path than starting to splinter Unicode into a Babel of conflicting "standards" for the PUA.
* "Not targeting use in text-based applications– Although many characters could be usefully used, it's impractical for end users to type characters from the PUA anyway." What about copy and paste? And how users *type* characters is a red herring. Specialized *input* mechanisms are a completely separate topic from stored representation -- consider input of Chinese characters.

Everything else about SMuFL sounds really great. As a sometime developer of notation software, I would be ecstatic to have access to a freely redistributable font with a comprehensive set of musical symbols and a standard way of encoding them.

Please, please don't base SMuFL on the PUA. Please. Thank you.

L Peter Deutsch

------------------------------**------------------------------** Post your message to the list by sending it to .

To contact the list owner, send your message to [email protected]**com> .

<http://cgi.mail-list.com/u?**ln=musicxml&nm=nicolas.martin%**>
> 40arobas-music.com

-- Nicolas Martin Chef de projet // Arobas Music
http://www.guitar-pro.com
xan
 
Posts: 5
Joined: March, 2014
Reputation: 0

Re: Standard Music Font Layout initiative

Postby David Webber » Sat May 25, 2013 3:41 am

> - Unicode represents "text"...

Not exactly. Unicode attempts to catalogue a lot more symbols than just text. Musical, mathematical, and other symbols are included. They are known as 'glyphs' to emphasise that they are not just an alphabet.

> Your standard seems to use Unicode to define glyphs.

Unicode, at the most basic level, *is* just a mapping of glyphs onto numbers ('code points').

xan wrote:Your standard maps over 800 Unicode characters to glyphs. A font will need to provide a representation of all those characters to be complete. That sounds like an expensive proposition.

It does. I'm not (yet?) convinced it needs that many, but I've joined the SMuFL group.

xan wrote:- Your standard will live inside an application. To exchange music we already have several "standards" besides MusicXML. The software using your standard will parse the XML file and obtain the note's attributes
(for example). Then based on the attributes will obtain the corresponding Unicode character from your list and pull the glyph from the selected font file. So the way a read it aims at standardizing musical fonts, which I think is a good idea. There are several alternatives to this approach (use a standard library that draws the glyph is just an example). I'm not sure your solution is a cheap one.
- I'm not sure all musical symbols can be represented this way.

You can regard the standard library which draws the glyph as a 'font engine', and the data base of information on how to draw each glyph (at any particular size) as a 'trueType/openType font file'. So you are not suggesting an alternative to the wheel - you are suggesting that it should be reinvented. :-)

Dave

David Webber Mozart Music Software
http://www.mozart.co.uk/
David Webber
 
Posts: 148
Joined: March, 2014
Reputation: 0

Next

Who is online

Users browsing this forum: No registered users and 2 guests

cron