Bug 94319 implemented some symbol font quirks for Windows, but our behavior is not consistent across platforms. We need to figure out: * what behavior we want * what we're currently doing and then resolve the differences.

I think the "correct" behavior should be: Standard mode: a-alpha-a-a-alpha-alpha Quirks mode: a-alpha-alpha-a-alpha-alpha GTK/Xft currently displays a-alpha-alpha-alpha-alpha-alpha in both testcases.

Mozilla 1.2.1 on Windows 95 displays both standard mode and quirks mode testcases as comment 2 describes the correct standards-mode behavior (so the quirk doesn't seem to be present).

GTK/core does the same as GTK/xft (a-alpha-alpha-alpha-alpha-alpha for both)

I would expect to see "a-alpha-alpha-a-alpha-alpha" in both modes. That is to say, I thought we had decided to make this quirk independent of the mode, given that <font> is not specified in enough detail to make this incorrect. Mozilla trunk on Windows 2000 does "a-alpha-a-a-alpha-alpha" in both modes. Note that there are already bugs filed for Mac and Linux to implement the quirk that is supposedly present on Windows. But I see the situation is a bigger mess than I previously imagined possible... Incidentally, it may be worth creating a second set of tests checking a font such as Webdings instead of Symbol, because Symbol may have additional quirks of its own that may be interfeering with the results.

Yes, see bug 195038.

FYI, my patch for bug 208213 include a fix for this for GFX:Gtk/X11 with Freetype2. The patch makes 'Symbol' font work the same way as the rest 'symbol' fonts (bug 94319 comment #101) _without_ interfering MathML rendering. It doesn't deal with X11core fonts, though.

I have homogenized things on Windows, and attached a patch on bug 195038 which does what dbaron described in comment 3 for all symbolic fonts ('Symbol', 'Webdings', etc). To reach what Hixie indicated in comment 6 requires a change in the Style System, though. That is, set the familyNameQuirks flag anytime on <font>. But this can come later.

I guess I'm not sure we want to do this. I don't think FONT is unspecified -- http://www.w3.org/TR/html4/charset.html is quite clear about how HTML works, even if it doesn't discuss display (which HTML doesn't).

<font> might not be underspecified, but i've yet to see a page that uses it according to the spec in this context.

We all agree that the quirky behavior of <font face> isn't the desired behavior that should have been there in the first place -- that's why bug 33127 has been VERIFIED WONTFIX for as long as I can remember. We may have to include almostStandards (for the transitional DTD) and what not, e.g., a pref. But this was already wisely avoided in bug 94319 because there is no much point having subtle differences that don't buy us anything extra. The reality is that <font face> is old and crusty, and so quirky that it is not worth debating over it anymore, and so I will just favor having a quirky <font face> as people have come to expect. Unicode and CSS are the new borns that came after <font face>. They represent modernity and the future. They are jealously kept clean. On the other hand, with the dependency on the quirky behavior of <font face> (to the point of having bug 94319 done), I wouldn't hold up trying to enforce the same level of purity as with the new foundation. [BTW, since the ability to access arbitrary glyphs in a font is sometimes a _real_ need and the Unicode Consortium with its de jure committees take for ever to approve new code points, a more direct way is officialized in MathML using the <mglyph> tag, with the syntax: <mglyph fontfamily="..." index="..." />]

re comment #3 dbaron, what symbol font do you have on the system? With type1 Symbol font as included in Adobe acroread, in both modes, Mozila Xft gave me 'a-alpha-a-a-alpha-alpha'. In quirk mode, we want that to be 'a-alpha-alpha-a-alpha-alpha', which is why we have bug 179946 for linux. I guess you got what you got in comment #3 because you have TTF Symbol font (from Windows) [1] but didn't remove the comment in the following lines in fontEncoding.properties file : # Symbol font #encoding.symbol.ttf = Adobe-Symbol-Encoding #encoding.symbol.ftcmap = mac_roman re comment #5: Was your test done with freetype enabled?

Comment on attachment 133938 [details] [diff] [review] patch to flag <font face> as quirky anytime I'm not convinced. Any time people depend on glyph indices in fonts, they're doing something non-portable. We should be trying to keep the web portable -- and preventing people from having a way to do this in standards mode (and thus in XHTML and thus in arbitrary XML) is a good thing.

That sounds fair enough to me.

1. You guys are missing the point of this. I used to be of the opinion that <font> should die, but the only motivation for me to have it around became precisely this -- the ability to access a "glyph" by index. Forget for a moment the other things that have indeed tarnished its reputation. 2. I am quoting "glyph" to emphasize that this is not just about characters (with code points that Unicode dared to assign). If you think only in terms of characters, then this issue is moot. 3. Embedded/downloadable "fonts" and the convergence of font engines (e.g., Xft) meant that a "font" can be attached to a document to provide unparallel characteristics. Again, I am using "font" to emphasize that it is not just about characters. The "font" can contain a scalable digital signature, a logo, etc. 4. Ten years down the track, this will be an easter egg that will make people rejoice about Gecko. The argument that people can use a quirks doctype if they want the quirky behavior doesn't hold. You want to phase ou the quirks doctype. There are increasingly more things (e.g., MathML, SVG) that can only happen in standards mode. 5. For me, it is like |goto|. It is the most hated statement, but there are circumstances where a good goto gives a much needed breath of fresh air out of a pointless loop. In fact, I consider <font> to be much powerful. Why? Unlike goto, what <font> does (in the light of what I said above about "glyph") *cannot* be emulated by anything else. 6. Don't let your judgement be clouded by your (justified) dislike of <font> and the stigma of its past abuses.

We don't support font downloading, and I'd hope any mechanism we support in the future would allow assignment of glyphs into the PUA if needed. Until that point, any access of glyphs by index is non-portable, and non-portable things don't belong on the web. Period.

As I said, you don't get the point.

Dare I ask which of the 6 points in comment 17 or the many points in comment 13 is the point that I don't get?

I'm thinking that, to the extent there might still be a change to be made here, it's a change we don't want to make. Please feel free to disagree with me.

It actually is consistent across platforms now, since we removed it on Windows. This is tested by layout/reftests/bugs/399636-*.