Closed Bug 491114 Opened 15 years ago Closed 13 years ago

Textboxes oversized with some versions of Lucida Grande

Categories

(Core :: Graphics, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: benisty.e, Unassigned)

References

Details

Attachments

(1 file)

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
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">
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
> 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
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.
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/).
> 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.
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).
> 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)
(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.
> 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
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.
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.
Do you see the same issue with this?

data:text/html,<input lang="en" size=5 value=abcde>
> 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.
What about:

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

(all on one line).
Summary: Textboxes oversized on some websites → Textboxes oversized on some websites (on Arch Linux)
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.
(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.
(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
(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?
(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?
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).
(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?
(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/.
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.
OS: Linux → All
Hardware: x86 → All
Summary: Textboxes oversized on some websites (on Arch Linux) → Textboxes oversized with some versions of Lucida Grande
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.
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
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?
(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
(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. :)
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.
I think this bug can be closed since it was caused by the bad font file.

Can you confirm jtd?
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: thebes → jdaggett
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: