How to debug missing glyphs present on system?

[treyharris]

Hi Roland et. al.—

I thought I had unicode-font-setup working correctly, but then I noticed I was missing the character ("⁴" (8308, 2074, ⁴) SUPERSCRIPT FOUR (NUMBER 4)). It's definitely available on my system; here's a PopChar screenshot:

If you're not familiar with PopChar, the black characters are ones available in the default font (Liberation Mono), the blue are available in some installed font, and the fonts in the sidebar marked with a circle are the fixed-width fonts installed that include the glyph in question. Note specifically that while Liberation Mono does not include the superscript 4, Monaco does include it.

Now, here's Emacs showing that Unicode block and the value of unicode-fonts-block-font-mapping centered at that block:

One would think from this that since Monaco is an available font for the Superscripts and Subscripts block, it would display, but it doesn't. (Note from comparing the PopChar and Emacs shots that all the block characters are available in some font or another, but only the "ⁿ" (8319, 207F, ⁿ) SUPERSCRIPT LATIN SMALL LETTER N is shown. That would initially make sense because PopChar displays it in black, meaning my default Liberation Mono includes it.

But upon further examination it's weirder: Liberation Mono includes the glyphs x2090–x2094, but Emacs does not display those glyphs in the block table, either.

How might I go about trying to debug this? I tried evaluating:

(unicode-fonts-setup nil t)

to regenerate the table, but that didn't seem to do anything (it returned nil).

[rolandwalker]

@treyharris you are suddenly omnipresent.

I am partly AWK right now, but I can tell you this happens because of some separate "overrides" which are per-glyph tweaks.

The overrides are stored in a separate monster customizable variable, which has drifted out of date as I have made a lot of changes to the main mapping. Perhaps I should not have tried to expose everything in customize. Within the constraint of customize, it was harder to elegantly express additions or subtractions on some range, so basically all the fonts have to be recapitulated there.

If you set unicode-fonts-ignore-overrides to nil, you should see expected behavior for the characters you are looking at. However, it would be better for me to work through the override settings, which is on my todo.

There are a number of debugging functions in the package, but not one to retrospectively answer the question "how did font x get chosen for character y?". I would be happy to add something along those lines.

[grettke]

Good evening. I'm running into a similar scenario; here is what is happening

• GNU Emacs 24.5.1 (x86_64-apple-darwin15.4.0, NS apple-appkit-1404.46) of 2016-06-08 on vela
• unicode-fonts version: latest
• Customizations: none
• Context: OS X. Symbola installed.
• Test case is codepoint #x1f352 "CHERRIES".
• Expected behavior: Unmapped fonts will fallback to Symbola.
• Actual behavior: CHERRIES does not display in Emacs. However it does display in PopChar and TextEdit.
• Thoughts: This article shows this code for setting a fallback manually (set-fontset-font "fontset-default" nil (font-spec :size 20 :name "Symbola")) and I tried that and it worked: CHERRIES shows up in Emacs now. The thing is that I see that unicode-fonts does the same thing; the fallbacks are Symbola and then Quivira. I can see some symbols successfully falling back to Quivira like RAINBOW for example. Both Symbola and Quovira have a symbol for RAINBOW, so I feel like the fallback mechanism is working. I wondered if I can't load the font in emacs so I set the frame text to Symbola and that succeeded. That is what got me to this post. I wondered if a chunk was skipped? I didn't try setting unicode-fonts-ignore-overrides to nil because it was already nil.
• Question: What might I do next and what do you think here?

[grettke]

@treyharris @rolandwalker How did you move forward with this? For now I'm manually setting the fallback to Symbola.