Bug 7053

Summary:

Unicode character rightwards arrow doesn't show up in serif with Safari. Other browsers have workaround

Product:

WebKit

Reporter:

David Latapie <david>

Component:

CSS

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED INVALID

Severity:

Normal

CC:

ap, daniele.metilli

Priority:

Version:

417.x

Hardware:

Mac

OS:

OS X 10.4

URL:

http://blog.empyree.org/?1506-font-substitution-flawed-in-safari

Attachments:

Description	Flags
test case	none
Screenshot of the testcase on my machine	none
Character Palette screenshot	none
Test case in US-ASCII	none

David Latapie

Reported 2006-02-03 11:59:59 PST

Sometimes (especially with Unicode characters) it may happen that the requested character doesn’t have any glyph in the requested font. How the brower deals with it varies from browser to browser. - Firefox seems to synthetise - Opera seems to substitute - Safari seems… to do nothing I consider Safari’s behaviour as a misfeature. Please notice the first arrow had been forced (with font-family:serif) into a serif; this is why, even on Safari, it is displayed as it should be. I attach test case

Attachments
test case (1.31 KB, application/xhtml+xml) 2006-02-03 13:17 PST, Alexey Proskuryakov	no flags	Details
Screenshot of the testcase on my machine (31.68 KB, image/png) 2006-02-03 19:38 PST, David Latapie	no flags	Details
Character Palette screenshot (68.44 KB, image/png) 2006-02-04 01:08 PST, Alexey Proskuryakov	no flags	Details
Test case in US-ASCII (1.38 KB, text/html) 2006-03-10 15:43 PST, David Latapie	no flags	Details
View All Add attachment proposed patch, testcase, etc.

David Latapie

Comment 1 2006-02-03 12:03:48 PST

Since attaching does not work, I copy the attachment here <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <meta http-equiv="content-type" content="application/xhtml+xml" /> </head> <body> Character is U+2192, RIGHTWARDS ARROW <h3>Encoded as Unicode</h3> <ul> <li>Default: ?</li> <li>Forced to sans serif: ?</li> <li>Forced to serif: ?</li> <li>Forced to monospace: ?</li> <li>Forced to cursive: ?</li> <li>Forced to fantasy: ?</li> </ul> <h3>Encoded as decimal</h3> <ul> <li>Default: →</li> <li>Forced to sans serif: →</li> <li>Forced to serif: →</li> <li>Forced to monospace: →</li> <li>Forced to cursive: →</li> <li>Forced to fantasy: →</li> </ul> </body> </html>

David Latapie

Comment 2 2006-02-03 12:05:41 PST

At the time of writing, this had not been fixed by the latest WebKit nightly.

Alexey Proskuryakov

Comment 3 2006-02-03 13:17:37 PST

Created attachment 6224 [details] test case Same test case, saved into a file.

Alexey Proskuryakov

Comment 4 2006-02-03 13:22:06 PST

I'm afraid I don't see what the problem is. On my machine, Firefox doesn't render the arrow in cursive and fantasy variants, but Safari renders them all. Could you please describe the problem in more detail, and/or attach a screenshot?

David Latapie

Comment 5 2006-02-03 19:38:33 PST

Created attachment 6235 [details] Screenshot of the testcase on my machine

Alexey Proskuryakov

Comment 6 2006-02-04 01:08:46 PST

Created attachment 6239 [details] Character Palette screenshot Thanks for the screenshot! Could you please do the following: 1) Open the test case, select the arrow glyph. 2) Open Character Palette (Cmd+Option+T). 3) Choose "Show Character Selected in Application" (see my screenshot). 4) Examine the fonts containing this glyph. I suspect that one of them will have a box instead of an arrow (indicating either a bad font or a bug in underlying system software). If my suspicion is wrong, please tell what fonts you have listed here.

David Latapie

Comment 7 2006-02-04 02:32:42 PST

Step 3 doesn't work for me (maybe a bug. I use French OS X and do not know how to change palette's language - for an app, I know but not for a service) Anyway, there is a LOT of fonts with this character: 52, and only two of them (Bookman Old style, both) do not have a glyph attached to it (and so show a square)

Alexey Proskuryakov

Comment 8 2006-02-04 05:20:02 PST

Ok, so does disabling Bookman Old Style (using Font Book, or by manually moving it from your Fonts directory) resolve the problem? I have Bookman Old Style version 2.35 installed, and it doesn't have the problem. What version do you have (it can also be seen in Font Book)?

Joost de Valk (AlthA)

Comment 9 2006-02-18 10:47:07 PST

It has been 2 weeks since ap's last comment, i'm closing this bug because of that AND the fact that if there's a bug, it seems to lie in different (lower) software. Closing as works for me, however, feel free to reopen if you think this is needed.

David Latapie

Comment 10 2006-02-18 12:10:24 PST

Oops, I forgot to reply to the last comment (althoufgh I did have the answer ready 5 minutes after reading the comment) Here it is It should not make any difference, since Bookman is not a default font. Plus, it could not make a problem for TWO font-family

Alexey Proskuryakov

Comment 11 2006-02-18 13:46:58 PST

I'm not ready to comment on whether it _should_ make a difference or not, but could you please try disabling the font? And I still would like to know its version. The box glyph has to come from some font, and we need to find out which one, and why this font gets used.

David Latapie

Comment 12 2006-02-18 15:38:14 PST

I deactivated the font and restarted Safari after having emptied the cache. No difference, still exactly like the picture I uploaded. I also tried with the latest nightly, with no improvement. Granted, I did not restarted the computer, as I have so much thing in progress.

ABob

Comment 13 2006-03-10 13:05:22 PST

As of 2-9-06 daily build I don't seee the problem, so I can't regress. Question: What happens if the page uses different encodings? Content-Type: text/html; charset=ISO-8859-1 or <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> or even xml <?xml version="1.0" encoding="ISO-8859-1"?>

David Latapie

Comment 14 2006-03-10 15:43:33 PST

Created attachment 7000 [details] Test case in US-ASCII

David Latapie

Comment 15 2006-03-10 15:45:23 PST

The new test case is full US-ASCII, with no changes.

Nicholas Shanks

Comment 16 2006-06-10 09:34:56 PDT

*** Bug 9311 has been marked as a duplicate of this bug. ***

David Kilzer (:ddkilzer)

Comment 17 2006-06-10 12:01:30 PDT

(In reply to comment #16) > *** Bug 9311 has been marked as a duplicate of this bug. *** While both bugs deal with Unicode arrow keys, this bug is for serif fonts while Bug 9311 is for sans-serif fonts. I'm not sure they're duplicates.

David Latapie

Comment 18 2006-06-10 14:57:46 PDT

I reinstalled my machine, straight from Tiger (before this, it was a blend of Panther and Tiger up to 10.4.5). Now the test case in US-ASCII *works correctly* (either 10.4.5 or 10.4.6). I don't know why. I also noticed that unmappable character did not appear at all earlier (save with BBEdit) while they now appears as black lozanges. I don't now if this should close the bug or not. Your advice?

Alexey Proskuryakov

Comment 19 2006-06-12 09:14:24 PDT

(In reply to comment #18) > I don't now if this should close the bug or not. Your advice? If noone can reproduce this issue now (and noone could confirm it before), there's hardly anything that can be done about it, so I think you can indeed close it.

David Latapie

Comment 20 2006-06-12 11:01:33 PDT

I do not know what WORKSFORME means, so I closed it at INVALID.

Note You need to log in before you can comment on or make changes to this bug.