288047 - [10.4] [10.5] Incorrect page layout (cursor offset in text fields) caused by particular fonts

Status: RESOLVED INCOMPLETE

(Core Graveyard :: GFX: Mac, defect)

Description

[Serge Polevitzky]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/408 (KHTML, like Gecko) Safari/407
Build Identifier: Firefox 1.0.2

When I view the site with Firefox, most of the first page looks like Klingon.  But when I copy & paste, (as 
here: "HOW TO DO ANYTHING PHOTOGRAPHIC" comes out and looks fine).  With Safari, the first page 
looks normal.

Running Tiger 8a420

Reproducible: Always




Say, how can I attach a screen shot ?  Tx, Serge

[e-mail]

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> Say, how can I attach a screen shot ?  Tx, Serge

Use the "Create a new attachment" link above.

Comment 2

[L. H.]

Please do not file bugs running a beta unreleased system.

Comment 3

[José Jeria]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050329
Firefox/1.0+

Comment 4

[David Becker]

Attachment: Example of text rendering problems

I have text rendering problems on the release version of Tiger.  Not quite as
bad as this person describes, though.  See attached screenshot..

Comment 5

[David Becker]

After much hacking around, I got Firefox to compile under Tiger, on the thought
that some SDK modification might fix the text rendering problem.  No such luck,
a native Tiger build still exhibits the problem.  Also note that text in
<TEXTAREA> boxes is *really* messed up...

Comment 6

[m-mozilla]

Attachment: Another example of FF on tiger rendering issues.

I am seeing similar rendering issues now that I have upgraded to Mac OS X
Tiger.

I have issues in Thunderbird as well during html composition.  I'll file a bug
with screenshot there as well.

Comment 7

[m-mozilla]

Attachment: Another example of FF on tiger rendering issues.

I am seeing similar rendering issues now that I have upgraded to Mac OS X
Tiger.

I have issues in Thunderbird as well during html composition.  I'll file a bug
with screenshot there as well.

Comment 8

[m-mozilla]

I figured out what was causing this, at least for me.

For some reason, I had a full copy of /System/Library/{FontCollections,Fonts} in
~/Library

I did the following:

