5 ms·

Systems have a way of finding fall-back fonts. At least on OS X (err, macOS) they will satisfy glyph requests in order from the font you specify, some built-in

by medgno 10y ago

Systems have a way of finding fall-back fonts. At least on OS X (err, macOS) they will satisfy glyph requests in order from the font you specify, some built-in fonts, and then any fonts that have the required glyphs. Finally, a "last resort" font is used to fill in any remaining glyphs[1]. A result of this is that if you ask for a character such as "𓀴" (U+13034 EGYPTIAN HIEROGLYPH A044) in a monospace font, the symbol you get back can be variable width. [1]: https://en.wikipedia.org/wiki/Fallback_font https://en.wikipedia.org/wiki/Fallback_font

pavanky 10y ago
And I see a boxes (on linux)
- aarongolliver 10y ago
  Same on win10/chrome. Works on edge though.
- kalleboo 10y ago
  On my Mac it gets displayed with "Noto Sans Egyptian Hieroglyhs" which appears to be included in the system (/Library/Application Support/Apple/Fonts/Language Support) but can be downloaded for other platforms from here https://www.google.com/get/noto/ https://www.google.com/get/noto/
- benkuykendall 10y ago
  That's not an inherent problem with GNU/Linux. Shows up fine for me because I have "ttf-ancient-scripts" (https://aur.archlinux.org/packages/ttf-ancient-fonts/ https://aur.archlinux.org/packages/ttf-ancient-fonts/) installed.
pcr0 10y ago
I see a box with these two lines inside it: 013 034 OSX 10.11.4
umanwizard 10y ago
Ah, so is that why emojis don't display correctly in vim? They spill out of the character's bounding box...
- legulere 10y ago
  That sounds more like a problem of your terminal. The basic problem is that Unicode characters (which may consist of as many codepoints as you like) have varying width. For instance Chinese has characters that are displayed over a width of two normal monospace characters. See this hacker news post: https://news.ycombinator.com/item?id=10206380 https://news.ycombinator.com/item?id=10206380 So the problem with emojis is that they aren't really specified to be full width or half width characters: https://ianrenton.com/blog/adventures-in-emoji/ https://ianrenton.com/blog/adventures-in-emoji/
  - legulere 10y ago
    Apparently emoji representations are defined to be wide by unicode 9 now: http://www.unicode.org/reports/tr11/tr11-31.html#Modifications http://www.unicode.org/reports/tr11/tr11-31.html#Modificatio...
the8472 10y ago
I have a font for that, but the character is unreadably small while it's perfectly fine for latin characters. Many other unicode symbols also suffer from this problem. E.g. ␀ is the printable version of the unprintable NUL (\0) control character, but it's so small at 13.3px / 10pt CSS font size that it's difficult to distinguish from the other control pictures. ␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟ ␠ ␡ How those look on display w/o pixel scaling: https://i.imgur.com/lAAyjXu.png https://i.imgur.com/lAAyjXu.png
- lucaspiller 10y ago
  They are also very small on my computer (Chrome on OS X 10.11.5, external non-'Retina' monitor), but they are vertically aligned instead of diagonal: http://i.imgur.com/kKfLYgx.jpg http://i.imgur.com/kKfLYgx.jpg Interestingly in Safari the hieroglyph is shown (still small though), I wonder why Chrome can't find it?
- heinrich5991 10y ago
  FWIW on my screen, they're really distinguishable: https://i.imgur.com/IdUK8MV.png https://i.imgur.com/IdUK8MV.png.
  - the8472 10y ago
    The spade symbol[0] is codepoint 9824, the acknowledge control picture[1] (␆) is codepoint 9222. They shouldn't be using the same glyph. [0] http://www.fileformat.info/info/unicode/char/2660/index.htm http://www.fileformat.info/info/unicode/char/2660/index.htm [1] http://www.fileformat.info/info/unicode/char/2406/index.htm http://www.fileformat.info/info/unicode/char/2406/index.htm
  - j4_james 10y ago
    That looks like your browser is somehow misinterpreting the character set of the page. What you're seeing appears to be something like code page 437 (https://en.wikipedia.org/wiki/Code_page_437 https://en.wikipedia.org/wiki/Code_page_437) rather than unicode. What browser/os are you using? Is it possible you're going through a proxy that is altering the HTTP headers?

by medgno 10y ago

pavanky 10y ago

And I see a boxes (on linux)

aarongolliver 10y ago
Same on win10/chrome. Works on edge though.
kalleboo 10y ago
On my Mac it gets displayed with "Noto Sans Egyptian Hieroglyhs" which appears to be included in the system (/Library/Application Support/Apple/Fonts/Language Support) but can be downloaded for other platforms from here https://www.google.com/get/noto/ https://www.google.com/get/noto/
benkuykendall 10y ago
That's not an inherent problem with GNU/Linux. Shows up fine for me because I have "ttf-ancient-scripts" (https://aur.archlinux.org/packages/ttf-ancient-fonts/ https://aur.archlinux.org/packages/ttf-ancient-fonts/) installed.

pcr0 10y ago

I see a box with these two lines inside it: 013 034 OSX 10.11.4

umanwizard 10y ago

Ah, so is that why emojis don't display correctly in vim? They spill out of the character's bounding box...

legulere 10y ago
That sounds more like a problem of your terminal. The basic problem is that Unicode characters (which may consist of as many codepoints as you like) have varying width. For instance Chinese has characters that are displayed over a width of two normal monospace characters. See this hacker news post: https://news.ycombinator.com/item?id=10206380 https://news.ycombinator.com/item?id=10206380 So the problem with emojis is that they aren't really specified to be full width or half width characters: https://ianrenton.com/blog/adventures-in-emoji/ https://ianrenton.com/blog/adventures-in-emoji/
- legulere 10y ago
  Apparently emoji representations are defined to be wide by unicode 9 now: http://www.unicode.org/reports/tr11/tr11-31.html#Modifications http://www.unicode.org/reports/tr11/tr11-31.html#Modificatio...

the8472 10y ago

I have a font for that, but the character is unreadably small while it's perfectly fine for latin characters. Many other unicode symbols also suffer from this problem. E.g. ␀ is the printable version of the unprintable NUL (\0) control character, but it's so small at 13.3px / 10pt CSS font size that it's difficult to distinguish from the other control pictures. ␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟ ␠ ␡ How those look on display w/o pixel scaling: https://i.imgur.com/lAAyjXu.png https://i.imgur.com/lAAyjXu.png

lucaspiller 10y ago
They are also very small on my computer (Chrome on OS X 10.11.5, external non-'Retina' monitor), but they are vertically aligned instead of diagonal: http://i.imgur.com/kKfLYgx.jpg http://i.imgur.com/kKfLYgx.jpg Interestingly in Safari the hieroglyph is shown (still small though), I wonder why Chrome can't find it?
heinrich5991 10y ago
FWIW on my screen, they're really distinguishable: https://i.imgur.com/IdUK8MV.png https://i.imgur.com/IdUK8MV.png.
- the8472 10y ago
  The spade symbol[0] is codepoint 9824, the acknowledge control picture[1] (␆) is codepoint 9222. They shouldn't be using the same glyph. [0] http://www.fileformat.info/info/unicode/char/2660/index.htm http://www.fileformat.info/info/unicode/char/2660/index.htm [1] http://www.fileformat.info/info/unicode/char/2406/index.htm http://www.fileformat.info/info/unicode/char/2406/index.htm
- j4_james 10y ago
  That looks like your browser is somehow misinterpreting the character set of the page. What you're seeing appears to be something like code page 437 (https://en.wikipedia.org/wiki/Code_page_437 https://en.wikipedia.org/wiki/Code_page_437) rather than unicode. What browser/os are you using? Is it possible you're going through a proxy that is altering the HTTP headers?