Unicode values outside Basic Multilingual Plane cannot be processed correctly.

[lixiangliu]

For example:

font.stringToGlyphs('\u{2f894}') will return an array with two “.nodef” in it.

If font.glyphs.glyphs[...] is being used to access a certain glyph directly, then it will return an object with an undefined unicode value.

[lixiangliu]

It seems this is the limitation of 16-bit mapping in cmap format 4.

[fdb]

Would it help if we parsed a different cmap format?

[lixiangliu]

In that case, cmap format 12 is probably a good choice then, it’s widely adopted and also the superset of format 4.

[Jolg42]

@lixiangliu cmap 12 read support was just added with PR #207 😉

[fdb]

Closing this issue because of the cmap 12 support. @lixiangliu let me know if there's something else that blocks you from working with these fonts.

[amart1n]

The same issue still exists with values outside the BMP. Looks like it may be because of the limitations of charCodeAt() https://mathiasbynens.be/notes/javascript-unicode#code-point-from-string

[Jolg42]

@amart1n You're right charCodeAt() "will always return a value that is less than 65536." (ref)

codePointAt() is the new method to use but because of the compatibility we would need to add Mathias's polyfill: https://github.com/mathiasbynens/String.prototype.codePointAt and use it instead of charCodeAt() to have a full Unicode support.

[fpirsch]

Closed through #338