639185 - Font: some large characters followed by other small characters have the wrong spacing.

Status: RESOLVED INCOMPLETE

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

Description

[God]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

Capital T followed by a, e, y, u, g, r, c, o, comma, period, colon and semi-colon all have the lower cases appear under the hat of the T.
Another example is capital Y followed by comma, period, colon and semi-colon.

Reproducible: Always

Steps to Reproduce:
1. open Firefox 4.0 beta 12
2. Observe Tools menu
3. Select either main URL box or embedded search box
4. Type: "Tr Y:"
Actual Results:  
Characters following capital T and Y are incorrectly spaced.

Expected Results:  
Letter spacing should be standard. 
Example 1: Letters should be spaced so they begin after the hat of the T.
Example 2: Perform the same steps to reproduce in Firefox 3.6.15 it does NOT have this issue.

Advanced font settings had no effect on this issue.

This is with the default Firefox theme.

Classed as severity major: Font feature is broken. A simple legible font is probably the most important feature of a theme.

Comment 1

[Jonathan Kew [:jfkthame]]

Please attach a screenshot showing the problem you're seeing - thanks.

Comment 2

[God]

Attachment: Spacing issues with letters on font: tools menu, trouble shooting, Tr Y: and a few others.

Comment 3

[Ed Morley [:emorley]]

Could you see if the issue occurs with a new, empty profile:
http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_make-a-new-profile

...or using the latest nightly:
http://nightly.mozilla.org/

Comment 4

[God]

I made a new profile before installing the beta 12 and again before the nightly.

Currently the exact same issue appears with the font.

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Does setting "gfx.font_rendering.harfbuzz.level" to "0" correct the Issue?
What Font is used for the Menus in your Windows Theme?

Comment 6

[God]

Yes turning off the harfbuzz corrected the font spacing.
As a default it should be set to zero I would assume.

what is the intended function of that feature?
I have a hard time believing it was just to mess up the spacing following some Tall characters.

Comment 7

[Jonathan Kew [:jfkthame]]

