You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
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
The text was updated successfully, but these errors were encountered: