5.68 KB, text/plain
7.32 KB, text/plain
4.59 KB, text/plain
10.17 KB, text/plain
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).
Mozilla's resolution preference is set to "use system setting". The Xserver setting is 100dpi. Mozilla resolution calibration results in a setting of 106dpi.
Unfortunately, I know nothing about fonts on *nix - reassigning to pav hoping that he does (or knows who does).
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.
> 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.
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
Phil: What OS are you running? What xfs are you running? What X server are you running?
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. :)
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
Created attachment 54194 [details] Output of /opt/mozilla/mozilla http://www.mozilla.org > mozilla.out 2>&1 with NS_FONT_DEBUG=5
oops, Phil can you redo this with NS_FONT_DEBUG=C
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".
The setup where the large fonts occur. I'm looking to see what font size layout requested and what font the font subsystem choose.
Created attachment 54324 [details] NS_FONT_DEBUG=C, Xserver path reordered to put scalable fonts first
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.)
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
That *is* rather the $64,000 question, isn't it?
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);
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.
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
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
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
okay, in gfx/src/nsFont.cpp can you add printf("size = %d\n", size); after each "size = ..." line? (lines 51,64,75, and 108)
PS: you only have to do a gmake in the mozilla/gfs/src dir and then rerun in the dist/bin dir.
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.)
I need to duplicate this on my system so I can debug it.
move to 0.9.8
I cannot reproduce this. I don't have "/usr/X11R6/lib/fonts/URW/", "/usr/X11R6/lib/fonts/freefont/", "/usr/X11R6/lib/fonts/sharefont/",
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 ?
I suspect this not not directly related to the order of font path, but some code trash some memory in that condiction.
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.
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.
could we make the size controllable via pref?
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.
Mass Reassign Please excuse the spam
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
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
xfs is now deprecated. xfs isn't by default installed in current distros. Is there any reason to consider fixing this?