Closed Bug 969504 Opened 6 years ago Closed 6 years ago
unicode character ▶ is rendered incorrectly with Direct
75.76 KB, image/png
3.06 KB, image/png
139.96 KB, image/png
2.82 KB, image/png
1.43 KB, patch
|Details | Diff | Splinter Review|
1.05 KB, patch
|Details | Diff | Splinter Review|
113.88 KB, text/plain; charset=utf-8
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140127194636 Steps to reproduce: I watch YouTube or listen to music on SoundCloud and during that the following character gets displayed in the title to indicate the playback in this tab: ▶ Actual results: the issue is that this character (▶) a black right-pointing triangle, which looks like a play symbol, is rendered wrong. Places where it gets rendered wrong: title element autocomplete for input fields probably more Expected results: all other browsers render this symbol/character correctly (at least: IE, Chrome)
Seems to workforme on Mac... Windows only?
an example of the wrong rendering of this character can be seen in the title of this bug as the title of the website includes the bug title it looks almost like an audio spektrum because the character looks so compressed :)
I'm using Windows right now so probably yes a lot of users seem to be experiencing the same bug (just found this): https://support.mozilla.org/de/questions/968277 actually it seems to be an issue with the hardware acceleration, I tested it and it was only corrupt while using hardware acceleration
Summary: unicode character ▶ is rendered wrong → unicode character ▶ is rendered wrong (using hardware acceleration)
Could you attach a screenshot showing the rendering you see? Thanks.
shows that the issue only exists having H/W acceleration enabled
shows that the autocomplete function for inputs (as well as the URL bar) is involved
sure :) I attached three screenshots which show the issues quite well, I think
The problem here is the Unicode character ▶ Falling back to this character http://imageshack.com/a/img849/1320/smq9.png with hardware acceleration enabled. Test case: http://dl.dropboxusercontent.com/u/95157096/85f61cf7/gbkZagOe.html
This problem occurs since the version 13.0a1 (2012-02-16). Screenshot: http://imageshack.com/a/img543/8372/kp3j.png http://hg.mozilla.org/mozilla-central/rev/a853f4017192 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120216 Firefox/13.0a1 Build ID: 20120216031231 Regressed by: bug 668813
This seems to be specific to Windows 7, due to the (faulty?) version of Segoe UI Light that's installed. I do not see the issue on Win8, which has updated versions of the fonts; there, Segoe UI Light does not include ▶, so it falls back to Segoe UI Symbol, which has the expected glyph.
So I think this should be considered a Windows font bug, rather than a Gecko bug.
then explain me why it works without hardware acceleration and why other browsers aren't experiencing this issue... and why can't use Firefox the symbol variant of the font instead? and why did it work before Firefox 13.0a1 as blink showed (thanks for the details btw. ;))
I'm sorry I did a quick test with Word 2010 (see attached picture above) and it turned out that only the Symbol variant of the font worked correctly so this is a font issue as you have already said above font-size 20pt the triangle was shown correctly in all variants though is it possible to tell Firefox to use a different font for certain characters (in the title and for autocomplete inputs)? else this issue can be closed
> then explain me why it works without hardware acceleration Because that uses a different font subsystem in Windows, which has different behavior...
(In reply to Boris Zbarsky [:bz] from comment #16) > > then explain me why it works without hardware acceleration > > Because that uses a different font subsystem in Windows, which has different > behavior... Specifically, under the GDI model, font families are limited to the "standard 4 faces" (regular/bold/italic/bold-italic). Therefore, Segoe UI Light ends up treated as a separate family from Segoe UI. And so in these UI elements where the default font family is Segoe UI, the ▶ character is not found, and fallback occurs; this gives us Segoe UI Symbol. But with the DirectWrite font system, all the weights of Segoe UI are (correctly) treated as belonging to the same Segoe UI family. This is in general a benefit; it means that font-weight styling can work more fully as designed. However, in this case it has the result that when ▶ is not found in Segoe UI Regular, our first fallback option is to try a different weight within the same family - and we find Segoe UI Light, with its thin version of the glyph.
yeah, but a software workaround which checks for the character should work, right? Web Designer cannot change the font style of the title and autocomplete elements (especially if you are talking about one character only)
Yuck - this is an ugly hack, but it should fix the rendering that people are seeing on sites that use U+25b6 to represent a Play control or similar.
Attachment #8373505 - Flags: review?(jdaggett)
Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
thx a lot! yes it may be an "ugly hack" but as long as people are using Win7 it is needed
See http://firstname.lastname@example.org/try-win32/ for a test build that includes this patch. If you could try this and confirm that it fixes the problem for you, that'd be great.
(In reply to Jonathan Kew (:jfkthame) from comment #21) > See > http://email@example.com- > 480897b01792/try-win32/ for a test build that includes this patch. If you > could try this and confirm that it fixes the problem for you, that'd be > great. I can not reproduce the problem with this build. Screenshot: http://imageshack.com/a/img163/5511/hc4j.png
This similar to bug 925071.
works for me as well (fixes title and autocomplete) what do you think: is it necessary to do the same for U+25C0 (left pointing triangle)? (http://www.fileformat.info/info/unicode/char/25c0/index.htm) because it looks more like the left pointing pointer (U+25C4) as well (http://www.fileformat.info/info/unicode/char/25c4/index.htm) When will the fix be introduced? (Version 30?)
(In reply to felix.bau from comment #25) > works for me as well (fixes title and autocomplete) > > what do you think: > is it necessary to do the same for U+25C0 (left pointing triangle)? > (http://www.fileformat.info/info/unicode/char/25c0/index.htm) Yes, I think that makes sense. I already added this to the patch that's awaiting review, although it wasn't included in the tryserver build.
I think this might be a better approach, rather than swizzling the cmaps. Need to confirm that this fixes the problem, running a tryserver build now.
Problem with this method (even if it is less ugly) -> you cannot be sure whether this replaces other characters as well which are supposed to be different in this special font type Have you looked through all characters? (if not, then the "ugly" version is better, as there is no chance that it changes stuff that it is not supposed to change ;)
Summary: unicode character ▶ is rendered wrong (using hardware acceleration) → unicode character ▶ is rendered incorrectly with DirectWrite enabled
Looks like this isn't fallback but our chrome code explicitly specifies Segoe UI. Argh... Logging when opening youtube page below: http://www.youtube.com/watch?v=rA4s3wN_vK8
Attachment #8376939 - Attachment mime type: text/plain → text/plain; charset=utf-8
Comment on attachment 8376094 [details] [diff] [review] patch, make Segoe UI Symbol higher priority for symbol fallback Testcase for comparing Segoe UI/Segoe UI Light and Segoe UI Symbol: http://people.mozilla.org/~jdaggett/tests/segoesymbolfallback.html Given that in symbol ranges it's far more common to find glyphs in Segoe UI Symbol than in Segoe UI, I think it makes sense to change the fallback order. For the most part this won't affect the actual glyph used, since when there's crossover the Segoe UI Symbol glyph typically matches the Segoe UI regular glyph. The weird glyphs in the U+25b? and U+25c? ranges are the exception.
Attachment #8376094 - Flags: review?(jfkthame)
Comment on attachment 8373505 [details] [diff] [review] avoid using Segoe UI Light or Semibold for U+25B6 due to bad glyph on Win7. Given that this is basically a bug in the version of Segoe UI that ships on Windows 7, it would be nice not to have to do this sort of cmap swizzling. But given that Segoe UI is used within chrome code, I think changing the cmap to effectively remove these glyphs is probably what we need to do. I think we should take both patches here, since it will speed up fallback ever so slightly to try Segoe UI Symbol first for symbol ranges.
Attachment #8373505 - Flags: review?(jdaggett) → review+
(In reply to John Daggett (:jtd) from comment #30) > Comment on attachment 8376094 [details] [diff] [review] > patch, make Segoe UI Symbol higher priority for symbol fallback > > Testcase for comparing Segoe UI/Segoe UI Light and Segoe UI Symbol: > http://people.mozilla.org/~jdaggett/tests/segoesymbolfallback.html Note that this testcase appears slightly misleading, in that the "Segoe UI" column will display Segoe UI Light glyphs for those characters (such as U+25b6) that are missing in the Regular face, but present in Light. > > Given that in symbol ranges it's far more common to find glyphs in Segoe UI > Symbol than in Segoe UI, I think it makes sense to change the fallback > order. On the other hand, I suspect (though it's only a guess) that some of the characters that are present in Segoe UI but not Segoe UI Symbol, such as various currency symbols and fractions, may be more commonly used - in which case trying Segoe UI first could make more sense. A further point is that it's likely the Segoe UI cmap will have already been loaded by the time we hit a character that needs fallback, as it's the primary chrome font, so checking this first should be very cheap. Segoe UI Symbol, on the other hand, is more likely to trigger an extra cmap load. As such, I'm not sure how beneficial - if at all - this change would be in practice. Given that it doesn't directly address this bug as filed, I'm going to r- the patch here; if you still think it's worth doing for other reasons, and want to file a separate bug for it, we can consider it further.
Attachment #8376094 - Flags: review?(jfkthame) → review-
Target Milestone: --- → mozilla30
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Has an Aurora uplift been considered? Maybe this is worthwhile to have out earlier.
Comment on attachment 8373505 [details] [diff] [review] avoid using Segoe UI Light or Semibold for U+25B6 due to bad glyph on Win7. This is far from a critical issue - it's been around for a while, and is really just cosmetic - but given that it affects a number of high-profile sites (see comments/screenshots here and in the duplicate bugs), and that the patch is IMO extremely safe, I think we could consider this for uplift. [Approval Request Comment] Bug caused by (feature/regressing bug #): font bug (bad glyph design) on Win7/DWrite User impact if declined: "Play" icons on various sites (or other usage of ▶ character) looks bad Testing completed (on m-c, etc.): on m-c for a week Risk to taking this patch (and alternatives if risky): risk is minimal; the patch just "blanks out" two specific characters in the Segoe UI font when using DWrite, and cannot affect anything else. String or IDL/UUID changes made by this patch: none
Attachment #8373505 - Flags: approval-mozilla-aurora?
Attachment #8373505 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Felix, could you please verify that this issue is fixed on Firefox 29 and 30?
Whiteboard: [good first verify]
yep, tested the current Aurora and Nightly versions (29+30) and the bugfix works as expected -> both "icons"/characters are shown just fine now in the title and in the autocomplete field so thx again for everybody involved in fixing it and providing additional informations ;)
Thanks Felix :)
Good to see that this is going to be fixed in one of the upcoming Mozilla Firefox updates. Great job, guys!
Whiteboard: [good first verify] → [good first verify] [testday-20140509]
You need to log in before you can comment on or make changes to this bug.