Unix version sometimes uses widely spaced fonts




18 years ago
13 years ago


(Reporter: R.K.Aa., Assigned: Erik van der Poel)



Firefox Tracking Flags

(Not tracked)



(6 attachments)



18 years ago
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

Comment 1

18 years ago
Created attachment 8764 [details]
no scrollbar on right side

Comment 2

18 years ago
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.

Comment 3

18 years ago
strange. The scrollbar is gone if i use xfsft and is there OK if i use xfstt

Comment 4

18 years ago
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:


Comment 5

18 years ago
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.

Comment 6

18 years ago
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.

Comment 7

18 years ago
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.

Comment 8

18 years ago
Created attachment 8815 [details]
comments and various requested output

Comment 9

18 years ago
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?

Comment 10

18 years ago
Created attachment 8820 [details]
xlsfonts using xfsft (my normal server, the bug is active using that)

Comment 11

18 years ago
Created attachment 8821 [details]
xlsfonts using xfstt

Comment 12

18 years ago
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.)

Comment 13

18 years ago
Created attachment 8822 [details]
xfontsel using tahoma as displayfont using xfsft as compiled into RH's XFree86-xfs-3.3.5-1.6.0

Comment 14

18 years ago
RKA, would you please try xfontsel with the following font (which I grabbed from
one of your attachments):


Put 'quotes' around it so that the shell doesn't complain.

Comment 15

18 years ago
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

Comment 16

18 years ago
We're getting closer. Now please try:


Comment 17

18 years ago
works OK - no oddities.

Comment 18

18 years ago
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

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...

Comment 19

18 years ago
Created attachment 8825 [details]
RKA's xlsfonts -u output showing *tahoma*c*jis* first

Comment 20

18 years ago
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)

Comment 21

18 years ago
Erik, is this yours?  If not, please reassign to evaughan 
Assignee: trudelle → erik

Comment 22

18 years ago
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

I've created bug 39738 to track the vertical scrollbar disappearance issue.
Summary: vertical scrollbar missing → Unix version sometimes uses widely spaced fonts
Target Milestone: --- → M18


18 years ago
Severity: normal → major
Component: XP Toolkit/Widgets → Layout

Comment 23

18 years ago
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

Comment 24

18 years ago
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

(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:

-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.

Comment 25

18 years ago
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-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

Comment 26

18 years ago
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?

Comment 27

18 years ago
 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

Comment 28

18 years ago
Since the problem is valid for more fonts than tahoma, listing order should be

p m c

for all of them really.


Comment 29

18 years ago
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.

Comment 30

18 years ago
sample URL that now renders wrong: http://www.pcworld.no

Comment 31

18 years ago
another site is top hundred http://www.cnn.com
text in top and bottom areas.

Comment 32

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 33

18 years ago
adding relnote keyword as a reminder to myself. Verifying invalid per erik.

Comment 34

17 years ago
*** Bug 47971 has been marked as a duplicate of this bug. ***

Comment 35

17 years ago
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.  
You need to log in before you can comment on or make changes to this bug.