Closed Bug 212745 Opened 21 years ago Closed 18 years ago

Suit symbols (e.g., ♦) do not display correctly.

Categories

(Core Graveyard :: GFX: Mac, defect)

Product:
Core Graveyard
Component:
GFX: Mac
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ers, Assigned: jaas)

References

(
URL
)

Details

(Keywords: platform-parity, Whiteboard: fixed for Firefox 3, partial workaround for Fx2 in comment 21)

Attachments

(6 files, 1 obsolete file)

Suit character references
381 bytes, text/html
Details
screenshot
10.99 KB, image/jpeg
Details
same html, but with <tt> added
392 bytes, text/html
Details
screenshot - Safari vs Firefox
159.28 KB, image/jpeg
Details
Test to show bug, including font-variations
5.68 KB, text/html
Details
screenshot of Firefox 3.0.6 on Mac OS X 10.4.11
11.39 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85 (KHTML, like Gecko) Safari/85
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624

The suit symbols (clubs, diamonds, hearts, spades) do not display correctly. They did in Mozilla 
1.3 (and work fine in other browsers. The following one line of HTML illustrates it:

&diams; are forever

The diamonds symbol appears as a horizontal line. 

Reproducible: Always

Steps to Reproduce:
1.Create a file "test.html" containing the one line: &diams; are forever
2.Open this file in the browser.
3.
Actual Results:  
The diamonds symbol appears as a horizontal line.

Expected Results:  
The diamonds symbol should have been the usual suit symbol.
Perhaps bug 88795 has regressed.
Keywords: pp
Hmmmm ... I can see them on the example page and on
http://www.cs.tut.fi/~jkorpela/html/guide/entities.html

build 2003071508 on Mac OS X 10.2.6
This attachment shows all the ways (I know) of referencing those characters,
and they all work for me using 1.5a
What do people who are seeing the problem see on the attached testcase?
Attached image screenshot — 
I'll see this with Mozilla trunk 2003093005
Are you sure you don't have a font that has those characters where the suit
symbols should be?
Hmm, I might have missed something...but I'll have the same settings as I have
with Mozilla 1.2.1 in Mac classic (I see the symbols with 1.2.1):

Under Typeface (top-bottom): Serif - Times - Helvetica - Apple chancery - Gadget
- Courier.


*** Bug 223240 has been marked as a duplicate of this bug. ***
see bug 223240 for a localization of the transition between working and broken
build : 1.4rc1 is OK ;; 1.4rc2 is broken

builds up to and including 1.4rc1 are OK
builds from 1.4rc2 and up are all broken

I've taken samples from the whole list - at present it seems as if it's just the
4 suit symbols that are broken

I've tested all released builds with the test-case attached to bug 223240

Completely new profile - nothing was changed between testing builds.
Fresh installs of every version of Mozilla (I ran them directly off the mounted dmg)
Status: UNCONFIRMED → NEW
Ever confirmed: true
i've noticed this bug for awhile and found it's already been filed.  i get my
lack of poker under 10.2.x and 10.3 using moz 1.4.1, 1.4.0, and (i'm pretty sure
but don't remember) moz 1.5.0.

it should be noted, viewing the suit test (attachment 130222 [details]) and hitting view
source will should show the actual characters.

also, the test suit but with a monospaced font will display the all cards
correctly in the html window.  i'll attach that.
enclosing the text in <tt> makes the suit symbols display correctly.  i'll
leave the screen shot to your imagination.
WFM using Mac/1.7. Ed, Jay, can either of you still reproduce this using a
current build?
Using the test-attachment 130222 [details] I'm still having the problem in Moz 1.7rc2
Mac OS X 10.3.3
> Using the test-attachment 130222 [details] I'm still having the problem in Moz 1.7rc2
> Mac OS X 10.3.3

Yup, still an issue with 2004051208 on mac os 10.2.8


*** Bug 259369 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10

Using the testcase with Unicde encoding (View > Character Encoding > Unicode)
all three rows display correctly. Changing to Western encoding results in the
third line being changed into this:

Actual characters: ♠ ♣ ♥ ♦
*** Bug 260101 has been marked as a duplicate of this bug. ***
*** Bug 257204 has been marked as a duplicate of this bug. ***
*** Bug 270058 has been marked as a duplicate of this bug. ***
*** Bug 281038 has been marked as a duplicate of this bug. ***
FWIW, I'm still seeing this in the Feb 14th Camino build. This affects the
"white" versions of the suit characters also.

Interestingly, if I set the font explicitly (e.g., to Osaka or Seoul) the
characters display properly. Maybe Gecko is falling back to a broken font?
*** Bug 295851 has been marked as a duplicate of this bug. ***
Hm, that's interesting. Osaka and Seoul work, but as shown in my attachment to bug 295851, the Hiragino 
family doesn't. Perhaps because they're OpenType.  The latest version of Arial, from Office 2004, doesn't 
work either, despite the fact that it too has the card suits in it.

And for what it's worth, I can't see any 'wrong' suit characters in Character Palette.
(In reply to comment #11)
> enclosing the text in <tt> makes the suit symbols display correctly.  i'll
> leave the screen shot to your imagination.

Doesn't this just imply that this is a font issue and not a Mozilla problem?
(In reply to comment #24)
> Doesn't this just imply that this is a font issue and not a Mozilla problem?

If you trade the fonts used for proportional and fixed width the <tt> version
still works and the other still doesn't so it isn't just because of fonts.
*** Bug 297258 has been marked as a duplicate of this bug. ***
*** Bug 302755 has been marked as a duplicate of this bug. ***
*** Bug 307350 has been marked as a duplicate of this bug. ***
Some more info...

I traced through the display of this page:
http://ppewww.ph.gla.ac.uk/~flavell/unicode/unidata21.html#x21E7
which shows the same problem for the * WHITE ARROW characters (as reported in bug#306281)
in a debug build of the nightly:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051001 Firefox/1.6a1

Interestingly these test pages have the correctly-displaying <tt> versions of the chars too, as in 
comment#11, because of a similar reported problem in IE.

It appears to me to be the fallback code. All of the 21xx characters trigger the fallback code in 
nsUnicodeRenderingToolkit.cpp. The characters in this block that display correctly are setting 
fallbackScript = BAD_SCRIPT in TECFallbackGetDimensions; later on this means they use the 
ATSUIFallback* code to display. The incorrectly displaying chars all trigger the TECFallback* path 
instead. 

Theres a bunch of other characters affected too; a more complete list:
0x21e6..0x21e9, 0x221f, 0x222e, 0x2460..0x2490, 0x249c..0x24b5, 0x260e, 0x261c..0x261f, 
0x2660..0x2667, 0x2776..0x277e, 0x278a..0x2792,0x27a1, 0x2b05..0x2b07
(I've probably missed a few single-char problems there, I was mainly looking for any pattern in the 
larger blocks).
*** Bug 311995 has been marked as a duplicate of this bug. ***
Suddenly the hearts suit has started working for me in Tiger with 1.0.7.  A screen capture can be found here: http://img.photobucket.com/albums/v614/swya/Picture1.png
Notice the first interest in the list.
(In reply to comment #31)
> Suddenly the hearts suit has started working for me in Tiger with 1.0.7.  A
> screen capture can be found here:
> http://img.photobucket.com/albums/v614/swya/Picture1.png
> Notice the first interest in the list.
> 

Today they don't work again.  The only thing different is I removed an extension.  Go Figure.
(In reply to comment #29)
> Theres a bunch of other characters affected too; a more complete list:
> 0x21e6..0x21e9, 0x221f, 0x222e, 0x2460..0x2490, 0x249c..0x24b5, 0x260e, 0x261c..0x261f, 
> 0x2660..0x2667, 0x2776..0x277e, 0x278a..0x2792,0x27a1, 0x2b05..0x2b07
> (I've probably missed a few single-char problems there, I was mainly looking for any pattern in the 
> larger blocks).

0x2160-0x216b and 0x2170-0x217b, also known as the Roman numeral characters, are displaying for me as Japanese kana!  Something is definitely not right there.
This problem still there with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
... though I have recently observed that IE isn't so good after all, as PC IE mis-renders the Icelandic &eth; character, and Firefox doesn't. 
http://www.jdawiseman.com/papers/trivia/character-entities.html tests all the named character entities, and their numeric equivalents. Of that subset of characters everything works except the suits. 
(In reply to comment #36)
WFM with 2005-12-21 sm trunk. And so do the testcases.

Sounds like there's probably either:
 * a font with incorrect glyphs for these characters
 * a font with glyphs that we incorrectly interpret as being for these characters

Has anyone tried to figure out which fonts are causing the problem?  It seems like there was some discussion of that in comment 23, perhaps continued in comment 29, etc.

It also sounds like this is Mac-only, and a bug either in fonts that are often present on the Mac or in the Mac font selection code.

It may also be useful if the regression window in comment 9 were narrowed.
Assignee: layout.fonts-and-text → joshmoz
Component: Layout: Fonts and Text → GFX: Mac
QA Contact: ian → mac
> WFM with 2005-12-21 sm trunk. And so do the testcases.

Sorry, didn't notice this was a Mac-specific bug.


This is fixed by the MLTE patch in bug 121540, if that patch lands at some point.
There might be a way to fix without relying on MLTE, but using MLTE is more likely to be a clean solution than others.
Depends on: atsui
No, this bug aint fixed. version 1.5.0.1 rc1 fails to render the suits symbols. and no its nothing to do with the character set nor is it to do with wrongly interpreted characters, etc. as has been suggested. this is a real bug. renders &spades; as a thick long (approx 2 "m" wide) horizontal line,  &hearts; as a thick long (full character line height) vertical line, &diams; as a dotted long (approx 2 "m" wide) horizontal line, and &clubs; as a thin gray long (full character line height) vertical line.
Still broken in Camino 1.0 final as well.
Enough bridge websites use these symbols that I'd be keen on any solution, even if it isn't clean and durable. String-and-blutack fix for the moment, please, even if better will come later. 
As noted in comment 21, you can "fix" some of these characters (at least the suits) by setting your Japanese font to Osaka (provided you don't also read Japanese text and want to use quality fonts to display it).  That's a work-around that will work for some until bug 121540 lands.

(For the morbidly curious, I'm 99% sure bug 188429 "broke" this by changing our Japanese font defaults to the modern Japanese fonts in order to fix serious problems the old fonts had with the display of many characters.  But that's really irrelevant here because the real problem is in busted font fallback code and friends--comment 29--which is fixed in the MLTE patches proposed in bug 121540.)
Whiteboard: partial workaround in comment 21
*** Bug 306281 has been marked as a duplicate of this bug. ***
Thank you. To detail the solution for others:
Firefox > Preferences… > Content > Fonts & Colors (Advanced…) > Fonts for: Japanese > Osaka-??, where ?? are Japanese characters I don't know how to type. 
*** Bug 336392 has been marked as a duplicate of this bug. ***
The bug has resurfaced in FF1.5.0.3.  (It worked beautifully in 1.5.0.2.)

Steps to Reproduce:
1. Launch Firefox
2. Go to website which uses unicode symbols (e.g.
http://www.alanwood.net/unicode/miscellaneous_symbols.html)
3. There is no step 3.
Actual Results:  
Unicode symbols such as &#9829; display as | instead.

Expected Results:  
Unicode symbols such as &#9829; should display as a &#9829;

Displays properly:

Firefox 1.5.0.2 for Mac OS X, Firefox 1.5.0.2 for Windows, Firefox 1.5.0.3 for
Windows

Doesn't display properly:

Firefox 1.5.0.3 for Mac OS X (Universal)


Tested with extensions enabled and disabled.  Tried restarting computer, too.  Also tried trashing profile and starting anew.
Attachment #220692 - Attachment description: Safari vs Firefox → screenshot - Safari vs Firefox
Yet http://www.jdawiseman.com/papers/trivia/character-entities.html works fine in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3, as indeed does the http://www.alanwood.net/unicode/miscellaneous_symbols.html link in the previous report. So works for me. 
It is weird.  I had problems with the page after upgrading to FF1.5.0.3 but even when I downgrade back to .2, the problem remains.  I have tried deleting ~\Library\Application Support\Firefox with a new profile and everything - to no avail.  (Furthermore, I have not installed/removed any software or fonts inbetween...)

Perhaps there is something else that leads to the problem?  Very weird that some people experience it and others don't.

The solution detailed in comment #46 works for me, too.
What OS? Works for me on 10.4.6.
(In reply to comment #53)
> What OS? Works for me on 10.4.6.
> 

Same. 10.4.6.  

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

*** Bug 337070 has been marked as a duplicate of this bug. ***
how is this related to Bug 148361 which also mentions a slew of other chars, but on the surface the discussion there does overlap these 4 chars
This does NOT appear to be a Mac-only problem; nor does it seem related to a system-level font problem. Read on:

The test cases on Bug 312567 don't work in FF 1.0.5.4 on Windows XP SP2 or on OS X  10.4.7 (same browser version); in all instances, it renders the entities as vertical or horizontal bars. The tests use named, decimal and unicode references. It does work in all instances of IE 5 and up (win and mac), Opera 9, Safari, iCab 3, etc. I cannot find a browser it _doesn't_ work in except in Gecko-based browsers. 

I tested it with the a nightly-build of FF 3.0a1 and the problem persists there too.

Interesting to note, changing the page's font-family in the CSS to generic 'monospace' and it redners the symbols on the Mac (didn't try out on the PC); however, specifying any _specific_ monospaced font-family won't work (and I've tried all that are on my system).

Changing the text-encoding does not work either.
This is a test case that also shows that declaring a generic font-family:monospace; will render properly. However, as the test table shows, the 'courier' that FF is using for its monospace default is clearly not identical to the 'courier' or 'courier new' that is explicitly declared.
(In reply to comment #57)
> This does NOT appear to be a Mac-only problem; 

I stand corrected. The test cases work (see latest attachment (id=229544)) on Windows in all instances for me. It still works in all other Mac browsers tested that don't use Gecko engine (Safari, IE, iCab, Opera).

> Interesting to note, changing the page's font-family in the CSS to generic
> 'monospace' and it redners the symbols on the Mac.

This is illustrated in the new test case. It clearly shows that though FF is set to use "Courier" by default as its generic monospace font, it's clearly not using the same reference to a font when "courier" or "courier new" is declared explicitly by the stylesheet. That should be a clue as to where to track down the problem.

Updated table to correct some incorrectly labeled font-choices.
Attachment #229544 - Attachment is obsolete: true
This bug completely vanished on my computer (Intel MacBook, 10.4.7) for a little less than an hour. I downloaded FF2.0rc1, installed the upgraded Pinstripe theme, and enabled it; once the browser restarted, it was displaying all hearts symbols perfectly. I re-switched to the 2.0 default theme to see if it worked there, and it reverted to showing vertical lines. Then I re-re-switched to Pinstripe, and got vertical lines there as well. 

I have no idea what caused this, and will comment again the minute I figure out how to reproduce it. 
*** Bug 360665 has been marked as a duplicate of this bug. ***
This looks fixed to me in cairo-cocoa builds.
yeah, fixed by cairo
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Is "cairo" 2.x, or unreleased?  This is still an issue for me on FF 2.0.0.1 on 10.4.8.
The 2.x build is not using Cairo; the first release to use it is the alpha release of 3.0 (GranParadiso).
This will finally be fixed in 3.0?
Sorry for filing the duplicate Bug 370730, but will this bug finally be fixed in 3.0? It's many years old already. >:(
(In reply to comment #69)
> Sorry for filing the duplicate Bug 370730, but will this bug finally be fixed
> in 3.0? It's many years old already. >:(
> 

It seems to be fixed already on the Firefox trunk, probably by Cairo.
Now working on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
by putting it into a <code><pre></pre></code> tag, Firefox 2.0.0.4 renders it correctly on a MacBook running 10.4
err, ignore that <code></code> bit, I got carried away. 
(In reply to comment #71)
> Now working on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
> rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
> 

Doesn't appear to be fixed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

It's not relevant to the bug since it's fixed in the latest builds; however, does your above UA work with the test page attachment id=229547 ? Mine doesn't.
> test page attachment id=229547
Works for me in every row except the last two, being cursive and fantasy, both of which are blank. 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Whiteboard: partial workaround in comment 21 → fixed for Firefox 3, partial workaround for Fx2 in comment 21
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: