I love the discussion, but I’d like to also propose a more practical angle: Drop using a webfont or if that’s not an option make sure it’s cached well and the 4x in size likely won’t matter too much in the long run – possibly load it async, so text is visible without it. Unless you’re specifically building a font preview application, where most font requests will be “first requests” this should be doable.
LostKobrakai
mayel
Yeah that’d be simpler, but I haven’t seen a font that offers more than 8 scripts, and taking Noto Sans as an example it has 145 separate fonts for scripts that aren’t included in the main one.
0
mayel
Somebody made some per-region font packages, they each measure in megabytes: Releases · satbyy/go-noto-universal · GitHub
0
mayel
LostKobrakai
That’s indeed rather large. What about the “no webfont” option though? People still have fonts installed on their computers already and it likely supports the scripts they want to read content in.
0
mayel
They’re likely to have fonts installed that support their primary language(s), but we’d have to rely on their browser (if using sans-serif) or their OS (is using system-ui) using that font as the default. And it wouldn’t help a user when seeing content posted by someone else in a language not supported by their font.
0
mayel
Oh maybe the first part of my statement is incorrect if we rely on HTML tags? Declaring language in HTML
0
mayel
So yeah, while it seemed like a fun exercise, and I may yet come back to it sometime, I’ll probably just map the locales corresponding to latin and those for cyrillic, devanagari, greek, latin-ext, vietnamese , loading a small webfont in the first case, a larger one in the second case, and for all others try just leaving it to the OS and browser (at least until users report problems…). Will share what I come up with for this simpler scope in any case.
0
KungPaoChicken
It is possible to load (subsets of) a webfont dynamically in CSS by Unicode range, assuming that ranges for languages don’t change frequently:
Quote from the page:
For example, a site with many localizations could provide separate font resources for English, Greek and Japanese. For users viewing the English version of a page, the font resources for Greek and Japanese fonts wouldn’t need to be downloaded, saving bandwidth.
2
kip
ex_cldr Core Team
That’s interesting. But must be a bit tricky in practise (caveat being this is not my area of expertise)
- A given language take may map to more than script:
iex> Cldr.Locale.language_data["ja"]
%{primary: %{scripts: [:Jpan], territories: [:JP]}}
iex> Cldr.Locale.language_data["zh"]
%{
primary: %{scripts: [:Hans, :Hant], territories: [:CN, :HK, :MO, :SG, :TW]},
secondary: %{scripts: [:Bopo, :Phag], territories: [:ID, :MY, :TH, :US, :VN]}
}
- A given script can map to a non-contiguous set of codepoints:
iex> Unicode.Script.scripts.hangul
[
{4352, 4607},
{12334, 12335},
{12593, 12686},
...
{65490, 65495},
{65498, 65500}
]
- Some language, like Japanese, have multiple scripts, For Japanese, hiragana, katakana and kanji (Han in Unicode speak, which has 94,215 code points!):
iex> Unicode.Script.scripts.hangul
[
{4352, 4607},
{12334, 12335},
...
{65490, 65495},
{65498, 65500}
]
iex> Unicode.Script.scripts.katakana
[
{12449, 12538},
...
{110592, 110592},
{110880, 110882},
{110948, 110951}
]
So mapping a language code to the right scripts to the right code points is not a trivial exercise. Possible for sure but hard to see this being a general purpose solution.
1