609604 - Wrong font rendering of combining marks (accents) without anchors

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Pavel Cvrcek [:JasnaPaka]]

Latest Firefox 4.0 NB.

Steps to reproduce:
1) Visit http://buzzmag.cz/placeny-obsah-budoucnost-medii-je-obsah-zdarma-02-11-2010/
2) Have a look at text which is inside tag <blockquote>.
3) Non-ascii chars are rendered incorrectly

I tried to create testcase but with no success (maybe I try it later again). On <blockquote> tag there is such CSS rule:

.entry-content, #hd blockquote {
    font-family: Georgia,"Times New Roman",Times,serif;
    font-size: 15px;
    line-height: 150%;
}

If I disable "font-size" then all works fine.

Comment 1

[Pavel Cvrcek [:JasnaPaka]]

Attachment: Firefox 3.6.12 - ok

Comment 2

[Pavel Cvrcek [:JasnaPaka]]

Attachment: Firefox 4.0 b8pre - wrong

Comment 3

[Boris Zbarsky [:bzbarsky]]

Can you narrow down a regression range?

Comment 4

[Alice0775 White]

It seems to be OK If I set gfx.font_rendering.harfbuzz.level to 0.

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/cc06207827f4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre ID:20100902020913
Fails:
http://hg.mozilla.org/mozilla-central/rev/dc2939f2640d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre ID:20100902051352
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc06207827f4&tochange=dc2939f2640d
Candistae Bug:
dc2939f2640d	Jonathan Kew — bug 569531 - enable harfbuzz by default on windows. r=roc approval2.0=roc

Comment 5

[Alice0775 White]

Attachment: reduced html

It seems to OK, If used Arial as font-family.

Comment 6

[(mostly gone) XtC4UaLL [:xtc4uall]]

Alice, you might want to set "gfx.font_rendering.harfbuzz.level" to "1" manually to find a better Range before the Defaulting. That's how i narrowed down Bug 605043 :-).

Comment 7

[Alice0775 White]

Regression window( Forcibly set "gfx.font_rendering.harfbuzz.level" to 1):
Works:
http://hg.mozilla.org/mozilla-central/rev/37caccea3c81
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100611 Minefield/3.7a6pre ID:20100611124033
Fails:
http://hg.mozilla.org/mozilla-central/rev/e76d7213680c
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100611 Minefield/3.7a6pre ID:20100611131844
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37caccea3c81&tochange=e76d7213680c

Comment 8

[Karl Tomlinson (:karlt)]

Georgia has a glyph for U+030C COMBINING CARON.
Strangely it has a positive (non-zero) advance.  It has no anchors.

I guess the Direct Write shaper had some magic heuristics.

Did any other shapers make this look right?
i.e. Did it look right on any systems other than Windows Vista and 7?

Comment 9

[Alice0775 White]

The problem does not occur on Ubuntu 8.04.
http://hg.mozilla.org/mozilla-central/rev/f7016571b472
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101104 Firefox/4.0b8pre ID:20101104025921

Comment 10

[Boris Zbarsky [:bzbarsky]]

It looks right at some font sizes on Mac, as far as I can tell....

Comment 11

[Karl Tomlinson (:karlt)]

Uniscribe on XP doesn't do as well as DirectWrite, and HarfBuzz looks similar
to Uniscribe on XP.  Things actually look better on XP; I'm guessing that's because of a different version of Georgia.

Comment 12

[philippe (part-time)]

On OS X 10.6.4 with the 1104 build both the url and the testcase look wrong (and are correct on Gecko 1.9.2 and Safari / WebKit).

Comment 13

[Karl Tomlinson (:karlt)]

Thanks, philippe.
Does Georgia come installed by default with OS X 10.6.4?

Comment 14

[philippe (part-time)]