What is the font being used (as asked in comment #5)?

I think you're seeing the result of kerning that is defined in the font, but is not supported by the old Windows text APIs, so it only takes effect when using the harfbuzz text system. Whether this is being done correctly (in accordance with the data in the font) is something we can check once you confirm what font is involved.

I notice you have text smoothing disabled; how does it look if you enable either "standard" (grayscale) or ClearType (subpixel) smoothing?

Comment 8

[God]

Tahoma size 8

Standard or cleartype smoothing didn't have any effect on the issue.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: screenshot comparing Tahoma with and without kerning

Tahoma has quite "tight" kerning of certain letter pairs, especially lowercase letters following "T", as shown in this comparison (using larger text so the effect is easier to see).

The old Windows text APIs don't implement kerning, so most older programs just ignore it, but harfbuzz handles it and therefore you get the text rendered with the kerning specified in the font.

Comment 11

[al_9x]

> This is not a bug in Firefox

Are you suggesting it should be ignored?  Whatever the underlying culprit, it makes text in 4.0 less readable than in 3.6

https://bug643882.bugzilla.mozilla.org/attachment.cgi?id=521010

Comment 12

[Jonathan Kew [:jfkthame]]

Does it change if you go to about:config and set the option gfx.font_rendering.harfbuzz.level to zero? I think that will probably disable the kerning - but be aware that it will also disable a range of typographic features that some websites (especially with custom downloadable fonts) may be designed to use.

Comment 13

[al_9x]

(In reply to comment #12)
> Does it change if you go to about:config and set the option
> gfx.font_rendering.harfbuzz.level to zero?

Yes, that resolves it, should it not be possible to code in some exception, disabling kerning for Tahoma in chrome so Fx4 can look normal without having to disable this harfbuzz.  Also, please provide more details about the consequences of turning it off.

Comment 14

[pfc]

I was relieved when I discovered this and applied the "fix", because I was thinking about reverting to FF 3.x. It was really annoying, because I'm using an 22" CRT with 1920x1440 resolution and some words beginning with "Tu", "Yu", etc. looked really horrible - instead of two letters, one weird.
Maybe you could just check if someone has Win XP and if, then automatically set that variable to "0" ?
Also, I would really like to get some info about that variable and what exactly setting it to "0" does.

Comment 15

[al_9x]

(In reply to comment #12)
> Does it change if you go to about:config and set the option
> gfx.font_rendering.harfbuzz.level to zero?

@Jonathan Kew - please review and comment

gfx.font_rendering.harfbuzz.level pref has been removed by Bug 623495, replaced by gfx.font_rendering.harfbuzz.scripts which appears to be a bitfield, with these bits:

enum ShapingType {
    SHAPING_DEFAULT   = 0x0001,
    SHAPING_ARABIC    = 0x0002,
    SHAPING_HEBREW    = 0x0004,
    SHAPING_HANGUL    = 0x0008,
    SHAPING_MONGOLIAN = 0x0010,
    SHAPING_INDIC     = 0x0020
};

so gfx.font_rendering.harfbuzz.scripts=0 disables harfbuzz and restores normal font rendering on xp

However, there is a problem (4.0 & 5.0):
http://forums.mozillazine.org/viewtopic.php?f=38&t=2158847&p=10937255#p10937255

I ran across and confirmed the above report of messed up spacing when printing, caused by turning off harfbuzz.  Jonathan, what's going on there?  Can we have proper font display and printing on xp at the same time, as in 3.6?  Fx 3.6 prints the page in question just fine, so it should be possible to print properly with harfbuzz disabled, or allow harfbuzz for printing when otherwise disabled.

Comment 16

[Jonathan Kew [:jfkthame]]

The printing problem reminds me of bug 635768, but that was specific to GDI printing when harfbuzz _is_ being used; it looks like there might be a similar issue in the non-harfbuzz path. It may also depend on the type of font involved (TrueType/OpenType vs old bitmap or type1 fonts); see bug 640528.

The printing issue should be treated separately from this report, anyway - either it's one of the already-filed printing bugs, or it's a new bug, but it is not _this_ bug.

As for this bug, it should probably be re-titled more like "WinXP users don't like the kerning that's specified in Tahoma". That's really the issue here. Maybe we should figure out some way to override it without disabling harfbuzz altogether (which means losing lots of more advanced font features).

Comment 17

[al_9x]

(In reply to comment #16)
> The printing problem reminds me of bug 635768, but that was specific to GDI
> printing when harfbuzz _is_ being used; it looks like there might be a
> similar issue in the non-harfbuzz path. It may also depend on the type of
> font involved (TrueType/OpenType vs old bitmap or type1 fonts); see bug
> 640528.
> 
> The printing issue should be treated separately from this report, anyway -
> either it's one of the already-filed printing bugs, or it's a new bug, but
> it is not _this_ bug.

Bug 667242

> 
> As for this bug, it should probably be re-titled more like "WinXP users
> don't like the kerning that's specified in Tahoma". That's really the issue
> here.

That makes it sound like some irrational caprice on the part of xp users, but it's not.  From the release of XP, neither any os app nor any other app that I'm aware of, rendered Tahoma with kerning.  That combined with the fact that it looks worse, less readable, distracting, in short wrong, strongly suggests that Tahoma was not meant to be rendered with kerning.  So the problem is not users, but Fx introducing an unreasonable and unwanted change, "fixing" what wasn't broken.

> Maybe we should figure out some way to override it without disabling
> harfbuzz altogether (which means losing lots of more advanced font features).

That seem to be the right approach, I asked you if that was possible, is it?

> should it not be possible to code in some exception,
> disabling kerning for Tahoma in chrome so Fx4 can look normal without having
> to disable this harfbuzz.  Also, please provide more details about the
> consequences of turning it off.

Comment 18

[God]

41% of users run XP. It's amusing but somewhat typical of lazy devs to say "by design"

As far as I am aware, HarfBuzz is Behdad Esfahbod and Ryan Lortie's way of converting Unicode text to positioned glyphs. It was originally intended for OpenType fonts.

Comment 19

[al_9x]

(In reply to comment #18)
> 41% of users run XP. It's amusing but somewhat typical of lazy devs to say
> "by design"

Yes unfortunately, there is no urgency to correct a problem they inflicted on a significant % of windows users.  We are expected to be satisfied by a doctrinaire appeal to technical "correctness" (kerning)  99.99% don't know what the hell that is, but we do know that font rendering is messed up.

Font rendering should strive for inconspicuous "transparency" so as to let you focus on the content and not be distracted by individual glyphs.  Rendering that prompts a mental WTF periodically on certain letter combinations is clearly problematic.

> 
> As far as I am aware, HarfBuzz is Behdad Esfahbod and Ryan Lortie's way of
> converting Unicode text to positioned glyphs. It was originally intended for
> OpenType fonts.

Supposedly it makes possible some fancy effects that are mostly good for demos, but if all you want is simple, clear, readable text, nothing beats native rendering with cleartype.  So I am happy to turn it off, at least as a temporary workaround, but that creates a printing issue (Bug 667242).  Jonathan Kew, please give it some attention.

Comment 20

[gallium.arsenide]

I just wanted to report that I also see the kerning problem in Firefox 4 and 5, Windows XP, "classic" as well as standard XP style.

I'm totally with al_9x:  I do know what kerning is, but I don't have access to fix the (ill-chosen) kerning embedded in the font.  Like most users, I spend way more time looking at the screen than printing it out, so for now I have also turned it off, but it sure would be nice if we can have it both display and print in a legible, nonjarring way (the way it is in every other piece of software I've encountered, including previous versions of Firefox).

Comment 21

[al_9x]

Bug 672456 - inflated character spacing in svg file when harfbuzz is disabled

Comment 22

[al_9x]

I am also seeing occasional inflated spacing (with harfbuzz disabled) in various text areas and input boxes.  However I don't know how to repro this reliably, a browser restart resets it to normal and I don't know what triggers it.

Comment 23

[al_9x]

(In reply to al_9x from comment #22)
> I am also seeing occasional inflated spacing (with harfbuzz disabled) in
> various text areas and input boxes.  However I don't know how to repro this
> reliably, a browser restart resets it to normal and I don't know what
> triggers it.

found a way to repro consistently:
Bug 682709 - inflated and inconsistent character spacing in input boxes and text areas (under certain circumstances) when harfbuzz is disabled

I have now reported three harfbuzz disabled spacing bugs:
Bug 667242 - printing
Bug 672456 - svg
Bug 682709 - html

disabling harfbuzz was recommended to address this spacing (kerning) issue, but with these bugs it's approaching jumping from a frying pan into the fire.

None of these problems existed in 3.6, it should be possible to render everything properly without harfbuzz.  However if you are going to ignore those bugs, then please implement the xp tahoma kerning exception, which should remove the impetus to disable harfbuzz

Comment 24

[_ck_]

This problem is confirmed to STILL EXIST under Firefox 10.0 final release under Windows XP SP3 (32bit)

Same as previously here http://forums.mozillazine.org/viewtopic.php?f=9&t=2302745

If I set harfbuzz to 2 instead of the default 3, the problem goes away.

Comment 25

[al_9x]

disabling harfbuzz is effectively pointless in 12.0 (Bug 736362) as it creates more problems than it solves.

Are you trying to make Fx use highly unpleasant on XP?  Either fix the xp kerning issues or the harfbuzz disabled issues.  It's ridiculous that version 12 can not render text at least as well as 3.6.

Comment 26

[_ck_]

Harfbuzz completely broke again using Firefox 12 under Windows XP 32-bit

Under Firefox 11 I was able to set harfbuzz to 2 and get nice results.

Now 2 and the default of 3 both have weird results depending on the page.

Set it to zero which must disable it and it looks fine to me so far.

Comment 27

[Dan]

This is not confined to Tahoma font.  It also occurs with Times New Roman at larger file sizes.  Try typing "ToT" in Times New Roman and enlarging to 20pt to see what I mean.  The lowercase o is not centered between the two Ts.

I think this is a harfbuzz bug in XP.  I don't think this is a font issue per say because the same fonts in Windows Vista/7 have correct spacing consistent with other browsers/programs.  I even copied the Windows 7 font file to XP in case MS made changes.  Even with the Win7 font file copied to XP, the spacing is still off in XP.

Comment 28

[Alin Ilea, Desktop Test Engineering [pto until 01.09]]

Marking this as Resolved > Incomplete since there are no new updates for 10 years, the issue is win XP specific and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.