93.11 KB, image/jpeg
19.39 KB, text/plain
171.61 KB, text/plain
98.61 KB, text/plain
22.21 KB, image/jpeg
174.60 KB, text/plain
Build ID M16-2000-051608 Linux Will attach screenshot of how app looks after initial fresh startup. -The vertical scrollbar in the main window is missing. -Navigating with keys or scrollwheel works - for a little while. -When navigating bottom scrollbar with mousedrag an error msg in console states: no handler found for spring Looks and acts the same with two diff. wm's: sawmill0.27 and E0.16.3 Running on gnome-core-1.1.90, gtk gtk+-1.2.7
also: Bottom scrollbar isn't all visible - it slide things but gives no feedback on where you are on page as the scrollbar-button fills all the visible scrollbar area all the time instead of resizing correct - i think i saw another bug on that though.
strange. The scrollbar is gone if i use xfsft and is there OK if i use xfstt
erik - i mailed you from another account but i get replies to this one. Also: My attachments in bug 39415 is NOT what the reporter was seeing, so it's a separate bugs. Shall we just include it here? It's part of the same problem. My attachments wrongly placed in 39415 are: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8743 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8747
It seems very strange that the scrollbar would be related to fonts, but since it depends on the font server (xfsft vs xfstt), I guess we should keep these 2 issues (scrollbar disappearance and spaced out text) in the same bug report for now at least. Later, if these 2 turn out to be different problems, we can decide what to do at that point.
removing the mentioning of tahoma in chrome/locales/en-US/global/locale/intl.css cures it all! The scrollbar comes back and all looks normal. If tahoma is mentioned there - the error returns. The arial font renders wrong everywhere IF tahoma is mentioned in that file, but not if i remove it. How about that.
RKA, when the next working build is available, would you please try it with and without tahoma in intl.css, with setenv NS_FONT_DEBUG 3 before you start the program. Please do whatever tests you did when you said that arial renders wrong everywhere, and send me the output. Thanks.
hmm additional discovery... (see comments first) The scrollbar actually *always* vanish when you make the browser so narrow that QA menuitem no longer displays. It seems to be attached to some grid/box defined by the menubar?
Created attachment 8820 [details] xlsfonts using xfsft (my normal server, the bug is active using that)
regarding xfontsel: I have too many fonts to select via menus in it, but will add screenshot from when xfontsel was started like this: xfontsel -fn -microsoft-tahoma-medium-r-normal--0-0-0-0-p-0-iso8859-1 It looks OK. (And yes - this is while running xfsft.)
Created attachment 8822 [details] xfontsel using tahoma as displayfont using xfsft as compiled into RH's XFree86-xfs-3.3.5-1.6.0
RKA, would you please try xfontsel with the following font (which I grabbed from one of your attachments): '-microsoft-tahoma-medium-r-normal--11-*-*-*-c-*-jisx0201.1976-0' Put 'quotes' around it so that the shell doesn't complain.
wowsa..that DID trigger it. Long like the earlyer attachments showing the bug. Wide wide spaced. Did that bring you closer to a solution, or is this xfsft's fault?
We're getting closer. Now please try: -microsoft-tahoma-medium-r-normal--11-*-*-*-p-*-iso8859-1
works OK - no oddities.
OK, this is just a wild guess, but I suspect that the -c- in the former pattern is causing xfsft to try to turn this proportional font into a "cell" font, and somehow ending up with very wide cells for each glyph. I will ask the xfsft author to take a look at this. Mozilla is selecting that font because it comes first in the XListFonts() output. You can verify the order using "xlsfonts -u". I had a look at the output you sent me earlier, and it looks like "xlsfonts -u" returns the fonts in the order of the font path, but for each directory in the font path, it has the fonts in ASCII order. So the *tahoma*c*jis* font comes before the *tahoma*p*iso* font (because c is before p). We had a long discussion in mozilla.unix about XListFonts order, and several people urged me to honor it. I guess I still believe that this order is important. However, we now have the c vs p problem. If the style sheet asks for tahoma, how am I supposed to know that I ought to be asking for a p font instead of a c font? Tahoma is definitely a proportional font, but how is Mozilla supposed to know that? XListFonts says that both c and p are available, so Mozilla has to choose. Hmmm...
hmm reading up on this - O'Reilly's "X WIndow System User's Guide" The way X deal with fonts is extremely "filterable" for a reason: different type of applications, consoles etc need different type of fonts. Charcell fonts are made for monitor displays or emulators. I can't find a single reason why not to filter away ALL charcell fonts in a GUI-based web-browser - regardless of OS. Does the windows version offer all available OEM VGA fonts for display in the browser? Does it offer the ".fot" fonts? The character cell fonts are the similiar case on unix. If xmlterm need charcell fonts then don't filter them there. But the brutal approach elsewhere; keeping them out of the rest of Moz, seems to me like a Very Good Idea. (And is also the approach xfstt takes, as you saw)
Erik, is this yours? If not, please reassign to evaughan
OK, I'll take ownership of this bug, but I'm going to morph it into a pure font bug. I'm changing the Summary to "Unix version sometimes uses widely spaced fonts". I've created bug 39738 to track the vertical scrollbar disappearance issue.
RKA, we can't filter out the monospace fonts because they are required for CSS compliance. If a style sheet asks for "Courier New", we need to honor it. Similarly, if a Unix user's style sheet asks for "fixed" (or any other cell font), we need to honor it. The tahoma case is rather special, since the font server is making it available in more than one form. If the style sheet simply says "Tahoma", we don't know whether they want the proportional or charcell version. Still thinking about this...
Variable width fonts spacing are tagged with a p. Character Cell fonts spacing are tagged with a c And monospace fonts spacing are tagged with an m The Character Cell fonts are one very special case of monospace fonts, only designed to be used as monitor-fonts (or in terminal emulators) Refreshing the syntax: -foundry-fontfamily-weight-slant-set width- additional style-pixels-points-horizontal dpi-vertical dpi-spacing-average width-character set (should be on one line) So character cell fonts *should not* be used in normal GUI applications. Character cell fonts are the fonts given aliases like 5x7, 6x13 etc. A character cell font is always a type of monospace font, but a monospace font is not always a character cell font - most often not, actually. Courier New and all the other normal monospace fonts look like this, for instance: -adobe-courier-medium-r-normal--8-80-75-75-m-50-iso8859-1 -monotype-courier new-bold-i-normal--0-0-0-0-m-0-iso8859-1 My previous comparision, between OEM VGA fonts and charcell fonts is the valid one. We wouldn't want to push VGA fonts on MSWindows users, so the equivalent under Unix should also be ignored. The fact that a particular type of font exists on a system, does not mean it should be recognized everywhere. The only problem i could possibly think of was if japanese, arabic and other more pictorial fonts should happen to make extensive use of charcell fonts, but i read up on this and it seems m (monotype) or p (proportionally) spaced fonts are the normal fonts used also there. So this likely much easyer than you think. I believe Character cell fonts can safely be ignored in Mozilla.
One more thing: The tahoma font is NOT special in that it also comes as a charcell font. Here a sample output from a: xlsfonts |grep '\-c\-' |grep microsoft -microsoft-comic sans ms-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-comic sans ms-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-georgia-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-georgia-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-georgia-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-georgia-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-tahoma-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-tahoma-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-trebuchet ms-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-trebuchet ms-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-trebuchet ms-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-trebuchet ms-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-verdana-bold-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-verdana-bold-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-verdana-medium-i-normal--0-0-0-0-c-0-jisx0201.1976-0 -microsoft-verdana-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0
Thanks for looking into it, but I really don't think we should filter out all c fonts. The user may wish to use "fixed", especially now that an ISO 10646 version is available. Also, all of the standard East Asian fonts are c fonts. I have an idea. The style sheet says: font: 3mm tahoma,arial,helvetica,sans-serif; Since it says "sans-serif" at the end of the list, we know that the author would be satisfied with a non-monospace font. So perhaps I could structure the code such that when tahoma is requested, it first looks at the proportional versions and if that fails, it looks at the m or c versions (if any). Comments?
I think that it might be desirable for Mozilla to prefer certain font encodings over others, if they appear to be otherwise equivalent. (Note that this is the Netscape 4.xx behavior; I believe it only ever looks for ISO-8859-1 fonts in normal usage.) The current behavior seems to be that Mozilla will pick whatever encoding is first in the list and suits its needs. I'd suggest that Mozilla prefer ISO 10496 fonts, then ISO-8859-1 fonts, and only then look at other encodings (eg 'jisx0201.1976-0'). This may be especially important in the case of non-European fonts, where the normal ISO-8859 characters may well have been tweaked to better fit the other characters that are the main purpose of the font (as seems to be the case here).
Since the problem is valid for more fonts than tahoma, listing order should be p m c for all of them really.
My proposal was not intended to be limited to tahoma, though my wording could easily have led others to believe so. What I meant was that the code would look for the first CSS generic (e.g. sans-serif). If there is no generic font in the list, use the default generic font (from "font.default" pref). Then if that generic is monospace, we look at m and c first, p last. All other generics cause us to look at p first, then m and c. In addition to this p/m/c processing, it might also be a good idea to process the charsets in a better order. For example, we could look for fonts that are used for the language of the document first, and if that fails, use the user's language. Failing that, we could look at the rest of the charsets in the XListFonts order.
sample URL that now renders wrong: http://www.pcworld.no
another site is top hundred http://www.cnn.com text in top and bottom areas.
OK, it turns out that the c version of tahoma was only generated because the user asked ttmkfdir to allow a lot of glyphs to be missing, so that JIS X 0201 became a candidate even though Tahoma does not contain many of the JIS X 0201 glyphs. Users should avoid using that (mis)feature of ttmkfdir, and also the font path should be set up so that the desired fonts occur early in the font path, by setting the font path or by editing fonts.dir, etc. Marking INVALID.
adding relnote keyword as a reminder to myself. Verifying invalid per erik.
*** Bug 47971 has been marked as a duplicate of this bug. ***
I just upgraded to RH 7.0 myself. Curiously, rxvt is showing the double spaced letter problem (I specify font -*-*-bold-r-*-sans-14-*-*-*-*-80-*-*, which works on every other system I use) but Mozilla displays just fine with the fonts I use.