@tom3 and another Unicode wonks—here’s a mystery. When this article:
Gets posted to Discourse:
The apple character in the title gets converted to a box in Safari:
But it’s fine in Arc, Brave, and Firefox (and I assume other Chrome browsers):
Even more oddly, Safari has no problem rendering the apple character on the main TidBITS site.
Any clue what’s going on?
Clicking on both links gave me the correct Apple symbol in Safari.
Yeah, but then go to the bottom of that page and click the link at "Join the discussion in the TidBITS Discourse forum". In Safari that returns a black box instead of — at least at the top of the page. The tab title shows correctly.
Sorry, my bad, I wasn’t sure what “Discourse” was. Should have kept quiet.
I think some fonts do not have the Apple character. Is it possible Discourse is forcing Safari to use one of those? Or that that system won’t display characters in the Unicode Private Use area (Apple is at U+F8FF)?
On tidbits.com, the heading’s font is proximanova-condensed with Helvetica as a fallback. On talk.tidbits.com, the heading is Arial, with only the keyword sans-serif as a fallback. The version of the Arial font in macOS seems to lack the Apple character but whatever Safari uses as the sans-serif font does have it.
My hunch is the other browsers detect there’s no glyph at the Apple character codepoint in Arial and use one from the sans-serif font instead. On tidbits.com, that’s not necessary because proximanova has the glyph.
Maybe you can the font-family on Discourse to have something other than Arial as the preferred font. I don’t know if Discourse has a supported method for overriding its defaults (it looks like it does); it uses custom variables stored in color_definitions.scss that gets turned into a .css file by a build step; if there’s not a GUI for Discourse administrators to set the font-family(s), maybe it supports a “custom.css” or something that’s meant for local overrides.
:root {
--font-family: Helvetica, Arial, sans-serif;
--heading-font-family: Helvetica, Arial, sans-serif;
}
Ah, thanks for the nudge! I looked and Discourse has default and default headline fonts, both of which were set to Arial. I switched to Helvetica, and now the apple character is showing in Safari. Hopefully it’s not too different otherwise—it didn’t stand out to me as a problematic change.
I’m a bit late, but I think I can also confirm this. I just did a wget on the article’s page and did a hex-dump. The start of the page looks like:
$ hexdump -C index.html
00000000 3c 21 44 4f 43 54 59 50 45 20 68 74 6d 6c 3e 0a |<!DOCTYPE html>.|
00000010 3c 68 74 6d 6c 20 6c 61 6e 67 3d 22 65 6e 22 3e |<html lang="en">|
00000020 0a 20 20 3c 68 65 61 64 3e 0a 20 20 20 20 3c 6d |. <head>. <m|
00000030 65 74 61 20 63 68 61 72 73 65 74 3d 22 75 74 66 |eta charset="utf|
00000040 2d 38 22 3e 0a 20 20 20 20 3c 74 69 74 6c 65 3e |-8">. <title>|
00000050 69 4f 53 20 31 37 2e 33 20 53 74 61 6e 64 73 20 |iOS 17.3 Stands |
00000060 4f 75 74 20 66 72 6f 6d 20 4f 74 68 65 72 20 ef |Out from Other .|
00000070 a3 bf 4f 53 20 55 70 64 61 74 65 73 20 77 69 74 |..OS Updates wit|
00000080 68 20 53 74 6f 6c 65 6e 20 44 65 76 69 63 65 20 |h Stolen Device |
As you can see (on rows 60 and 70), the position of the Apple glyph is the UTF-8 sequence ef a3 bf, which decodes to the Unicode code-point f8ff.
So it’s definitely a case of the chosen font not having that character.
I find it rather surprising that Safari doesn’t perform font substitution the way other browsers do. I thought that was pretty much universal these days - if the selected font doesn’t have the required glyph, automatically select a different font that does have it.
And I’m also a bit surprised that Arial doesn’t have that. I would have expected Apple to make sure that all their bundled fonts include that character.
I just checked on my (Sonoma) Mac and Arial is stored in /System/Library/Fonts/Supplemental/Arial.ttf, so this is an Apple-bundled font, not one from a third-party (like Microsoft).
FWIW, Helvetica is in /System/Library/Fonts/Helvetica.ttc. And I see that it has an Apple copyright alongside the Linotype copyright. So maybe that’s the difference - Arial only has a Monotype copyright and it’s in the “Supplemental” directory. It would appear that Apple has contracted for a customized Helvetica but they are just bundling a stock/licensed Arial.
Helvetica is better than Arial anyway. I will be entertaining no responses at this time. 
As Tom mentioned, U+F8FF is in the Private Use Area (PUA), I’m sure Safari does substitution in other areas. I think it’s implicit, if not explicit, that when you use the PUA that you ensure a font with the intended glyph is available. A fallback font could have a different glyph at that codepoint so Apple’s decision is reasonable, no glyph is better than the wrong glyph. Chrome and Firefox are taking a chance but it may be that in practice their gamble pays off more often than not; it’s also possible that they handle U+F8FF differently just because it’s often used for the Apple.
I agree 1,000,000%. Helvetica manages resizing as well as weights easily and beautifully. You tend to see Helvetica in street and highway and street signs. film, magazine, newspaper and TV titling, as well as on packaging for food and pharmaceutical drugs, etc., etc., etc. for this reason.
There are also many, many, many more variants of Helvetica. There’s a good analysis here:
GIVE ME HELVETICA OR GIVE ME DEATH!
Clearly, you need a T-shirt with that saying. :-)
Neatly typeset in Comic Sans, I think.
The word “Helvetica” should be in Helvetica. The word “death” should be in Arial. The rest in Comic Sans.
AARRRRRGGGGGHHHH!!!
A fate worse than death!!! The horror, the horror!
It’s even more awful than Arial!!!
Not even close. There’s nothing wrong with Comic Sans as a font when used appropriately. The problem with Comic Sans is that people treat it as a general-purpose font instead of the specialty display font it was designed to be.
Arial, on the other hand, is a poorly designed Helvetica knock-off with no elegance or character. It’s ugly and hard on the eyes. Arial should never be used in any context, especially if Helvetica is available.
This is true, but there are so many issues that are problematic, including almost nonexistent kerning; everything has the same thickness. Comic Sans’s letters in body copy sucks, mostly because of the kerning problem. But most of the letters just don’t look well together, which makes copy in Comic Sans harder to read, and it makes content in most instances just plain old ugly, confusing, and dorky looking.
There are so many millions of fonts out there, including many freebies, that work better with reading or spoken content. Comic Sans does work well in some instances, especially cartoons, games, invitations, etc.
Apropos of this sidetrack…