Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicode values outside Basic Multilingual Plane cannot be processed correctly. #168

Closed
lixiangliu opened this issue Dec 12, 2015 · 8 comments

Comments

@lixiangliu
Copy link

For example:

font.stringToGlyphs('\u{2f894}') will return an array with two “.nodef” in it.
2015-12-12 21 26 42

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

@lixiangliu lixiangliu changed the title The unicode value outside Basic Multilingual Plane cannot be processed correctly. Unicode values outside Basic Multilingual Plane cannot be processed correctly. Dec 12, 2015
@lixiangliu
Copy link
Author

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

@fdb
Copy link
Contributor

fdb commented Dec 15, 2015

Would it help if we parsed a different cmap format?

@lixiangliu
Copy link
Author

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

@Jolg42
Copy link
Member

Jolg42 commented Jul 29, 2016

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

@fdb fdb closed this as completed Jul 31, 2016
@fdb
Copy link
Contributor

fdb commented Jul 31, 2016

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
Copy link

amart1n commented Dec 5, 2016

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
Copy link
Member

Jolg42 commented Dec 5, 2016

@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
Copy link
Collaborator

fpirsch commented Mar 19, 2018

Closed through #338

@fpirsch fpirsch closed this as completed Mar 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants