If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

()

Core
Layout
--
major
16 years ago
8 years ago

People

(Reporter: Phil Stracchino, Assigned: Jungshik Shin)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

16 years ago
On Unix systems, there are potentially two different fontpaths, one for the
Xserver itself and possibly another for the X font server.  Mozilla appears to
pay no attention whatsoever to the xfs fontpath, from which I assume that it
does not use xfs.  It does, however, use the Xserver's fontpath, and the order
in which font types are listed in the Xserver's fontpath is critical.  Mozilla
will work correctly if bitmap fonts precede scalable outline fonts (Type1 and
TrueType) in the fontpath.

If, however, outline font directories are listed in the fontpath before bitmap
fonts, then Mozilla renders fonts at enormously incorrect sizes (as much as 2
orders of magnitude larger than specified).  For most applications it is,
naturally, preferable to use scalable fonts before bitmapped fonts.

To give a specific example, I am running AccelX 6.0 at 1600x1200 resolution with
a Mozilla window 923 pixels wide by 1159 high (plus window manager decorations).
 My Xserver,s fontpath is currently set to:

[FONTPATH]
    "/usr/X11R6/lib/fonts/100dpi/",
    "/usr/X11R6/lib/fonts/75dpi/",
    "/usr/X11R6/lib/fonts/misc/",
    "/usr/X11R6/lib/fonts/AcceleratedX/",
    "/usr/X11R6/lib/fonts/URW/",
    "/usr/X11R6/lib/fonts/freefont/",
    "/usr/X11R6/lib/fonts/sharefont/",
    "/usr/X11R6/lib/fonts/TrueType/",
    "/usr/X11R6/lib/fonts/ghostscript/";

Mozilla is rendering correctly.  If I change the fontpath to the following:

[FONTPATH]
    "/usr/X11R6/lib/fonts/URW/",
    "/usr/X11R6/lib/fonts/freefont/",
    "/usr/X11R6/lib/fonts/sharefont/",
    "/usr/X11R6/lib/fonts/TrueType/",
    "/usr/X11R6/lib/fonts/100dpi/",
    "/usr/X11R6/lib/fonts/75dpi/",
    "/usr/X11R6/lib/fonts/misc/",
    "/usr/X11R6/lib/fonts/AcceleratedX/",
    "/usr/X11R6/lib/fonts/ghostscript/";
and start a new Mozilla process, the only things visible in that 923x1159 window
will be the initial "Fi" of "File" and the lefthand edge of the L.
All my other applications -- the Gimp, AbiWord, Netscape 4.77, to name a few --
have no problems rendering any of the Type1 or TrueType fonts, so I know there
is nothing wrong with the fonts.
I have been encountering this problem with Mozilla since at least M15, but it
wasn't until today that I finally figured out what was actually causing the problem.
In your font preferences, what's your DPI set to (Edit > Preferences >
Appearance > Fonts, the "Display Resolution" dropdown).
(Reporter)

Comment 2

16 years ago
Mozilla's resolution preference is set to "use system setting".  The Xserver
setting is 100dpi.  Mozilla resolution calibration results in a setting of 106dpi.
ccing bstell.
Assignee: asa → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen

Comment 4

16 years ago
Unfortunately, I know nothing about fonts on *nix - reassigning to pav hoping
that he does (or knows who does).
Assignee: attinasi → pavlov

Comment 5

16 years ago
-> bstell
Assignee: pavlov → bstell

Comment 6

16 years ago
I see two separate issues here.

First, lets sort out how the font list *should* be handled.

> On Unix systems, there are potentially two different fontpaths, one for the
> Xserver itself and possibly another for the X font server.  Mozilla appears 
> to pay no attention whatsoever to the xfs fontpath, from which I assume that 
> it does not use xfs.  

To my knowledge X applications are not supposed to look at the font path to
find fonts but are supposed to call XListFonts. Linux/Mozilla follows this 
standard X font convention and calls XListFonts and honors the (user
controlled) order of fonts listed when searching for fonts. The user is in 
charge of the font path.

The user is in charge of enabling/disabling xfs. If xfs is enabled then 
fonts supplied by xfs will appear (in order) in the list for fonts returned
from XListFonts.

> order in which font types are listed in the Xserver's fontpath is critical

By design the user controls the font path / list and xfs.

Comment 7

16 years ago
> For most applications it is, naturally, preferable to use scalable fonts 
> before bitmapped fonts.

In general the bitmap fonts on X are hand tuned and hence have better
visual quality than outline scaled fonts. As such Linux/Mozilla makes an
effort to prefer hand tuned fonts over outline scaled fonts.

Comment 8

16 years ago
Since this bug concerns incorrectly sized xfs fonts I'm changing the title
from:

  Mozilla may use grossly incorrect fonts depending on fontpath

to:

  incorrectly sized xfs fonts
Summary: Mozilla may use grossly incorrect fonts depending on fontpath → incorrectly sized xfs fonts

Comment 9

16 years ago
Phil:

  What OS are you running?

  What xfs are you running?

  What X server are you running?
(Reporter)

Comment 10

16 years ago
Brian,
While the hand-tuning advantage for bitmap fonts is true for small point sizes,
these bitmap fonts are generally *only* present in small point sizes, and as a
result even the best hand-tuned bitmap fonts appear blocky and ugly in large
sizes.  They are also typically available only in a small range of sizes (9, 10,
12, 14, 18 is typical) and are typically scaled on the assumption of screen
resolution on the order of 72dpi.  Thus my comment about scalable fonts being
preferred.
As already stated, the X server here is AccelX 6.0.  The xfs in use is the xfs
shipped with AccelX 6.0.  The OS is Linux, based on Slackware 7.0 with various
upgrades, on a 2.4.6 kernel.

Regarding XListFonts, my assumptions about what it was and was not paying any
attention to was based on observations about which changes to the xfs fontpath
and the Xserver fontpath appeared to affect Mozilla's behavior.  I'm not an X
programmer and not familiar with how font lists are actually obtained.  It
doesn't appear to be an xfs problem, since Mozilla is the only application
rendering the fonts at incorrect sizes.

FWIW, it's rendering them beautifully...  :)  it's merely doing so in billboard
sizes.  :)

Comment 11

