Closed Bug 837498 Opened 8 years ago Closed 8 years ago
[Win8] Hebrew characters appears as empty squares on Firefox user interface
3.02 KB, image/png
6.54 KB, image/png
10.26 KB, image/png
38.77 KB, image/png
1.94 KB, patch
|Details | Diff | Splinter Review|
We've starting to get reports to our community forum as well as other places that the browser user interface on Windows 8 doesn't appear well in Hebrew, and instead of Hebrew they are seeing empty square glyphs. I can't reproduce it as I don't have Windows 8 machine nearby, but as it reproduce to different people in different places, I suspect it can reproduce on clean installation of Windows 8 as well. I am attaching screenshots provided by users. Steps to reproduce: Launch Firefox 18 with Hebrew locale on Windows 8. Actual result: * The location bar reported to contain squares if typed Hebrew text such as "שלום עולם". * Tab bar contains squares if page title contains Hebrew characters (for example visit http://he.wikipedia.org). The user reported the text re-appear after clicking on the tab. The user reported it can be fixed by changing the system fonts to Arial.
Empty squares on Firefox start (about:home) the placeholder text ("Go to site"/"עבור לאתר") appears as empty squares. I've found this report on another forum were users suggested the user to wait until the bug resolve without giving him any informative answer. It is possible that text entered on the location bar won't trigger this problem as opposed to what I wrote on comment 0; this one seems easier to reproduce.
If someone experiencing this problem could try changing the preference gfx.font_rendering.fallback.always_use_cmaps from false (the default) to true in about:config, and let us know whether that makes any difference, it would be helpful. Thanks. smontagu, do you have access to a Win8 machine to test this, by any chance?
Workaround: It is reported that it is possible to get the expected result by disabling fonts that are not designed to the input language settings. I think that this screen is new on Windows 8 as I don't remember seeing it in previous versions. The screen appears on the first image on following help document: http://sumtips.com/?p=7877 Although this workaround pretends to fix the problem, it is reported that after restarting the computer the problem reproduce and it is required to enable again the checkbox and click on the restore fonts button.
Jonathan, i change this value to true, and still have that problem.
Yaniv, you've mentioned that running in safe mode mysteriously solved the problem. Mind running some further investigation to find which addon might cause this problem?
i dont mind. but as i check right now. its not addon problem niegther. see again my update on the forum. all my checks.
Please try the example page at http://people.mozilla.org/~jkew/heb-test.html, and confirm whether the problem occurs in any of the lines of text there (which ones?). It should show 9 lines each containing the same Hebrew text, but in various styles. If the problem -does- show up with the text on that page, then please also do the following: * install the "fontinfo" addon (and restart Firefox to make it active) * select the "bad" text on the page and choose Show Fonts in Selection from the contextual (right-click) menu * let us know what font name(s) it reports Thanks for your help investigating this!
so i check this site http://people.mozilla.org/~jkew/heb-test.html. this is the result: lines 1-3 apears well. lines 4-9 showing these empty square glyphs. but only the second "שלום עליכם" in each line its bad. the first one good. i'll install fontinfo and let u know.
i uploaded pic to show u how its looks like in this site. http://tinypic.com/r/344vcci/6
ok then. the result of fontinfo: all bad font lines showing this: segoe UI italic segoe UI semilight lines 7-9 showing also this: segoe UI
According to MSFT, Segoe UI should include Hebrew glyphs. https://www.microsoft.com/typography/fonts/font.aspx?FMID=1941
so any good solution how can i change this segoe for better font?
(In reply to Tomer Cohen :tomer from comment #12) > According to MSFT, Segoe UI should include Hebrew glyphs. > https://www.microsoft.com/typography/fonts/font.aspx?FMID=1941 Yes, but note that not all styles of the family include Hebrew: https://www.microsoft.com/typography/fonts/font.aspx?FMID=1943 Yaniv, could you try a couple more tests, please? First, load the page http://people.mozilla.org/~jkew/heb-segoe.html and attach a screenshot of the result (you can add it as an attachment directly to this bug). I'm expecting that you will see the same problem in *some* of the table cells in that example, but I'd like to confirm the pattern of behavior. And second, I'm curious whether a similar issue occurs with Arabic characters. To check this, please try loading http://people.mozilla.org/~jkew/arab-segoe.html and let us know the result of that as well. Thanks!
Jonathan. both pages apears very good. hebrew and arabic. i attached screenshot that included result of both.
Thanks. Hmm, that's interesting - not quite what I expected. So the problem only happens when using a "system" font name (via CSS such as "font: message-box"), but not when the font is selected using "font-family: Segoe UI".
i would like to notice. that in nightly hebrew version [21.0a1], i don't see anything wrong as all mention.
It has been reported that this problem MIGHT be caused by Tab Mix Plus, although I don't have Windows 8 machine to check this out.  http://mozilla.org.il/board/viewtopic.php?f=9&t=11548#p57758
(In reply to Jonathan Kew (:jfkthame) from comment #16) > Thanks. Hmm, that's interesting - not quite what I expected. So the problem > only happens when using a "system" font name (via CSS such as "font: > message-box"), but not when the font is selected using "font-family: Segoe > UI". Interesting conclusion, except it's wrong. The reason Yaniv didn't see a problem in the last test files is because he cannot see the problem at all anymore (since he moved to a beta/nightly version) for whatever reason. However, I can confirm that the problem happens to me even with latest nightly (clean profile), and only when the font displayed is Segoe UI Italic (regardless of how it was set) in all test files. Obviously it has something to do with the lack of Hebrew in the italic style of that font, as per Comment #14. Also, when I set gfx.font_rendering.directwrite.use_gdi_table_loading to False (or when disabling d2d completely), the problem disappear.
yonizaf, am I right in assuming your Windows system locale is set to Hebrew? If so, this suggests we're looking at a Hebrew version of the problem that was discussed and fixed for Arabic-script locales in bug 629386. And in that case, we should be able to work around this in the same way. I've started a tryserver build at https://tbpl.mozilla.org/?tree=Try&rev=2dd3f3a38757 that has a patch for this. If you could test it once the build is available (it'll be a couple of hours), and confirm whether it fixes the problem, that would be great - thanks!
The try build is now available at https://firstname.lastname@example.org/try-win32/. If you could test this and let us know whether it fixes the problem, that would be really helpful. (You can either download the installer.exe and use it to install the build, or download the firefox-23.0a1.en-US.win32.zip archive, extract the files, and run the "firefox.exe" found there - this avoids the need to actually "install" the test build and perhaps replace your existing installation of Nightly.)
Yes, my system locale is set to Hebrew, and yes, your try build fixes the problem.
(In reply to yonizaf from comment #22) > Yes, my system locale is set to Hebrew, and yes, your try build fixes the > problem. OK - thanks for testing. In that case, we can get this fixed in Nightly as soon as the patch is reviewed.
Comment on attachment 744056 [details] [diff] [review] work around DWrite/GDI 'cmap' discrepancy for Italic fonts with Hebrew system locale Review of attachment 744056 [details] [diff] [review]: ----------------------------------------------------------------- r=me, but I'm not going to lie to you and say I like this fix
Can't say I like it either, but as we already have the hack in place for Arabic, I'm prepared to look the other way and go ahead. https://hg.mozilla.org/integration/mozilla-inbound/rev/331187bfb983 Hmm, having just pushed this, I notice you apparently forgot to actually set the r+ flag on the patch. I'm taking the liberty of flipping it to r+ on the basis of comment #25.
Attachment #744056 - Flags: review?(smontagu) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Can we comfortably take this in FF22? We'll release note this as a known issue for FF21.
Comment on attachment 744056 [details] [diff] [review] work around DWrite/GDI 'cmap' discrepancy for Italic fonts with Hebrew system locale Yes, I think we can safely take this for FF22. It's just extending the fix we did in bug 629386 for Arabic, and applying it to Hebrew as well. [Approval Request Comment] Bug caused by (feature/regressing bug #): 602792 User impact if declined: unreadable text (boxes) for some italic-styled text on Hebrew Windows systems Testing completed (on m-c, etc.): tested with tryserver build (comment 22), landed in m-c Risk to taking this patch (and alternatives if risky): minimal String or IDL/UUID changes made by this patch: none
Attachment #744056 - Flags: approval-mozilla-aurora?
Attachment #744056 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I can't reproduce the initial issue on Firefox 21 he. Could anyone who reproduced the initial issue confirm that is no longer reproducible on Firefox 23 beta? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/23.0b7-candidates/build1/win32/ Thanks!
Yaniv, since you were able to reproduce this before can you please see if it's fixed for you now with the latest Beta builds?
Anthony, as i alerady said before since 21 versio, so now on 23 version, there is nothing wrong. and that bug doesnt exists. apparently its fixed at last versions.
You need to log in before you can comment on or make changes to this bug.