410954 - [mac] Latin font incorrect/bold after certain Hebrew character

Status: RESOLVED FIXED

(Core :: Graphics, defect, P4)

Description

[Uri Bernstein]

Attachment: testcase

On a page with Hebrew and English text, using the default fonts, the font used to display English becomes sans-serif and bold, following a specific Hebrew character (U+05BE HEBREW PUNCTUATION MAQAF).

This seems to also depend on the length and position of the Hebrew and English texts. There might be other characters that trigger this bug as well.

Comment 1

[Uri Bernstein]

Attachment: screenshot

Comment 2

[Uri Bernstein]

This is on OS X 10.4.11 PPC, BTW.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I see serif and italics on 10.5.1 Intel, so it's only half as broken ;)

Comment 4

[Uri Bernstein]

Attachment: testcase #2

In this utf-8 testcase the Hebrew fonts are messed up, and the culprit is the NIS sign (U+20AA).
This is based on a google.com search result page, where a NIS sign appearing somewhere in the middle affected the font of (almost) everything beneath it.

Comment 5

[John Daggett (:jtd)]

I'm fairly sure I know the cause of this but I can't reproduce the same results you're seeing.  My guess is that your font settings are slightly different than the defaults or the fonts you have available on your system are different.

If possible, could you attach the following:

(1) the prefs.js for the profile you used
(e.g. ~/Library/Application Support/Firefox/Profiles/xxxxx/prefs.js)

(2) a listing of the fonts on your system

ls -l /System/Library/Fonts
ls -l /Library/Fonts
ls -l ~/Library/Fonts

Another way to track this down if you have a debug build available is to enable text run dumping in gfxAtsuiFonts.cpp by uncommenting the line here:

http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/gfxAtsuiFonts.cpp#69

Then enable logging:

export NSPR_LOG_MODULES=atsuiTextRun:5
export NSPR_LOG_FILE=atsuiTextRun.log

In the output file, for each text run you'll see the content of the text run along with the fonts that were matched:

InitTextRun 3fd21910 fontgroup 3f9b39b0 (sans-serif) len 6 TEXTRUN "foobar" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fd21910 fontgroup 3f9b39b0 font 3fd21c60 match Times-Roman (1-6)
InitTextRun 3fd25fb0 fontgroup 3f9b39b0 (sans-serif) len 3 TEXTRUN "א־ב" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fd25fb0 fontgroup 3f9b39b0 font 3fd0d830 match ArialHebrew (1-1)
InitTextRun 3fd25fb0 fontgroup 3f9b39b0 font 35830c90 match TimesNewRomanPSMT (2-1)
InitTextRun 3fd25fb0 fontgroup 3f9b39b0 font 3fd0d830 match ArialHebrew (3-1)
InitTextRun 3fd219a0 fontgroup 3f9b39b0 (sans-serif) len 6 TEXTRUN "barfoo" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fd219a0 fontgroup 3f9b39b0 font 35830c90 match TimesNewRomanPSMT (1-6)

The font match information indicates the font matched for a specific subsection of the text run above it, the numbers in () indicate position-length.  As you can see above, with my profile "barfoo" is matched with "Times New Roman" which is not correct, it should be matched with "Times".  I spotted this last week, the code for looking up fonts automatically adds the font to the font group:

http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/gfxAtsuiFonts.cpp#469

When the script changes, fonts in the font group will be considered first and this will be incorrect.  This same routine on Windows doesn't do this:

http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/gfxWindowsFonts.cpp#464

Comment 6

[Uri Bernstein]

Attachment: prefs.js

prefs.js from a clean, new profile (which I see the problem with).

Comment 7

[Uri Bernstein]

Attachment: font list

This lists fonts from the three folders (the user one is empty).

Comment 8

[Uri Bernstein]

I don't have a recent debug build right now. If I have time, I'll build one, and report the results here.

Comment 9

[Uri Bernstein]

Here's the log from my debug build:

-1610551928[1506cb0]: InitTextRun 35de88a0 fontgroup 2be1dc80 (sans-serif) len 6 TEXTRUN "foobar" ENDTEXTRUN
-1610551928[1506cb0]: InitTextRun font: ArialHebrew
-1610551928[1506cb0]: InitTextRun 35de88a0 fontgroup 2be1dc80 font 2be99140 match Times-Roman (1-6)
-1610551928[1506cb0]: InitTextRun 35d46250 fontgroup 2be1dc80 (sans-serif) len 3 TEXTRUN "א־ב" ENDTEXTRUN
-1610551928[1506cb0]: InitTextRun font: ArialHebrew
-1610551928[1506cb0]: InitTextRun 35d46250 fontgroup 2be1dc80 font 2be99400 match ArialHebrew (1-1)
-1610551928[1506cb0]: InitTextRun 35d46250 fontgroup 2be1dc80 font 35d586c0 match LucidaGrande-Bold (2-1)
-1610551928[1506cb0]: InitTextRun 35d46250 fontgroup 2be1dc80 font 2be99400 match ArialHebrew (3-1)
-1610551928[1506cb0]: InitTextRun 35d90e00 fontgroup 2be1dc80 (sans-serif) len 6 TEXTRUN "barfoo" ENDTEXTRUN
-1610551928[1506cb0]: InitTextRun font: ArialHebrew
-1610551928[1506cb0]: InitTextRun 35d90e00 fontgroup 2be1dc80 font 35d586c0 match LucidaGrande-Bold (1-6)

Lucida Grande Bold is picked for the MAQAF in the middle of the second textrun, and then used for the third textrun as well.

Comment 10

[John Daggett (:jtd)]

Steps to reproduce:

1. Remove fonts from user font directory (~/Library/Fonts)
2. Open testcase

Result: with default fonts and default prefs, 'barfoo' is displayed using Lucida Grande Bold

There are actually two bugs here:

1. fallback fonts are appended to the end of font group list when used

The default pref settings will use Arial Hebrew for Hebrew codepoints.  However, the MAQAF character (U+05BE) is not available in Arial Hebrew so fallback will occur to system fonts.  Only Lucida Grande and Lucida Grande Bold contain glyphs for this character.

Solution: remove automatic insertion of font face into font group upon lookup in GetOrMakeFont (gfxAtsuiFonts version).

2. a bold face is chosen instead of a normal weight face

This is because the font matching code attempts to match the weight of the font used for preceding characters, in this case Arial Hebrew.  Arial Hebrew has a weight of 400, Lucida Grande has a weight of 500, so they don't match exactly and the relative ranks of the normal and bold face are the same.  The tie between two fonts is always broken by taking the latter one.

Solution: add code to bump the rank of "nearby" weight faces in gfxQuartzFontCache::FindFontForCharProc.

Comment 11

[John Daggett (:jtd)]

Attachment: patch, v.0.1, don't append font to group list in GetOrMakeFont

Font matching output with testcase and patch build:

InitTextRun 3fc5a9b0 fontgroup 3fc59890 (sans-serif) len 6 TEXTRUN "foobar" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fc5a9b0 fontgroup 3fc59890 font 3fc5acb0 match Times-Roman (1-6)
InitTextRun 3fc5b2f0 fontgroup 3fc59890 (sans-serif) len 3 TEXTRUN "א־ב" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fc5b2f0 fontgroup 3fc59890 font 3fc59aa0 match ArialHebrew (1-1)
InitTextRun 3fc5b2f0 fontgroup 3fc59890 font 3fc8eb50 match LucidaGrande-Bold (2-1)
InitTextRun 3fc5b2f0 fontgroup 3fc59890 font 3fc59aa0 match ArialHebrew (3-1)
InitTextRun 3fc5aa40 fontgroup 3fc59890 (sans-serif) len 6 TEXTRUN "barfoo" ENDTEXTRUN
InitTextRun font: ArialHebrew
InitTextRun 3fc5aa40 fontgroup 3fc59890 font 3fc5acb0 match Times-Roman (1-6)

Note that barfoo matches against Times Roman, not Lucida Grande or Times New Roman.  Lucida Grande Bold is still matched, that fix coming up...

Comment 12

[John Daggett (:jtd)]

Attachment: patch, v.1.0, favor font faces closeby in weight

Comment 13

[John Daggett (:jtd)]

Attachment: patch, v.1.0, non-idiotic form

oops, sorry about that...