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

Render CJK glyphs locally #613

Closed
1ec5 opened this issue Dec 10, 2022 · 2 comments
Closed

Render CJK glyphs locally #613

1ec5 opened this issue Dec 10, 2022 · 2 comments

Comments

@1ec5
Copy link
Member

1ec5 commented Dec 10, 2022

Viewing the map in Chinese, Japanese, or Korean requires an inordinate number of requests for fontstack glyph PBFs because Chinese, Japanese, and Korean characters are spread out over so many 255-codepoint ranges. The map takes longer than usual to load, consumes more memory, and can feel more sluggish. This also affects viewing East Asia in any language, due to the city name glosses added in #592.

GL JS has a localIdeographFontFamily option for rendering CJK glyphs client-side on demand, in a manner not unlike how we’re rendering route shields. All we need to do is specify some font names that are likely to be on the system.

We have the opportunity to prioritize, say, a Japanese font when the user prefers Japanese labels. This is important because, in many cases, Unicode has conflated multiple mutually unintelligible characters from each CJKV country into the same Unicode codepoint. Because we try to show labels in the user’s preferred language, rather than the local language, we know which language to target worldwide, allowing us to overcome the challenges in gravitystorm/openstreetmap-carto#2208 #428 (comment) in terms of font selection.

/ref OpenHistoricalMap/issues#258

@1ec5
Copy link
Member Author

1ec5 commented Dec 12, 2022

localIdeographFontFamily is actually enabled by default with sans-serif as the font, so this issue would only track tailoring the font fallback list to the user’s preferred language. The browser’s sans-serif font might well resolve to a font designed for the user’s preferred language, so the only case where we might have a problem is if the user manually overrides the preference with a language= for a different CJK langauge. Quite the edge case, so I’m closing this issue as works-for-me unless we find that it’s actually a big deal.

@1ec5 1ec5 closed this as completed Dec 12, 2022
@1ec5
Copy link
Member Author

1ec5 commented Jan 11, 2023

The browser’s sans-serif font might well resolve to a font designed for the user’s preferred language

Confirmed in Firefox 108.0.1 on macOS by setting intl.accept_languages in about:config and observing the Yellow Sea label. The name is 黄海 in both Chinese and Japanese, but 海 is one of the unified characters that has a different form in Japanese than in Traditional or Simplified Chinese or Korean:

Chinese (zh) Japanese (ja)
黄海 黃海

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant