Open Munter opened 11 years ago
AFAIK, rendering libraries must cycle through all their fonts until they either find one that has the given codepoint or run out of fonts.
But adding a webfont to the mix, might help them along.
(An aside: I'm still toying with an idea about having browsers rendering codepoints on a hidden canvas, check if it's a square (= missing codepoint) and report the result + browser/OS to us, somehow). Then we'd might get a fairly good idea about what's supported where.)
You could do it without the canvas tag by choosing a fallback font with known dimensions. You can construct a special font that supports the whole unicode range and falls back to a single character with an extremely large (and known) width (or advance.) That way, you can insert a character into the DOM, monitor its size, and if it becomes very large you know there is no support for it in the fonts you have on your machine.
I'm doing something similar in my webfont loader: https://github.com/bramstein/fonzie
On Mon, Sep 24, 2012 at 11:42 AM, Morten Siebuhr notifications@github.comwrote:
AFAIK, rendering libraries must cycle through all their fonts until they either find one that has the given codepoint or run out of fonts.
But adding a webfont to the mix, might help them along.
(An aside: I'm still toying with an idea about having browsers rendering codepoints on a hidden canvas, check if it's a square (= missing codepoint) and report the result + browser/OS to us, somehow). Then we'd might get a fairly good idea about what's supported where.)
— Reply to this email directly or view it on GitHubhttps://github.com/msiebuhr/charcod.es/issues/35#issuecomment-8812048.
Currently there is an inconsistent rendering of charcodes across platforms.
If there is a webfont available with a wide range of supported unicode chars, then that might be a better choice to give a more pleasant experience for all users.
We might even be able to switch fonts for certain blocks where there is missing support in our preferred font.