search

w3c / smufl

Standard Music Font Layout
https://w3c.github.io/smufl/latest/
214 stars 35 forks source link

On the relationship between the cmap OpenType table and the glyphnames.json information #220

Open dbuenzli opened 2 years ago

dbuenzli commented 2 years ago

This issue is similar to #219. Namely data integrity issues between OpenType data and the SMuFL JSON metadata.

In SMuFL the accidentalNatural glyph can be represented according to glyphnames.json by the code point U+E261 or the alternate character U+266E.

Naively I expected that a font cmap would map these two characters to the same glyph identifier. However taking the cmap table of the reference implementation font Bravura.otf, this doesn't seem to be the case.

U+266E maps to glyph identifier 13 and U+E261 to the glyph identifier 536. While inspection of the glyphs outlines – via this glyph inspector – seem to indicate they are identical, their advance in the hmtx table is different (169 for the former and 168 for the latter).

This raises again the question where data should be sourced from and which one should be trusted or take over (Personally I would tend to favour the OpenType information since eventually that's the one that will remain embedded e.g. in PDF files).

Maybe the standard should avoid duplicating data or at least provide strong data integrity constraints between the JSON data and the OpenType tables (e.g. in a cmap table, characters which are listed as alternates of another one must map to the same glyph id or at least to a glyph with same outlines and metrics).

dspreadbury commented 2 years ago

The advance widths data is reproduced in the JSON metadata files for applications that don't have ready access to internal values from the OpenType font tables. Furthermore, SMuFL is also intended to be at least somewhat font-format agnostic, so that it is not reliant on the specific implementation details of any particular font format.

However, it is obviously desirable that the values in the metadata files match the values in the font tables. The specification doesn't make any specific recommendations about how those values should be generated, and perhaps it could.

dbuenzli commented 2 years ago

Thanks for your answer.

I think it would be nice if the standard mentioned which metadata is unique to SMuFL (e.g. engraving defaults) and the one that is derived for convenience. And for the latter, how to compute it from the font data and mandates that they do not diverge. Otherwise it makes it harder for everyone to track down layout problems.

There's also a few integrity constraints that could be mentioned. For example, since AFAIU SMuFL essentially uses PUA codepoints as glyph ids, there should be an entry in the OpenType's font cmap for any codepoint (or glyph name's codepoint as per glyphname.json) mentioned in a font's SMuFL metadata. Otherwise the metadata talks about a glyph that can't be accessed in the OpenType font.