16 years ago
please the environment variable NS_FONT_DEBUG=5, do a minimal run 
(eg: ./mozilla http://some.website.com/some_content.html), capture the output,
and attach it to this bug
(Reporter)

Comment 12

16 years ago
Created attachment 54194 [details]
Output of /opt/mozilla/mozilla http://www.mozilla.org > mozilla.out 2>&1 with NS_FONT_DEBUG=5

Comment 13

16 years ago
oops, Phil can you redo this with NS_FONT_DEBUG=C 
(Reporter)

Comment 14

16 years ago
Created attachment 54311 [details]
As above, with NS_FONT_DEBUG=C
(Reporter)

Comment 15

16 years ago
Done; see second attachment.  I should verify, though -- do you need me to
reconfigure my fontpath so as to make Mozilla break, before I do this?  Or can
the information you need be gained with the font path set up so that it works? 
I'm guessing you probably need it "broken".

Comment 16

16 years ago
The setup where the large fonts occur.

I'm looking to see what font size layout requested and what font the font 
subsystem choose.

Updated

16 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 17

16 years ago
Created attachment 54324 [details]
NS_FONT_DEBUG=C, Xserver path reordered to put scalable fonts first
(Reporter)

Comment 18

16 years ago
Try this one for size.  This has NS_FONT_DEBUG=C, Xserver fontpath reordered to
put scalable fonts first followed by bitmap fonts, font server fontpath left
untouched.  A 923wx1159h Mozilla window launched with this fontpath contains the
Fi of File and the very edge of the l, and nothing more.  The window will stay
up arbitrarily long until the mouse is moved into the window, but the instant
the window gains focus, Mozilla dies.  (I've now figured out exactly what change
to make to reproduce this condition on demand.)

Comment 19

16 years ago
I wonder why layout is asking for this large font?

> outline font:______ -adobe-helvetica-medium-r-normal--%d-*-0-0-p-*-iso8859-1
>                     desired=1000, scaled=1000, bitmap=0, nsFontMetricsGTK.cpp 
2468
> scaled font:_______ adobe-helvetica-iso8859-1
>                     desired=1000, scaled=1000, bitmap=0, nsFontMetricsGTK.cpp 
2499
(Reporter)

Comment 20

16 years ago
That *is* rather the $64,000 question, isn't it?

Comment 21

16 years ago
Phil: do you build mozilla?

If so, can you add a bit of debug here:
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp

1061   float app2dev;
1062   mDeviceContext->GetAppUnitsToDevUnits(app2dev);
1063   float textZoom = 1.0;
1064   mDeviceContext->GetTextZoom(textZoom);
1065   mPixelSize = NSToIntRound(app2dev * textZoom * mFont->size);

       printf("app2dev = %f\n", app2dev);
       printf("textZoom = %f\n", textZoom);
       printf("mFont->size = %d\n", mFont->size);
       printf("mPixelSize = %d\n", mPixelSize);

(Reporter)

Comment 22

16 years ago
I haven't tried to build it locally since about M15, because the last time I
tried I ran out of free spae on my build partition.  But I'll give it a try and
see if I can juggle enough disk space to get room to build it.

Comment 23

16 years ago
I believe that a setting non-debug and enable-optimize reduces the disk 
requirement.

http://www.mozilla.org/build/distribution.html
you might try adding a mozilla/.mozconfig file containing this:

ac_add_options --disable-debug
ac_add_options --enable-optimize
(Reporter)

Comment 24

16 years ago
I got it to build last night with --disable-tests and --disable-debug, and I
have output from a test run, but it's pretty minimal (below).  Is this going to
be enough to be useful, or will I need to recompile with debug enabled?

MOZILLA_FIVE_HOME=/usr/src/mozilla-0.9.5/dist/bin
 
LD_LIBRARY_PATH=/usr/src/mozilla-0.9.5/dist/bin:/usr/src/mozilla-0.9.5/dist/bin/plugins
    
LIBRARY_PATH=/usr/src/mozilla-0.9.5/dist/bin:/usr/src/mozilla-0.9.5/dist/bin/components
       SHLIB_PATH=/usr/src/mozilla-0.9.5/dist/bin
          LIBPATH=/usr/src/mozilla-0.9.5/dist/bin
       ADDON_PATH=/usr/src/mozilla-0.9.5/dist/bin
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 168
mPixelSize = 12
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 336
mPixelSize = 24
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 14000
mPixelSize = 1000
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 168
mPixelSize = 12
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 168
mPixelSize = 12
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 168
mPixelSize = 12
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 134
mPixelSize = 10
app2dev = 0.071429
textZoom = 1.000000
mFont->size = 14000
mPixelSize = 1000
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
  serial 1138 error_code 11 request_code 53 minor_code 0

Comment 25

16 years ago
This looks normal:

> app2dev = 0.071429
> textZoom = 1.000000
> mFont->size = 134
> mPixelSize = 10

This looks odd:

> app2dev = 0.071429
> textZoom = 1.000000
> mFont->size = 14000
> mPixelSize = 1000

Comment 26

16 years ago
okay, in gfx/src/nsFont.cpp can you add

  printf("size = %d\n", size);

after each "size = ..." line?
(lines 51,64,75, and 108)

Comment 27

16 years ago
PS: you only have to do a gmake in the mozilla/gfs/src dir and then rerun
in the dist/bin dir.
(Reporter)

Comment 28

16 years ago
Done as requested.  Output of NS_FONT_DEBUG=C ./mozilla http://www.mozilla.org/
attached.  See attchment 4.  (I wish bugzilla would let me add a comment and an
attachment in the same operation.)
(Reporter)

Comment 29

16 years ago
Created attachment 54619 [details]
Output of NS_FONT_DEBUG=C ./mozilla http://www.mozilla.org/

Comment 30

16 years ago
I need to duplicate this on my system so I can debug it.

Updated

16 years ago
Target Milestone: --- → mozilla0.9.7

Comment 31

16 years ago
-> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW

Comment 32

16 years ago
move to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 33

16 years ago
I cannot reproduce this. I don't have 
 "/usr/X11R6/lib/fonts/URW/",
    "/usr/X11R6/lib/fonts/freefont/",
    "/usr/X11R6/lib/fonts/sharefont/",

Comment 34

16 years ago
In my system:
[ftang@ftang rc5.d]$ ls /usr/X11R6/lib/X11/fonts
100dpi  CID       encodings  korean  local  PEX     TrueType  util
75dpi   cyrillic  japanese   latin2  misc   Speedo  Type1

and I swith the font path, cannot reproduce the problem. Here is the order of my
font path
[ftang@ftang rc5.d]$ /usr/sbin/chkfontpath
Current directories in font path:
1: /usr/X11R6/lib/X11/fonts/Type1
2: /usr/X11R6/lib/X11/fonts/Speedo
3: /usr/share/fonts/default/TrueType
4: /usr/share/fonts/default/Type1
5: /usr/share/fonts/ja/TrueType
6: /usr/share/fonts/ko/TrueType
7: /usr/share/fonts/zh_CN/TrueType
8: /usr/share/fonts/zh_TW/TrueType
9: /usr/X11R6/lib/X11/fonts/korean
10: /usr/X11R6/lib/X11/fonts/misc:unscaled
11: /usr/X11R6/lib/X11/fonts/75dpi:unscaled
12: /usr/X11R6/lib/X11/fonts/100dpi:unscaled
13: /usr/X11R6/lib/X11/fonts/misc
14: /usr/X11R6/lib/X11/fonts/cyrillic
15: /usr/X11R6/lib/X11/fonts/CID
16: /usr/X11R6/lib/X11/fonts/local
17: /usr/X11R6/lib/X11/fonts/latin2/Type1
18: /usr/X11R6/lib/X11/fonts/japanese
19: /usr/share/AbiSuite/fonts
20: /usr/share/fonts/KOI8-R/misc:unscaled
21: /usr/share/fonts/KOI8-R/75dpi:unscaled
22: /usr/share/fonts/KOI8-R/misc
23: /usr/share/fonts/KOI8-R/75dpi

what is your chkfontpath ?

Comment 35

16 years ago
I suspect this not not directly related to the order of font path, but some code
trash some memory in that condiction.

Comment 36

16 years ago
I will suggest you run purify on the system which can reproduce this problem. 
It seems the caller of nsFont pass down 14000 to it. there are no reason that
layout engine cannot make such request. But it is unlikely. I suspect some code
trash the memory before call to nsFont. 
Target Milestone: mozilla0.9.8 → ---

Comment 37

16 years ago
to prevent this kind of hang happen, we should guard the code to only require
size up to a cerntain size . 

shanjian can we add some code like

NS_ASSERTION(mPixelSize <= 100 , "pixel size too big");
mPixelSize = MAX(mPixelSize, 100);
before we convert mPixelSize to font size. 
  

 

Assignee: ftang → shanjian
Status: ASSIGNED → NEW

Comment 38

16 years ago
could we make the size controllable via pref?

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 39

13 years ago
shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first. 
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 40

13 years ago
Mass Reassign Please excuse the spam
Assignee: shanjian → nobody

Comment 41

13 years ago
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 42

13 years ago
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW

Comment 43

10 years ago
xfs is now deprecated. xfs isn't by default installed in current distros. Is there any reason to consider fixing this?
QA Contact: chrispetersen → layout
You need to log in before you can comment on or make changes to this bug.