39553 - Unix version sometimes uses widely spaced fonts

Status: VERIFIED INVALID

(Core :: Layout, defect, P3)

Description

[R.K.Aa.]

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

[R.K.Aa.]

Attachment: no scrollbar on right side

Comment 2

[R.K.Aa.]

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

[R.K.Aa.]

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

Comment 4

[R.K.Aa.]

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

Comment 5

[Erik van der Poel]

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

[R.K.Aa.]

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

[Erik van der Poel]

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

[R.K.Aa.]

Attachment: comments and various requested output

Comment 9

[R.K.Aa.]

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

[R.K.Aa.]

Attachment: xlsfonts using xfsft (my normal server, the bug is active using that)

Comment 11

[R.K.Aa.]

Attachment: xlsfonts using xfstt

Comment 12

[R.K.Aa.]

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

[R.K.Aa.]

Attachment: xfontsel using tahoma as displayfont using xfsft as compiled into RH's XFree86-xfs-3.3.5-1.6.0

Comment 14

[Erik van der Poel]

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.

Comment 15

[R.K.Aa.]

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?

Comment 16

[Erik van der Poel]

We're getting closer. Now please try:

  -microsoft-tahoma-medium-r-normal--11-*-*-*-p-*-iso8859-1

Comment 17

[R.K.Aa.]

works OK - no oddities.

Comment 18

[Erik van der Poel]

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

Comment 19

[Erik van der Poel]

Attachment: RKA's xlsfonts -u output showing *tahoma*c*jis* first

Comment 20

[R.K.Aa.]

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

[Peter Trudelle]

Erik, is this yours?  If not, please reassign to evaughan 

Comment 22

[Erik van der Poel]

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.

Comment 23

[Erik van der Poel]

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

Comment 24

[R.K.Aa.]

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.

Comment 25

[R.K.Aa.]

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

Comment 26

[Erik van der Poel]

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

[Chris Siebenmann]

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

Comment 28

[R.K.Aa.]

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

p m c

for all of them really.

Comment 29

[Erik van der Poel]

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

[R.K.Aa.]

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

Comment 31

[R.K.Aa.]

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

Comment 32

[Erik van der Poel]

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.

Comment 33

[John Morrison]

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

Comment 34

[R.K.Aa.]

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

Comment 35

[Akkana Peck]

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.