969504 - unicode character ▶ is rendered incorrectly with DirectWrite enabled

Status: VERIFIED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Djfe]

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)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Seems to workforme on Mac...  Windows only?

Comment 2

[Djfe]

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 :)

Comment 3

[Djfe]

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

Comment 4

[Jonathan Kew [:jfkthame]]

Could you attach a screenshot showing the rendering you see? Thanks.

Comment 5

[Djfe]

Attachment: example: title

shows that the issue only exists having H/W acceleration enabled

Comment 6

[Djfe]

Attachment: example: input autocomplete

shows that the autocomplete function for inputs (as well as the URL bar) is involved

Comment 7

[Djfe]

Attachment: example: url bar

Comment 8

[Djfe]

sure :)
I attached three screenshots which show the issues quite well, I think

Comment 9

[blinky]

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

Comment 10

[blinky]

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

Comment 11

[Jonathan Kew [:jfkthame]]

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.

Comment 12

[Jonathan Kew [:jfkthame]]

So I think this should be considered a Windows font bug, rather than a Gecko bug.

Comment 13

[Djfe]

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. ;))

Comment 14

[Djfe]

Attachment: test Word 2010

Comment 15

[Djfe]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

> then explain me why it works without hardware acceleration

Because that uses a different font subsystem in Windows, which has different behavior...

Comment 17

[Jonathan Kew [:jfkthame]]

(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.

Comment 18

[Djfe]

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)

Comment 19

[Jonathan Kew [:jfkthame]]

Attachment: avoid using Segoe UI Light or Semibold for U+25B6 due to bad glyph on Win7.

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.

Comment 20

[Djfe]

thx a lot!
yes it may be an "ugly hack" but as long as people are using Win7 it is needed

Comment 21

[Jonathan Kew [:jfkthame]]

See http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-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.

Comment 22

[blinky]

(In reply to Jonathan Kew (:jfkthame) from comment #21)
> See
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 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

Comment 23

[blinky]

This similar to bug 925071.

Comment 25

[Djfe]

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?)

Comment 26

[Jonathan Kew [:jfkthame]]

(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.

Comment 27

[John Daggett (:jtd)]

Attachment: patch, make Segoe UI Symbol higher priority for symbol fallback

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.

Comment 28

[Djfe]

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 ;)

Comment 29

[John Daggett (:jtd)]

Attachment: textrun, textrunui logging output for youtube page

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

Comment 30

[John Daggett (:jtd)]

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.

Comment 31

[John Daggett (:jtd)]

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.

Comment 32

[Jonathan Kew [:jfkthame]]

(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.

Comment 33

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4e6633cbb697

Comment 35

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/4e6633cbb697

Comment 36

[Thomas Stache]

Has an Aurora uplift been considered? Maybe this is worthwhile to have out earlier.

Comment 37

[Jonathan Kew [:jfkthame]]

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

Comment 38

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4c2ea03015af

Comment 39

[Ioana (away)]

Felix, could you please verify that this issue is fixed on Firefox 29 and 30?

Comment 40

[Djfe]

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 ;)

Comment 41

[Ioana (away)]

Thanks Felix :)

Comment 42

[Amaury]

Good to see that this is going to be fixed in one of the upcoming Mozilla Firefox updates.

Great job, guys!