cd ~/Library
tar cf ~/LibraryUserFonts.tar FontCollections Fonts
rm -rf FontCollections/*
rm -rf Fonts/*

log out of desktop

log in

Everything's now fine.

Comment 9

[David Becker]

Nice(In reply to comment #8)
> I figured out what was causing this, at least for me.
<snip>

Nice work!  I can confirm this fix worked for me too.  Odd.  Had you upgraded to
Tiger like me?  Perhaps the fonts in ~/Library were remnants from 10.3 and the
new fonts have different hinting information?  I wonder why ff is the only thing
I've seen with problems though?

Comment 10

[Simon Fraser [no longer active]]

Can someone find out which fonts in particular are the problem? What font is the
page using? Put them back one by one, and see which causes the issue.

Comment 11

[David Becker]

(In reply to comment #10)
> Can someone find out which fonts in particular are the problem? What font is the
> page using? Put them back one by one, and see which causes the issue.

I haven't yet narrowed it down (as you can imagine, this is tedious).  However,
I can tell you what it ISN'T.  It's NOT anything in ~/Library/FontCollections/*
and it's NOT any of the arial*.ttf fonts.  I'll try some more later.

Comment 12

[David Becker]

Attachment: Font that causes the problem

I discovered I did not have to logout or reboot to reproduce the problem, just
adding and removing fonts from ~/Library/Fonts and restarting Firefox was
enough.  That allowed me to move more quickly with the testing.  I've narrowed
it down to the Verdana.ttf font.  The other fonts seem to make no difference. 
Curiously, this font does not exist in /Library/Fonts at all, though there is
an empty Verdana file placeholder (0 bytes) -- whatever that is for...

Comment 13

[Ian Brandt]

(In reply to comment #11)
> and it's NOT any of the arial*.ttf fonts.

I experience this with any TTF borrowed from Windows XP Pro/Virtual PC,
including arial.ttf.

Comment 14

[Ian Brandt]

*** Bug 292461 has been marked as a duplicate of this bug. ***

Comment 15

[Uri Bernstein]

Confirming, based on confirmed duplicate.

Comment 16

[Ian Brandt]

https://bugzilla.mozilla.org/show_bug.cgi?id=176272 reports different symptoms,
but it seems like it shares the same Gecko/TTF cause.  That bug is older, but
this one seems to have identified the issue, so I'm not sure which should be
marked a duplicate of the other.  I don't believe I have the access to do
either, so there you have it.

Comment 17

[Samuel Sidler (old account; do not CC)]

I don't think this is limited to Verdana. See bug 299098. I can only reproduce
this with the Vera fonts. There's a testcase in that bug. If they're the same,
please dupe.

Comment 18

[Josh Aas]

I recommend not blocking 1.8b4.

Someone should try this with tomorrow's nightly build to see if the fix from bug
300721 did anything.

Comment 19

[Simon Fraser [no longer active]]

*** Bug 299098 has been marked as a duplicate of this bug. ***

Comment 20

[Vincent Lefevre]

*** Bug 302175 has been marked as a duplicate of this bug. ***

Comment 21

[Vincent Lefevre]

The workaround proposed in Comment #8 doesn't work for me (but since I have got
my Mac for a few days, I didn't upgrade from a previous Mac OS X version).

I've found the problem. When I select a new font in the Preferences, the page
layout is fixed in the current document window, but the new font isn't used
(yet). But if I click on the Reload button, then the new font is used, but with
incorrect spacing! To fix the spacing temporarily, I can select a new font.

So, the workaround is the following: in the preferences "Fonts & Colors", click
on "Advanced...", then on "OK" (to select the *same* fonts). Note: you may need
to click on Reload once or twice for each page already loaded.

Comment 22

[Vincent Lefevre]

Attachment: Example showing the scrollbar drawn at a wrong place after a font config change

This is what I obtained just after changing a font in the preferences: the
scrollbar was drawn more on the left (but the real scrollbar was still on the
right).

Comment 23

[Andrew Reilly]

(In reply to comment #21)
> I've found the problem. When I select a new font in the Preferences, the page
> layout is fixed in the current document window, but the new font isn't used
> (yet). But if I click on the Reload button, then the new font is used, but with
> incorrect spacing! To fix the spacing temporarily, I can select a new font.
> 
> So, the workaround is the following: in the preferences "Fonts & Colors", click
> on "Advanced...", then on "OK" (to select the *same* fonts). Note: you may need
> to click on Reload once or twice for each page already loaded.

This didn't work for me, but the suggestion made me try a few things that I hadn't, before, and lo: I 
have found a *single* change that reliably turns the problem on and off, for me.

Consider the electronic design URL from bug 299098.  This page sets its own fonts and causes me 
problems, so I did not expect this fix to help.  I started by hitting the "reset" button in the fonts settings 
panel, to start from scratch, and lo: the page and the links rendered properly.  One by one, I reset the 
fonts in the Advanced pane to my usual preferences (bitstream vera series, sans-serif default).  I forced 
a refresh of the page after every change.  NONE of the font changes made the page render incorrectly, 
UNTIL I changed the font size from the default 16 down to my usual 13.  That default size change, even 
though it didn't change the size of the text on the page, turned the layout bug on.  Resetting the 
default size back to 16 turned the bug off.

On the flip side: the http://bsdnews.com web site still produces text that flows past the right hand 
article border irrespective of the font setting, and even when the defaults have been "reset" to the 
factory settings.  Hope this helps...

Comment 24

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

I think comment 21 is bug 191032.

Comment 25

[Vincent Lefevre]

> I think comment 21 is bug 191032.

Partly. Until I changed the fonts, I got such display problems at Firefox startup.

Comment 26

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

*** Bug 308989 has been marked as a duplicate of this bug. ***

Comment 27

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

*** Bug 309096 has been marked as a duplicate of this bug. ***

Comment 28

[Sébastien Stormacq]

*** Bug 313136 has been marked as a duplicate of this bug. ***

Comment 29

[Andrew Reilly]

Just downloaded Camino 1.0a1, and can report some improvement (entering text in this text box seems to work properly, now), but several pages still exhibit the bad rendering problem (overlapping styled text and text running past the end of boxes).  bsdnews.com and the EEdesign article from bug 299098, for example.

Comment 30

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

*** Bug 316286 has been marked as a duplicate of this bug. ***

Comment 31

[Gena Wilson]

*** Bug 319523 has been marked as a duplicate of this bug. ***

Comment 32

[Gena Wilson]

I'm seeing layout issues with Georgia on Tiger -- the white space preceding links is ignored on pages that use this font, causing text overlapping or crowding.

Screenshots and test cases are on Bug 319523

Comment 33

[Gena Wilson]

Georgia issues have been fixed in Camino nightly builds and 1.0b2.

Comment 34

[Simon Fraser [no longer active]]

(In reply to comment #33)
> Georgia issues have been fixed in Camino nightly builds and 1.0b2.

Fixed by what? Did this change in 10.4.4?

Comment 35

[Gena Wilson]

I was able to verify the Georgia links displaying correctly, without overlaps, on a machine running 10.4.3 as well (though I couldn't reproduce this issue on that same machine with earlier builds, either).  

However, the machine I originally noticed the fixed links on was indeed upgraded to 10.4.4 recently, so it's quite possible that was the cause --  unfortunately, I can't pinpoint it more specifically.  Perhaps the next person to upgrade to 10.4.4 could test this before and after if they see these issues?

Comment 36

[Andrew Reilly]

Attachment: Screen capture of bsdnews.com showing mis-formatting still in camino 1.0b2

I see no change with 2005122909 1.0b2, on 10.4.4.  Here are a couple of screen captures of the web page that I mentioned at first: bsdnews.com, one from stock safari, the other from camino 1.0b2.  I've sized the windows to be as close to identical as I can, and both browsers are using the same fonts.  You can see clearly that Camino/Gecko is losing the space in front of the links, and has badly messed up the word wrap on the second line of the comment body.

Comment 37

[Andrew Reilly]

Attachment: image 2 of 2 (goes with camino1.0b2.gif) Safari rendering of same page

See comment for camino1.0b2.gif

Comment 38

[philippe (part-time)]

The Bitstream Vera package is another one that causes display problems.
http://www.gnome.org/fonts/

Symptoms: white-space before an inline element (span, b, a, code, etc) vanishes.

Basic test page that use this font as first choice:
http://dev.l-c-n.com/gecko/bitstream-288047.php

Comment 39

[HJ]

I upgraded from 10.3.9 to 10.4.4 yesterday and immediately hit this bug with <Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1>.

the workaround in comment #8 works for me. seems a bit Draconian, and i haven't had a chance to check if any of my other apps are affected, but at least for FF it does the trick.

Comment 40

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

*** Bug 333093 has been marked as a duplicate of this bug. ***

Comment 41

[Edward Meehan]

Attachment: text render issue

Comment 42

[Edward Meehan]

*** Bug 337707 has been marked as a duplicate of this bug. ***

Comment 43

[is+mozilla]

I have also experienced behaviour similar to this bug,. However, none of the proposed workk arounds wokred for me. However, changing the default character encoding from UTF-8 to iso8859-1 (or selecting 8859-1 manually) did fix the problem, at least for some pages. See the attached screen shots. I am using the exact same fonts (Time New Roman 14pt) for both shots. 

Comment 44

[is+mozilla]

Attachment: Screen shot bug 288047 page w/o rendering issues. (Thought this as an encoding issue, but is a font issue).

Comment 45

[is+mozilla]

Attachment: Screen shot bug 288047 page w/ rendering issues. (Thought this was an encoding issue, but is a font issue)

Comment 46

[is+mozilla]

Oops. I lied. It was a font problem. I was changing the serif font, but this page is monospaced. Once I changed the monospace font, every thing work. 

Comment 47

[Uri Bernstein]

*** Bug 345974 has been marked as a duplicate of this bug. ***

Comment 48

[jiho]

Given al previous attempts to track down this one I tried to be systematic and produced a test case. The results are attached as a PDF.
My conclusions from this test are:
- the bad font rendering, with white space before spans and links is present when the font is duplicated on the system.
- it also causes problems with accented characters
- disabling the duplicate via font book restaures the correct layout but does not solve the problem with acccented characters.
- forcing to use the duplicated font (by defaulting to it or by defaulting to it and not allowing the page to choose it's own) recreates the problem, even when the  duplicate is disabled, as if Firefox did not honored the "disabled" setting.

In addition, some more tweaks on my system suggested me that:
- the problem with the accents appears only when the particular font in use is duplicated
- the layout problem seems to be broader. Indeed, I added many fonts to my system by with no font marked as duplicate by Foot Book and the layout problem is present even when not using a system font (=when using a font which is surely not duplicated). It looks like as soon a font is duplicated/close to an other one somewhere, the problems appears with all fonts (with few execeptions such as Lucida Grande).
To sum up: it is really weird...

Comment 49

[jiho]

Attachment: Result of a systematic test on the layout and accents problem

Refer to this file for the results of the test mentioned in the comment above

Comment 50

[Uri Bernstein]

*** Bug 348548 has been marked as a duplicate of this bug. ***

Comment 51

[Shoshannah Forbes]

Yup, I am seeing this with all ttf Hebrew fonts (non-ttf Hebrew fonts seem to be ok).
You can see this for exmaple with the free (as in speech & beer) Culmus Mac fonts:
http://homepage.mac.com/alon.weinstein/Culmus_TTF_Fonts_Families.dmg.zip

Comment 52

[Andrew Reilly]

Just acquired FireFox 2.0b2, and this problem persists.  I have no fonts in my own directory, and the problem is not exclusive to Bitstream Vera, half a dozen other fonts on my Mac (standard? who knows) behave the same way, but most don't.  For example, Lucida Sans Unicode and Verdana are also bad, while Helvetica, Helvetica Nue and Ariel all work.  This bugs me, because I *like* the broken ones better...

(Weirdly, even though I've removed all font duplicates, and have no home/Library/Fonts files, FontBook still claims (with that dot) that my Bitstream Vera set are duplicates.  Nothing happens when I tell it to resolve this...)

(This on 10.4.7)

Comment 53

[Cameron Kaiser [:spectre]]

This is just a random thing, but did changing font size help?

In Camino, I changed the Proportional font size from 16 to 14 and suddenly the problems got better. The only remnant is that underlines in hyperlinks don't quite go all the way, but the rendering is tremendously improved. Camino 1.0.3 on 10.4.7, about to upgrade to 10.4.8 when I can get a free minute. Btw, this also seems to work nicely on the Firefox 2 RC.

Comment 54

[Cameron Kaiser [:spectre]]

This is just a random thing, but did changing font size help?

In Camino, I changed the Proportional font size from 16 to 14 (the default is 16) and suddenly the problems got better. The only remnant is that underlines in hyperlinks don't quite go all the way, but the rendering is tremendously improved. Camino 1.0.3 on 10.4.7, about to upgrade to 10.4.8 when I can get a free minute. Btw, this also seems to work nicely on the Firefox 2 RC.

Comment 55

[Cameron Kaiser [:spectre]]

One other thing (sorry about the bugspam): I noticed with interest that 16-point Times isn't shown as a "choice" when I pick a font -- I have to enter 16 as a point size manually. Using 14 or 18 point Times, which are both listed and selectable, does not exhibit the bug (except for underlines).

Comment 56

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

*** Bug 358664 has been marked as a duplicate of this bug. ***

Comment 57

[sci-fi]

Thought I'd chime-in so's to get me addy added to the CC list.

I've seen this in Firefox releases & nightlies, Minefield trunk builds (I'm using 20070110 right now), and Camino releases & nightlies, for-ever that I can remember.

Inside these browsers, I have the Prefs Content Fonts Advanced set to Apple's provided /System/Library/Fonts versions of Times (17), Courier (15), and Helvetica (17) (and they are not dup'd anywhere else in /Library/Fonts or in ~/Library/Fonts).  I have a few hundred fonts installed in /Library/Fonts, and we can test other kinds e.g. Times New, Courier New, Helv Neue, ITC versions, etc., with similar results.

One quick fix for me is to hit Cmd-Plus after a page is finished rendering -- then the various text hiliting is reflowed and usually properly kerned & spaced.  If I hit Cmd-Minus to go back to original Advanced settings, we again see the bad rendering (it took some time for each switch, i.e. doesn't seem to be cached when we do this 'live' fontsize switching).

Firefox & Minefield will honour Cmd-Plus on an about:blank page while Camino won't -- but this is another trick to "pre-prepare" for this rendering bug, if you see what I'm trying to say here.  After about:blank fontsize is increased, usually every page afterwards is rendered okay as long as you stay at that size or larger.

It seems that enlarging the fontsize via Prefs Content Fonts Advanced setting doesn't really help this bug at all times -- the trick seems to be to get the code to recalculate something _after_ a browser window is shown (whether as I said about:blank or already filled with useful text).  But no matter what, if Cmd-Minus takes you back to the Prefs setting (or smaller), we see the bad rendering.  This is a strong hint.

Thanks for letting me put my blurb in here.  I'll stay tuned...  :)

Comment 59

[Vincent Lefevre]

Attachment: Screenshot of http://www.alglib.net/news.php

While I've no longer noticed this bug until now (including on the URL provided for this bug), I've just seen that it makes the www.alglib.net web site unreadable. The web server declares the windows-1251 charset, so that Firefox uses Cyrillic preferences (these should be the default ones, provided with Firefox).

Comment 61

[mathew]

I'm having font rendering problems with a brand new Mac, factory install of 10.4.10, using the RedHat Liberation fonts downloaded directly from RedHat. Specifically, Liberation Sans. I've checked that there's only 1 copy of Liberation Sans on the hard drive, and it verifies as OK in Font Book.

I've also tried configuring Safari to use the same font, and it displays pages just fine. Will attach meta-Safari.png and meta-Firefox.png. Compare the two, it's pretty embarrassing for Firefox.

Cmd-+ and Cmd-- don't fix the problem. Changing font size to Mozilla default (16) does not fix the problem.

However, changing font to Arial or Helvetica Neue, they work.

Comment 62

[mathew]

Attachment: Firefox rendering an article on the front page of Slashdot, with RedHat Liberation Sans as font.

Comment 63

[mathew]

Attachment: Safari rendering an article on the front page of Slashdot, with RedHat Liberation Sans as font.

Comment 64

[Jonathan]

Just commenting to get on the CC list... I have a boatload of fonts installed.  I see problems in a few main areas:
1. Textarea boxes with a non-default font applied via CSS
2. After bold or italic text
3. Some text spans past the edge of the screen/table/etc.

Comment 66

[Andrew Reilly]

(In reply to comment #52)
> Just acquired FireFox 2.0b2, and this problem persists.

I'm currently running FireFox 3.0b3 and the problem is completely resolved.  So YAY for the new gecko engine!

(System is now 10.4.11)

Comment 67

[Chris Lawson (gone)]

Comment 57 suggests this still happens with current trunk (Gecko 1.9b) builds, but comment 66 suggests that it doesn't.

Since there have been a large number of font code changes on trunk and the vast majority of comments confirming this bug have been with branch builds, can someone who was seeing this with Camino 1.x or Firefox 2 please attempt to replicate the problem using Camino 2.0pre (trunk nightly) or Firefox 3.0b3 (or a Minefield trunk nightly) on both 10.4 and 10.5?

Bug 405872 comment 5 suggests this bug is definitely branch-only and thus the "Trunk" designation appears no longer to be correct, but I'd just like some confirmation, ideally from [e-mail] or anyone else who may have experienced this with a Gecko 1.9 build since Cairo landed (approximately April 2006-ish?).

Comment 68

[philippe (part-time)]

(In reply to comment #67)

Fwiw, Cairo Mac landed somewhere in Dec 2006.
Personally I have not seen any problems like the ones here since then.
If you're testing trunk builds, the only problems affecting fonts are related to bold/italic not displaying correctly (bug 364713).

Comment 69

[Chris Lawson (gone)]

I'm going to move this over to 1.8 Branch, then, and if the Powers That Be decide this isn't worth fixing for 1.8, we can call this WORKSFORME since Cairo landed.