(In reply to comment #13)
> Thanks, philippe.
> Does Georgia come installed by default with OS X 10.6.4?

Yes.

Comment 15

[Karl Tomlinson (:karlt)]

OS -> All to mean Vista, 7, and 10.6

Comment 16

[Jonathan Kew [:jfkthame]]

This occurs because of a number of errors and deficiencies in the Georgia font - at least in version 5.00, which I have on both Windows and Mac systems here. It lacks GPOS support for "mark positioning", to properly place combining marks over base characters; the glyphs for combining mark characters (U+03xx) have non-zero widths; and in addition, the GDEF table incorrectly classifies the glyphs for the combining marks as "Base Glyph" rather than "Mark Glyph".

It seems that DirectWrite hacks around this error in *some* cases by automagically using the precomposed character in place of base+diacritic combinations (e.g. it renders <e, combining caron> using the single <ecaron> glyph); however, it doesn't do this consistently for all such combinations, as can be seen with the <u, combining ring above> sequence seen in the word "svůj" and several other instances in the example.

The behavior of other font-shaping systems varies a bit: in Safari, I see results similar to DirectWrite (the e-caron combination is handled, but u-ring renders with the ring mispositioned); in Minefield with harfbuzz disabled (i.e. using our Core Text path) even the u-ring is handled nicely. The difference here seems to be that the combining ring (U+030A) is entirely absent from Georgia, whereas the combining caron (U+030C) is present but improperly implemented. ...... Aha, that'll be why DW doesn't handle <u, combining ring above> nicely: the ring is missing from the font and so it falls back to a different font, and then it fails to combine the base+mark. Likewise in Safari. Our Core Text path, on the other hand, manages to use the precomposed <u-ring> character even though the ring alone was not supported in the font.

Comment 17

[Joe Drew (not getting mail)]

I think this needs to block. Behdad, do you have any ideas about how to fix this in Harfbuzz?

Comment 18

[Behdad Esfahbod]

Interesting.  I knew that Arabic fonts need a hack to fix non-spacing marks with positive advance and no GPOS table.  But haven't seen a Latin one.  Let me read Comment 16 fully and decide what to do.  We'll figure out a fix, don't worry.

Comment 19

[Behdad Esfahbod]

Can you send me the version that you have?  The one I found from XP doesn't have GDEF.

Comment 20

[Behdad Esfahbod]

I wrote down my (loooong) thoughts about how to handle this here:

  http://lists.freedesktop.org/archives/harfbuzz/2010-November/001029.html

Waiting for feedback but I expect to head to implementing the compose/decompose part pretty soon.

Comment 21

[ms-studio]

For the case that someone is working on this, here is another simple test case:

http://sandbox.4o4.ch/georgia/

Comment 23

[John P Baker]

(In reply to comment #20)
> I wrote down my (loooong) thoughts about how to handle this here:
> 
>   http://lists.freedesktop.org/archives/harfbuzz/2010-November/001029.html

It looks as if these are at
http://lists.freedesktop.org/archives/harfbuzz/2010-November/000953.html

Comment 24

[Behdad Esfahbod]

(In reply to comment #23)
> (In reply to comment #20)
> > I wrote down my (loooong) thoughts about how to handle this here:
> > 
> >   http://lists.freedesktop.org/archives/harfbuzz/2010-November/001029.html
> 
> It looks as if these are at
> http://lists.freedesktop.org/archives/harfbuzz/2010-November/000953.html

Thanks.  Don't know how that happened.

Comment 25

[ms-studio]

Some additional findings regarding the occurrence of this bug with French accented characters and the Georgia font:

If I open my test HTML file - http://sandbox.4o4.ch/georgia/index.html - in a text editor, the different occurrences of "é" look all the same. If I open it in a hex editor (HexFiend), it shows that they are different: 

The correct "é" appears in ASCII as √© and in hex as C3 A9.

The faulty "é" (rendered by FF4/Georgia as "´e") appears in ASCII as eÃÅ and in hex as 65 CC 81.

I hope this all makes sense for some of you.

Comment 27

[Jonathan Kew [:jfkthame]]

AFAIK, the issues here are now fixed, mainly thanks to a number of updates in harfbuzz. Closing this as WorksForMe. If there are remaining issues, please file new bugs with specific testcases for anything that's still a problem.

Comment 28

[Dominik Röttsches (drott)]

Jonathan, can you remember what was done in HarfBuzz to avoid this? We have this bug again cropping up in Chrome, compare https://bugs.chromium.org/p/chromium/issues/detail?id=673095.

Comment 29

[Jonathan Kew [:jfkthame]]

(Responded in the chromium bug.)