313037 - mozilla/firefox/camino don't render glyphs in private use area

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Mac, defect)

Description

[Jonathan Stern]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915

We're trying to display glyphs mapped to codepoints in the private use area by using character references 
and CSS. While windows versions of the mozilla browsers display the correct glyphs, the OS X versions do 
not. The glyphs are in a font we developed in-house, so to verify that this wasn't a problem unique to our 
font, I tried to display PUA characters in several fonts included with Mac OS X: specifically Big Caslon, 
STSong, and STHeiti. Thus far, I haven't found an example of a glyph from the PUA being rendered.

See the attached screenshot, which shows (from left to right) Safari, Mozilla, Firefox, and Camino.

Reproducible: Always

Steps to Reproduce:
1. Load attached HTML test case in mozilla, firefox or camino.
Actual Results:  
The character references are rendered as boxes.

Expected Results:  
Expected the glyphs to show up, as in Safari. (See attached screenshot.)

Comment 1

[Jonathan Stern]

Attachment: HTML testcase used to produce screenshot

Comment 2

[Jonathan Stern]

Attachment: Screenshot of Safari, Mozilla, Firefox and Camino displaying HTML test case.

Comment 3

[Jo Hermans]

dupe of bug 121540 ?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

changing component...

I don't think that this requires ATSUI, so this doen't seem like a dup of that
bug to me

Comment 5

[Hiro]

depend bug240841 ?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I really don't see why a Web browser *should* display private use area
characters.  The Web isn't private use, it's public, and Web content can't
depend on a specific font being installed.

Comment 7

[Simon Montagu :smontagu]

Large parts of the Web *are* private, in that can only be accessed with a login
or from within a firewall, but anyway the private use area isn't really private
in that sense: it's for characters "not specified by [the Unicode] standard and
whose use may be determined by private agreement among cooperating users" (Such
"private" agreements can be quite widespread, see
http://www.evertype.com/standards/csur/). I don't see any reason in principle
why a website shouldn't use characters in the PUA by "agreement among
cooperating users". For example, material for a university course on a language
not yet encoded in Unicode.

Comment 8

[Jonathan Stern]

The comment I'd originally typed was longer, but Simon beat me to the punch --and put it much better 
than I had. 

The only thing I have to add is that the project that led me to report this issue uses third-party software to 
wrap Mozilla; we install the necessary fonts with the application, so the user is guaranteed to have them.

Comment 9

[Jungshik Shin]

Confirming and making this depend on bug 254585. It's likely to be a dupe of bug
240841 in that they have the same root cause. Note also that in the screenshot
uploaded here, the font specification for STSong and STHeiti has no effect while
'Big Caslon' works (compare the Safari shot with Gecko shots)

Comment 10

[Josh Aas]

fixed on trunk by cairo