I rather suspect this is silly but Is there any way to see here on Firefox what you see on e,g, Android?
For example if I enter Unicode decimal 128077 
what do you see?
Chrome has a device emulator, you can just hit F12 and specify the device display you want, and it will pretend it is Chrome on that device.
A thumbs up using Firefox 43.0.4 on a Windows 7 laptop.
And on Safari 9.0.2 on OS X 10.10.5
I see a little box saying “OIF44D”. Firefox 43.0.4, Vista 64 bit.
I had this feeling that something of this sort might be happening but no way to find out for myself.
Thanks
I guessing, WAG. These variations in the display of Unicode would be greater in email? I guess I could check that myself.
Which fonts contain which Unicode glyphs is always a mystery from the server / sender side. As is which fonts are installed on which device.
Even if you know by testing that *this *particular glyph works on *this *particular version of Android on *this *particular make and model and revision of hand held device tells you almost nothing of whether that glyph exists on any other particular device.
Support on smartphones for the emoji glyphs is growing rapidly because people want to send them in texts and have them visible at the other end. So arbitrary glyph support *ought *to be improving over time.
OTOH, the PTB of Unicode are now under ever-increasing pressure to approve ever more new and shiny emoji code points. So there’s an arms race between those approvals, the new shiny devices that display them, and the older devices that don’t know about the new ones. Yet.
As to email vs. browser, there ought to be very little difference. Not to mention that many people only view their email in a browser, so the difference is moot. The device either has a font that knows what &x123456 should look like, or it doesn’t.
Again the little box; the latest Firefox to my sorrow.
Still I think it’s probabably more to to with the font sets installed on the underlying operating system than anything else. This is just a temporary OS so II haven’t set it up much.
Actually, this hasn’t been true for a long time now. Many browers run the Adobe Flash and/or Java plugins, which in their default configurations will happily send a list of system fonts to any web server that requests it. It’s also trivially easy to detect system fonts using CSS + Javascript, so if all you need to do is to render a page differently according to what fonts are installed, that can be done entirely on the client side.
Yet some of us run neither Flash nor Java.
And you are to be commended for that, but as long as other people still run these plugins, it isn’t correct to say that the client’s installed fonts are “always a mystery” to the server.
It gets worse, your use of the unicode is not only subject to the browser you send it to, its subject to whatever the server side (eg straightdope.com ) has done to the font context sent to the browser.
The page could download a font from anywhere…
see http://www.html5rocks.com/en/tutorials/webfonts/quick/
However that can mean that the smart server side has set the font to ensure that it was displayed using a suitable font…
Not anymore, especially not on mobile. Java applets ceased to exist in the 2000s, after puttering along for a while in the 1990s, and Flash is going downhill as well, with modern HTML standards giving websites the ability to tell browsers to play video and audio directly, without plugins as such being involved. (Silverlight, Microsoft’s attempt at Flash, died on the vine because of this.)
One aspect of modern HTML and CSS relevant here is the fact it can be used to get the browser to load a font from a remote server and use that font to display text. It’s like the old ‘font’ tag, except it comes with a URL and the browser is smart enough to download the font.
Adobe itself currently claims a penetration rate of one billion desktop machines; third-party estimates put the relative penetration rate for desktops at around 95%. And in 2015 mobile devices accounted for only a third of all web traffic. Though it’s undeniable that Flash is on the decline, that fact does not effectively rebut my assertion that many browsers have it installed (and that it can therefore be used by servers to probe for system fonts). For any given website visit today, the server’s got about a 64% chance of being able to sniff the client fonts via the Flash plugin.
There’s no reason to check and see what fonts you have or don’t have–either use a web font or declare your fonts with fallbacks–eventually falling back to either serif, sans, or mono, which will just use the default font of that type on your system.
The only issue is that no one seems to have made a free web font that has emoji, or everyone would fall back to that. Well, that and no one expects people to be using Vista.