Last Comment Bug 39553 - Unix version sometimes uses widely spaced fonts
: Unix version sometimes uses widely spaced fonts
Status: VERIFIED INVALID
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Linux
: P3 major (vote)
: M18
Assigned To: Erik van der Poel
: John Morrison
Mentors:
: 47971 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-16 21:45 PDT by R.K.Aa.
Modified: 2005-03-17 13:34 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
no scrollbar on right side (93.11 KB, image/jpeg)
2000-05-16 21:47 PDT, R.K.Aa.
no flags Details
comments and various requested output (19.39 KB, text/plain)
2000-05-17 18:06 PDT, R.K.Aa.
no flags Details
xlsfonts using xfsft (my normal server, the bug is active using that) (171.61 KB, text/plain)
2000-05-17 18:53 PDT, R.K.Aa.
no flags Details
xlsfonts using xfstt (98.61 KB, text/plain)
2000-05-17 18:54 PDT, R.K.Aa.
no flags Details
xfontsel using tahoma as displayfont using xfsft as compiled into RH's XFree86-xfs-3.3.5-1.6.0 (22.21 KB, image/jpeg)
2000-05-17 19:10 PDT, R.K.Aa.
no flags Details
RKA's xlsfonts -u output showing *tahoma*c*jis* first (174.60 KB, text/plain)
2000-05-17 19:54 PDT, Erik van der Poel
no flags Details

Description R.K.Aa. 2000-05-16 21:45:53 PDT
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. 2000-05-16 21:47:42 PDT
Created attachment 8764 [details]
no scrollbar on right side
Comment 2 R.K.Aa. 2000-05-16 21:50:45 PDT
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. 2000-05-17 09:04:12 PDT
strange. The scrollbar is gone if i use xfsft and is there OK if i use xfstt
Comment 4 R.K.Aa. 2000-05-17 12:08:51 PDT
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 2000-05-17 13:10:03 PDT
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. 2000-05-17 13:26:37 PDT
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 2000-05-17 16:16:46 PDT
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. 2000-05-17 18:06:08 PDT
Created attachment 8815 [details]
comments and various requested output
Comment 9 R.K.Aa. 2000-05-17 18:10:40 PDT
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. 2000-05-17 18:53:19 PDT
Created attachment 8820 [details]
xlsfonts using xfsft (my normal server, the bug is active using that)
Comment 11 R.K.Aa. 2000-05-17 18:54:11 PDT
Created attachment 8821 [details]
xlsfonts using xfstt
Comment 12 R.K.Aa. 2000-05-17 19:07:54 PDT
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. 2000-05-17 19:10:19 PDT
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 Erik van der Poel 2000-05-17 19:15:21 PDT
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. 2000-05-17 19:22:54 PDT
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 2000-05-17 19:29:13 PDT
We're getting closer. Now please try:

  -microsoft-tahoma-medium-r-normal--11-*-*-*-p-*-iso8859-1
Comment 17 R.K.Aa. 2000-05-17 19:32:43 PDT
works OK - no oddities.
Comment 18 Erik van der Poel 2000-05-17 19:51:58 PDT
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 2000-05-17 19:54:21 PDT
Created attachment 8825 [details]
RKA's xlsfonts -u output showing *tahoma*c*jis* first
Comment 20 R.K.Aa. 2000-05-18 00:37:04 PDT
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 2000-05-18 09:54:58 PDT
Erik, is this yours?  If not, please reassign to evaughan 
Comment 22 Erik van der Poel 2000-05-18 10:16:15 PDT
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 2000-05-18 12:21:41 PDT
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. 2000-05-18 13:11:33 PDT
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. 2000-05-18 13:31:29 PDT
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 2000-05-18 13:42:56 PDT
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 2000-05-18 15:46:52 PDT
 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. 2000-05-18 17:32:41 PDT
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 2000-05-18 17:43:35 PDT
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. 2000-05-18 18:34:26 PDT
sample URL that now renders wrong: http://www.pcworld.no
Comment 31 R.K.Aa. 2000-05-18 18:37:25 PDT
another site is top hundred http://www.cnn.com
text in top and bottom areas.
Comment 32 Erik van der Poel 2000-05-23 16:09:50 PDT
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 2000-05-23 16:19:03 PDT
adding relnote keyword as a reminder to myself. Verifying invalid per erik.
Comment 34 R.K.Aa. 2000-08-08 06:24:06 PDT
*** Bug 47971 has been marked as a duplicate of this bug. ***
Comment 35 Akkana Peck 2000-11-08 14:45:12 PST
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.  

Note You need to log in before you can comment on or make changes to this bug.