Last Comment Bug 491114 - Textboxes oversized with some versions of Lucida Grande
: Textboxes oversized with some versions of Lucida Grande
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: John Daggett (:jtd)
Mentors:
: 493351 500550 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-01 23:56 PDT by benisty.e
Modified: 2011-11-27 10:17 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Browser comparison for input with no specified width in CSS or attribute: Firefox 3.0.10 (Windows), Firefox 3.5.2 (Windows), Safari 4.0.2 (Windows) (268.65 KB, image/jpeg)
2009-08-04 14:40 PDT, Andrew Udvare
no flags Details

Description benisty.e 2009-05-01 23:56:27 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b5pre) Gecko/20090426 Firefox/3.1a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b5pre) Gecko/20090426 Firefox/3.5b5pre

Textboxes are oversized on most websites.
Please see as examples:
http://omploader.org/vMW0xNw
http://omploader.org/vMW0xNQ
http://omploader.org/vMW0xOA

Reproducible: Always
Comment 1 Sylvain Pasche 2009-05-03 17:40:54 PDT
Does it also happen with a clean profile?
(http://kb.mozillazine.org/Profile_Manager#Creating_a_new_profile)

Can you reproduce the issue when opening these URLs?

data:text/html,<input size=5 value=abcde>

data:text/html,<input size=5 value=abcde style="font-family: monospace">
Comment 2 benisty.e 2009-05-04 07:05:59 PDT
> Does it also happen with a clean profile?
Yes. The issue is still here.

> Can you reproduce the issue when opening these URLs?
Please see results (screenshots) below.

data:text/html,<input size=5 value=abcde>
http://omploader.org/vMW1lbw

data:text/html,<input size=5 value=abcde style="font-family: monospace">
http://omploader.org/vMW1lcA
Comment 3 Hermann Schwab 2009-05-04 07:54:25 PDT
http://dieter.plaetinck.be/uzbl_a_browser_that_adheres_to_the_unix_philosophy
is showing your first example http://omploader.org/vMW0xNw

Worksforme. What I see in your example is an overly long subject textbox, mine displays 54 chars without scrolling.
Comment 4 Sylvain Pasche 2009-05-04 09:31:49 PDT
Maybe your "sans" font has some strange metrics. Could you please provide the output of:

fc-match -v sans|grep file:

This should show the font's filename. Then you could try running ftdump FILENAME to get some basic info.

Oh, and please try with a recent nightly (from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/).
Comment 5 benisty.e 2009-05-04 10:50:57 PDT
> Could you please provide the output of:
eb@blackout:~>fc-match -v sans|grep file:
	file: "/usr/share/fonts/TTF/Vera.ttf"(s)

> Then you could try running ftdump FILENAME to get some basic info.
I'm really sorry but I couldn't find ftdump. Is it part of some ensemble of utilities?

> Oh, and please try with a recent nightly
exactly same problem.
Comment 6 Sylvain Pasche 2009-05-04 11:41:58 PDT
ftview is part of Freetype. Here's what I see on Very.ttf on my Ubuntu 9.04 box:
ftdump /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
There is 1 face in this file.

----- Face number: 0 -----

font name entries
   family:     Bitstream Vera Sans
   style:      Roman
   postscript: BitstreamVeraSans-Roman

font type entries
   FreeType driver: truetype
   sfnt wrapped:    yes
   type:            scalable
   direction:       horizontal
   fixed width:     no
   glyph names:     yes
   EM size:         2048
   global BBox:     (-375,-483):(2636,1901)
   ascent:          1901
   descent:         -483
   text height:     2384
   glyph count: 268

charmaps
   0: platform 1, encoding 0
   1: platform 3, encoding 1 (active)


I think it could be useful if you provided versions for the packages:
ttf-bitstream-vera (the package containing the Very.ttf font)
fontconfig
freetype
libpango (not sure if it is still used on trunk for font selection).
Comment 7 benisty.e 2009-05-04 12:07:03 PDT
> ftview is part of Freetype
There's no Freetype in the distribution I use (Arch Linux), only Freetype2 and ftdump is missing.

> I think it could be useful if you provided versions for the packages:
> ttf-bitstream-vera (the package containing the Very.ttf font)
> fontconfig
> freetype
> libpango (not sure if it is still used on trunk for font selection).
eb@blackout:~>pacman -Q freetype2
freetype2 2.3.9-2
eb@blackout:~>pacman -Q ttf-bitstream-vera
ttf-bitstream-vera 1.10-6
eb@blackout:~>pacman -Q fontconfig
fontconfig 2.6.0-2
eb@blackout:~>pacman -Q pango
pango 1.24.1-1
(NB: libs are not provided as separated packages in Arch i.e. pango version is libpango version)
Comment 8 Sylvain Pasche 2009-05-04 12:37:10 PDT
(In reply to comment #7)
> > ftview is part of Freetype
> There's no Freetype in the distribution I use (Arch Linux), only Freetype2 and
> ftdump is missing.

Sorry, I meant freetype2. Never mind if you don't have the tool, it may not provide all the needed information.

> > I think it could be useful if you provided versions for the packages:
> > ttf-bitstream-vera (the package containing the Very.ttf font)
> > fontconfig
> > freetype
> > libpango (not sure if it is still used on trunk for font selection).
> eb@blackout:~>pacman -Q freetype2
> freetype2 2.3.9-2
> eb@blackout:~>pacman -Q ttf-bitstream-vera
> ttf-bitstream-vera 1.10-6
> eb@blackout:~>pacman -Q fontconfig
> fontconfig 2.6.0-2
> eb@blackout:~>pacman -Q pango
> pango 1.24.1-1
> (NB: libs are not provided as separated packages in Arch i.e. pango version is
> libpango version)

Ok, I have the same versions on Ubuntu where this is working fine. The only difference is that DejaVuSans.ttf is used for sans instead (from the ttf-dejavu-core package).

The only thing I can think of now is that Vera.ttf could be different. What's the md5sum/size of that file on your system? (by typing |md5sum /usr/share/fonts/TTF/Vera.ttf|). I have 785d2fd45984c6548763ae6702d83e20 (65932 bytes) here.
Comment 9 benisty.e 2009-05-04 15:32:30 PDT
> The only thing I can think of now is that Vera.ttf could be different. What's
the md5sum/size of that file on your system?
785d2fd45984c6548763ae6702d83e20  /usr/share/fonts/TTF/Vera.ttf
Comment 10 Sylvain Pasche 2009-05-04 16:16:12 PDT
So it's the same font, that's weird. I'm not sure what's going on here.

Did it work with Firefox 3.0? If it worked on a previous version, it could be interesting to find the regression window. The process is explained on http://quality.mozilla.org/documents-home/bugs-docs/bug-triaging-guidelines/finding-regression-windows.
Comment 11 benisty.e 2009-05-05 07:49:13 PDT
Bug hunt may be difficult with the info I'm coming with but I'll submit it anyway. I'll try to narrow down the search in the meantime.

2008-09-25-02-mozilla-central
displays textboxes as expected

2008-11-11-02-mozilla-central
has the issue.

All binaries in-between will crash at startup (even in safe mode) with:
(crashreporter:15856): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed

I'm going to give hg a try but I'm afraid "old" code may fail to build with nowadays systems.
Comment 12 Karl Tomlinson (:karlt) 2009-05-17 22:07:14 PDT
Do you see the same issue with this?

data:text/html,<input lang="en" size=5 value=abcde>
Comment 13 benisty.e 2009-05-18 10:26:08 PDT
> Do you see the same issue with this?

> data:text/html,<input lang="en" size=5 value=abcde>
Yes.
http://omploader.org/vMXA0aA

I don't know how to narrow down the search. As stated before, mozilla nightly binaries crash at start on a period of 1.5 month (even if I could identify working/non-working builds during this period - see comment #11) and the toolchain/libs I'm currently using will result in hg builds to fail.
Comment 14 Karl Tomlinson (:karlt) 2009-05-18 15:56:32 PDT
What about:

data:text/html,<input size=5 style="font-family: Bitstream Vera Sans" value=abcde>

(all on one line).
Comment 15 Sylvain Pasche 2009-05-18 18:46:24 PDT
*** Bug 493351 has been marked as a duplicate of this bug. ***
Comment 16 Jeff Cook 2009-05-18 21:54:54 PDT
This was recently posted to the Arch Linux general list, and just wanted to drop in and note that I can't recall ever experiencing this problem using Firefox 3.5 nightlies and a fully updated install of Arch (with testing repo), so it's not always reproducible across all Arch machines.
Comment 17 David Rosenstrauch 2009-05-19 07:42:39 PDT
(In reply to comment #16)
> This was recently posted to the Arch Linux general list, and just wanted to
> drop in and note that I can't recall ever experiencing this problem using
> Firefox 3.5 nightlies and a fully updated install of Arch (with testing repo),
> so it's not always reproducible across all Arch machines.

Seconded - I don't see this on my Arch box either.
Comment 18 benisty.e 2009-05-20 07:24:15 PDT
(In reply to comment #14)
> What about:
> 
> data:text/html,<input size=5 style="font-family: Bitstream Vera Sans"
> value=abcde>
> 
> (all on one line).

same result, please see http://omploader.org/vMXBmYw
Comment 19 Karl Tomlinson (:karlt) 2009-05-20 20:26:03 PDT
(In reply to comment #18)
> (In reply to comment #14)
> > data:text/html,<input size=5 style="font-family: Bitstream Vera Sans"
> > value=abcde>

> same result, please see http://omploader.org/vMXBmYw

That's quite different to previous snapshots and similar to what I see.
That is what is expected, as some extra padding is provided for non-fixed-width fonts.

It seems that the UI default font is not "Sans" but something different.
Can you find out your Gnome or GTK default font (gtk-font-name), please?
Comment 20 benisty.e 2009-05-20 21:59:23 PDT
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #14)
> It seems that the UI default font is not "Sans" but something different.
> Can you find out your Gnome or GTK default font (gtk-font-name), please?

Very good move Karl, thanks. Changing the gtk font solved the issue. Should this be closed or still considered as a bug?
Comment 21 benisty.e 2009-05-21 00:40:16 PDT
FTR, it doesn't only solve this textboxes problem but also some stange text rendering problems I had on some pages (I could provide screenies if needed but I'm not sure it's necessary now that the cause has been identified).
Comment 22 Karl Tomlinson (:karlt) 2009-05-21 02:55:10 PDT
(In reply to comment #20)
> Changing the gtk font solved the issue. Should
> this be closed or still considered as a bug?

I'd like to know what the problem font was, so that I can understand the cause.
Are you able to find out the family name, please?
Comment 23 benisty.e 2009-05-21 03:06:49 PDT
(In reply to comment #22)
> (In reply to comment #20)
> > Changing the gtk font solved the issue. Should
> > this be closed or still considered as a bug?
> 
> I'd like to know what the problem font was, so that I can understand the cause.
> Are you able to find out the family name, please?

Sure. Sorry I didn't mention it in my previous post. Font was /Lucida Grande/.
Comment 24 Kevin Brosnan 2009-08-04 11:49:45 PDT
*** Bug 500550 has been marked as a duplicate of this bug. ***
Comment 25 Micah Gersten 2009-08-04 12:28:32 PDT
Ubuntu bug:
https://bugs.launchpad.net/bugs/383020
Comment 26 Sylvain Pasche 2009-08-04 14:14:24 PDT
I tested with some versions of Lucida Grande on Linux and Windows.
With the one downloaded from http://isuman.blogspot.com/2008/09/lucida-grande-fonts-for-windows.html: width of the <input> looks fine.
With the one from http://ubuntu-debs.googlecode.com/files/macfonts.tar.gz: width is too large, like what other people are reporting.

I've put a demo there: http://www.spasche.net/files/lucida/

So that looks more like a font issue.
Comment 27 Andrew Udvare 2009-08-04 14:40:06 PDT
Created attachment 392574 [details]
Browser comparison for input with no specified width in CSS or attribute: Firefox 3.0.10 (Windows), Firefox 3.5.2 (Windows), Safari 4.0.2 (Windows)

Because this is a duplicate bug of #500550, from the other bug:

From the HTML source:
<input type="text" name="Email"  id="Email" size="18" value="" class='gaia le
val' />
<input type="password" name="Passwd" id="Passwd" size="18" class="gaia le val"
/>

Notice there is no width="", nor do the classes specify width. Also from the
source (CSS):
.gaia.le.val { font-family: Arial, Helvetica, sans-serif; font-size: smaller; }

I do see this problem on numerous sites, not just iGoogle's log in. The other
sites do not have CSS for their <input>s nor do they specify width. For those,
the input boxes often go off screen.

I do not know if this a bug with Firefox or Cairo. But on Linux I have not
changed my Cairo version and 3.0.10 renders "correctly". Should not make
Firefox the odd one out by rendering <input>s this way.
Comment 28 Karl Tomlinson (:karlt) 2009-08-04 20:53:09 PDT
The problem seems to be that, in the font from http://ubuntu-debs.googlecode.com/files/macfonts.tar.gz , xAvgCharWidth is set to the maximum advance instead of a mean character width:

name           table value

unitsPerEm      head 2048
xAvgCharWidth   os2  3336
advanceWidthMax hhea 3336
Comment 29 Andrew Udvare 2009-08-04 21:22:37 PDT
Lucida Grande md5: c1c8bda7336c62e03c3e485f717781e2

My issue with this bug is that if I can downgrade to FF 3.0 and everything works fine, then something is broken in 3.5 for sure. It may be only opinion that it is broken but it seems I am not the only one with this preference of Lucida Grande for a font (designers of sites as well).

If the issue is with xAvgCharWidth then why does it work with FF 3.0.x?
Comment 30 Karl Tomlinson (:karlt) 2009-08-04 22:15:26 PDT
(In reply to comment #29)
> If the issue is with xAvgCharWidth then why does it work with FF 3.0.x?

The method used in 3.0.x to calculate average widths didn't use this value from the font but was too slow.
FF 3.5 on Linux is closer to what the Windows code does:
http://hg.mozilla.org/mozilla-central/file/73e08f744e9a/gfx/thebes/src/gfxWindowsFonts.cpp#l1052
Comment 31 Andrew Udvare 2009-08-05 01:21:14 PDT
(In reply to comment #30)
> (In reply to comment #29)
> > If the issue is with xAvgCharWidth then why does it work with FF 3.0.x?
> 
> The method used in 3.0.x to calculate average widths didn't use this value from
> the font but was too slow.
> FF 3.5 on Linux is closer to what the Windows code does:
> http://hg.mozilla.org/mozilla-central/file/73e08f744e9a/gfx/thebes/src/gfxWindowsFonts.cpp#l1052

Okay, I figured out the problem I think then. It is fonts. For a while, because of OS X themes, there has been an "emulated" Lucida Grande font floating around the web for a while. It is the "bad" one with md5sum c1c8bda7336c62e03c3e485f717781e2.

I changed my font in Windows to the one at http://isuman.blogspot.com/2008/09/lucida-grande-fonts-for-windows.html and everything works great.

If I could, I would put this as fixed. Everyone needs to get the official Apple Lucida Grande font for Windows, which comes with Safari, or the above link also has it too. :)
Comment 32 Yuriy Voziy 2009-08-20 15:37:50 PDT
Confirmed this bug with 3.5.2
http://dl.getdropbox.com/u/106810/Google_1250807672553.png
Comment 33 Andrew Udvare 2009-08-20 22:19:17 PDT
If the font file has incorrect data for xAvgCharWidth then this error will occur. The question then is, can there be a workaround for those who still wish to use their current fonts? An option in about:config or program the function to notice the unusual xAvgCharWidth value and use the old method (3.0.x) to render pages with these fonts.
Comment 34 Benoit Girard (:BenWa) 2011-11-25 11:08:58 PST
I think this bug can be closed since it was caused by the bad font file.

Can you confirm jtd?

Note You need to log in before you can comment on or make changes to this bug.