https://www.ctrl.blog/entry/creative-commons-unicode-fallback-font.html

[Lunokhod]

https://www.ctrl.blog/entry/creative-co ... -font.html
The fonts (further down the page, not in the blue image at the top) are shown in Chromium and Firefox but do not appear in Pale Moon.

[Night Wing]

If you mean the lettering in the table, it shows for me. If you mean the geek coding in the gray box, it also shows for me.

At this time, I'm using 64 bit linux Pale Moon 29.2.1 running in 64 bit linux Mint 20.1 (Ulyssa) Xfce.

[Moonchild]

Webmaster (and author) error.

CSS font unicode-ranges can be specified in a variety of formats but NOT in the way they did it.

@font-face {
font-display: swap;
font-family: CCSymbols;
font-synthesis: none;
src: url(CCSymbols.woff2) format(woff2),
url(CCSymbols.woff) format(woff);
unicode-range: u+a9, u+229c,
u+1f10d-f, u+1f16d-f;
}

The red values are incorrect ranges, as they effectively mean a negative range (ending at u+0000f). As a result, Goanna ignores the incorrect values and the font falls back to system fonts that don't include the characters.
The correct way to specify the unicode ranges he wants is:

unicode-range: u+a9, u+229c,
u+1f10d-1f10f, u+1f16d-1f16f;

[Lunokhod]

So I don't have those characters in my system fonts. Interestingly though it seems both Firefox and Chromium are getting them as webfonts rather than using some bundled font, because I tried toggling these in Firefox: gfx.downloadable_fonts.disable_cache false gfx.downloadable_fonts.enabled true and using $ chromium --disable-remote-fonts & to start Chromium, and then both didn't display the cc fonts. Whether it's a good thing they ignore the fact the values are negative or a potential problem I have no idea.

[Moonchild]

You don't seem to understand.
The page itself does use web fonts for the table which works everywhere, BUT their definition of the unicode range for the web font they use is wrong, so it falls back to system fonts. I don't think system fonts (that don't get updated normally or regularly) will be at unicode 13 level anywhere unless you explicitly install a replacement font yourself so yeah, the broken css means you'll get number boxes instead.
I'm not sure why Firefox and Chrome would display these wrong unicode ranges... Possibly another CSS parsing discrepancy that worked in Chrome and was copied by Firefox but is just wrong? You should be able to check if Firefox recognized the unicode range definition or not in its inspector under fonts for the element. Pale Moon only has 2 entries listed since the red ones are dropped for being invalid. If they also only show 2, then the fallback font for those glyphs will likely be an updated embedded font that has Unicode 13.

[Lunokhod]

Here's what the respective inspectors say when inspecting the 2nd from top CC character, visible in Firefox but not Pale Moon, at least I hope that's what I got in these screenshots:
https://pasteboard.co/K7RmG0o.png
https://pasteboard.co/K7RnHag.png

No doubt I don't fully understand, it just seemed interesting there was a difference. I don't have a lot of big font packages installed, or office suites and so on that might require them as deps, so it's not surprising I wouldn't have those on my system. It looks like Pale Moon can see where to get the font but is presumably told by the CSS not to use that character from it or something like that.

[Moonchild]

Firefox's devtools' inspector apparently no longer displays the font information as provided in the @font-face rule, instead having silly sliders that have no factual purpose in an inspector, so you cannot even see the difference. That's essential information they are leaving out.
Pale Moon's font display box clearly displays the rules resulting in the font load, provides a path to the font, and obviously excludes what I marked in red for the reason I indicated (invalid ranges)