notdef in Oculi text font makes it a bad choice

Thomas Phinney

Currently Typedrawers is using Oculi for body text.

I quite like the typeface, but the notdef is a joke, both literally and figuratively. It needs a traditional notdef rather than a fun one, if it is going to work well for Typedrawers.

The skull-styled notdef in Oculi is just confusing, especially at normal text size. Here it is enlarged:

jeremy tribby

I don’t have a strong opinion about this but CSS makes it pretty easily to define a fallback font stack that includes Noto or similar, and I think a stylistically different but correct glyph is probably better than changing a .notdef to be more clearly a .notdef? When TD switched to Oculi I think James expressed that the forum software makes theming a real pain, though, so maybe that approach is less viable here

Thomas Phinney

Having a good/better fallback stack would be preferable to seeing notdefs, sure!

Though I suspect it is also the case that folks here are likely to at least occasionally use characters unsupported by most stacks.

jeremy tribby

True, I suppose of all places this might be where it would happen

James Hultquist-Todd

I'll see what I can do about better implementing a fallback. 

Kent Lew

Seems like behavior might also depend upon browser? Here is what I see in Firefox:

Which is more informative than a .notdef, imo. Especially in this kind of situation.

Thomas Phinney

It may depend on which fonts of the fallback stack we each have? I think you are getting some kind of Last-Resort–like font.

Kent Lew

Not sure why that would be. The fallback stack is quite long, and the first couple after Oculi are system-level fonts. And yet, you are seeing the .notdef from Oculi instead of a fallback or Last-Resort. Why is that? Why wouldn’t I also see Oculi’s .notdef instead of a fallback?

As I said, I think the fallback behavior may be somewhat browser-specific if no font in the stack has the char encoded.

Thomas Phinney

When I switch from Chrome to Firefox, I get the same thing as Kent, so he must be right in that it is a browser-specific behavior. (NOTE: we are looking at https://typedrawers.com/discussion/5060/ipa-best-practice/p4)

Firefox is not showing a notdef at all. We are instead getting a Last-Resort–style glyph (or assembly of components, more likely) that shows the exact missing codepoint! Which is certainly preferable to a notdef.

James Hultquist-Todd

Alright, so it seems the post referenced above is the only one that is showing the notdef. Every other post in that thread seems to use a fallback font. I tried cycling through all the fallback system fonts and it looks like none of them have support for uniAB57 (the character that should be represented).

Khaled Hosny

Thomas Phinney said:

Firefox is not showing a notdef at all.

That is a feature of Firefox and a handful of other applications/text layout libraries. Instead of showing the font’s .notdef glyph (and this thread shows one of the reasons why showing .notdef glyph is not always a good idea), they show a so-called hex box showing the Unicode of the missing character (the hex box is “drawn” on the fly, so no last resort font is used).

Kent Lew

For the record, Denis’s post also included instances of uniAB55–AB59 and AB4E in the last paragraph. 

Which is another reason that the “hex box” solution is really useful in this forum, rather than bare .notdef. 

(And in general, I might suggest. But probably not practical for all renderers to implement.)

Kent Lew

[Oops. Just realized I forgot to turn off my custom stylesheet applying a WIP font for text here on TD before taking that screenshot. Oh well. Inadvertent public preview.]