94327 - When there are multiple fonts with different foundry names but the same family name moz should pick the best fit based on width, weight and available size

Status: RESOLVED FIXED

(Core :: Internationalization, enhancement, P2)

Description

[Barrett Lindstrom]

Re-creating bug to get rid of security issues.  Will post info from original 
bug, with confidential material edited out, as an attachment.

Comment 1

[Barrett Lindstrom]

Attachment: Text from previous bug with all the "naughty" bits removed :-)

Comment 2

[Frank Tang]

Barrett Lindstrom : Is this bug important to the product you want to ship?
Mark it as P2.

Comment 3

[Barrett Lindstrom]

Yes, this is one that our hpux customers are concerned about.

Comment 4

[kill this account]

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

Comment 5

[kill this account]

At present we create a foundry-family node table that separates the fonts
into foundry/family/registry/encoding (FFRE) groups.

When CSS specs a font generally just the family name is specified. 

However, the current font code only looks in the first FFRE for a given font
even if a better size or style is available from a different foundry.

To fix this problem I think we need to create a separate 
*/family/registry/encoding (FRE) node table.

This table would sort all the fonts of a given family/registry/encoding but
any foundry into nodes.

This FRE table would make all the fonts with a given family available rather 
than just the fonts in the first FFRE with that family name. 

The would also mean non-scaled fonts from a different foundry would be 
available as well. This would be far preferrable to bitmap scaling which is
done on occasion even when non-scaled fonts from a different FFRE are
available.

Comment 6

[kill this account]

Attachment: patch; add a set of "any foundry" nodes

Comment 7

[kill this account]

This code adds an AFRE (Any_foundry-Family-Registry-Encoding) node list. This
node list merges all the fonts with the same family-registry-encoding but any
foundry name into one group. The font list order is honored: the first font of 
a given weight/width/slant/size is used. Any subsequent font of the same 
weight/width/slant/size is ignored in the AFRE (but of course it is remembered 
in the FFRE list).

When looking for a font and the foundry is not specified the code looks in the 
AFRE node list. Typically only fonts specified by user preferences have a
foundry name.

Katakai: would you kindly review this?

thanks

Comment 8

[kill this account]

I believe this should fix the most common cases where we bitmap scale
instead of using a font from a different foundry, bug 87664

Comment 9

[Hixie (not reading bugmail)]

rbs: fyi, this is a font bug with a patch which may or may not affect your code

Comment 10

[kill this account]

> rbs: fyi, this is a font bug with a patch which may or may not affect 
> your code

I assume this refers to bug 99010. I strongly doubt that this will have any 
functional effect on that code since this exists in a layer below those 
changes.

Bit rot, of course, is a different problem.

Comment 11

[Roland Mainz]

bstell:
Wanna try to fix bug 93771 ("Mozilla uses low-resolution bitmap fonts on high
resolution X11 displays") here ?

Comment 12

[kill this account]

Roland: This implements an important bit that is needed for bug 93771
but that bug needs other items as well. Some of those additional items
still need to be thought out.  I would prefer to get this part in and 
solve this customer's issue while we try to figure out the full solution
for bug 93771.

Comment 13

[Roland Mainz]

Should I file the port to Xlib now or after your patch has been r='ed ?

Comment 14

[kill this account]

Roland: If it is not too hard go ahead and attach an xlib version. 
It will have to be redone if Katakai suggests changes but if not we can move
directly to asking for sr=.

Comment 15

[Roland Mainz]

Xlib version follows once my new build from tip finishes (~14hours)...

Comment 16

[Roland Mainz]

Attachment: Xlib version of the patch for 2001-09-19-08-trunk

Comment 17

[Roland Mainz]

Comment on attachment 50063 [details] [diff] [review]
Xlib version of the patch for 2001-09-19-08-trunk

One minor detail:
-- snip --
+#ifdef FIX_ME // where is this defined !?
+    size->mMap = nsnull;
+#endif /* FIX_ME */
-- snip --
Is |mMap| an artifact left over from bug 95518 ?

Comment 18

[Roland Mainz]

Attachment: Xlib port of GTK+ patch (without the |#ifdef FIX_ME|) for 2001-09-19-08-trunk

Comment 19

[kill this account]

> +    size->mMap = nsnull;

bitrot

Comment 20

[Roland Mainz]

Any idea when this patch will "land" ?

Comment 21

[Masaki Katakai]

I need more one day for verifying the patch, sorry.

Comment 22

[Masaki Katakai]

r=katakai

Sorry for late. I've reviewed the codes and have tested the
following steps in japanese locale. The patch could get proper
sizes of fonts.

1. prepare 2 font patch A, B

   A contains outline fonts, family name = gothic but foundary = dummy
   B contains bitmap fonts, 12, 14, 16, 18, 20, 24 points size
             family name = gothic but foundary = sun

2. set +fp B, then set +fp A
   A becomes a top directory of fontpath

3. start Mozilla and browse the example page that contains
   "face=gothic"

Without Brian's patch, characters are displayed in outline fonts
because TryFamily() returns the first matched font.

With Brian's patch, characters are displayed by using bitmap fonts
in fontpath B when the size is available. Good.

Comment 23

[Roland Mainz]

Requesting sr= ...

Comment 24

[kinmoz]

The changes look ok to me with one exception:

FFREName will be a dangling pointer since the temporary PromiseFlatCString goes 
out of scope almost immediately:


@@ -3472,7 +3548,9 @@
 nsFontXlib*
 nsFontMetricsXlib::TryNodes(nsAWritableCString &aFFREName, PRUnichar aChar)
 {
-  nsCStringKey key(PromiseFlatCString(aFFREName).get());
+  const char *FFREName = PromiseFlatCString(aFFREName).get();
+  nsCStringKey key(FFREName);
+  PRBool anyFoundry = (FFREName[0] == '*');


Fix that and you can have sr=[e-mail]. If there are any objections from 
any of the X Font gurus listed on the AssignedTo/Cc list speak up now. :-) I 
also assume you tested enough to make sure there were no bad affects to onscreen 
rendering.

Comment 25

[kill this account]

How about this:

@@ -3472,7 +3548,9 @@
 nsFontXlib*
 nsFontMetricsXlib::TryNodes(nsAWritableCString &aFFREName, PRUnichar aChar)
 {
   nsCStringKey key(PromiseFlatCString(aFFREName).get());
+  PRBool anyFoundry = (PromiseFlatCString(aFFREName).get()[0] == '*');

Comment 26

[kinmoz]

It's better to flatten once. The string docs suggest doing things this way:

   const nsPromiseFlatString& flat = PromiseFlatString(aFFREName);
   nsCStringKey key(flat.get());
   PRBool anyFoundry = (flat.get()[0] == '*');

Should we be checking the length before we go indexing into the string?

Comment 27

[kill this account]

thanks.

The working model for a FFRE is <foundry>-<family>-<registry>-<encoding>
so the minimum length is 7.

Comment 28

[kill this account]

checked in

Comment 29

[kill this account]

we probably want to back this out for 0.9.5

Comment 30

[kill this account]

backed out.

Comment 31

[rbs]

When the fix was in, it seemed to have had an effect in bug 103159.

Comment 32

[Jungshik Shin]

Another side-effect I found when the fix was in
is that badly-scaled fonts are mysteriously used
to render US-ASCII part of US-ASCII + CJK or
other multi-script texts. These fonts are also
used for pure-US-ASCII pages (such as http://bugzilla.mozilla.org for which I'm
gonna
attach a screenshot) when View|Character Coding
is set to almost anything other than Western.

I font-traced and found that those badly-scaled fonts
are all in iso8859-9 encodings. Note that iso8859-9 encoded fonts are as good as
iso8859-1 encoded
fonts to cover US-ASCII part in terms of glyph coverage.
When non-Western encoding is selected, font-trace
included the following:

...snip....
bitmap (non-scaled) font:
-adobe-helvetica-medium-o-normal--17-120-100-100-p-0-iso8859-9,
nsFontMetricsGTK.cpp 3224
bitmap (non-scaled) font:
-adobe-helvetica-medium-r-normal--17-120-100-100-p-0-iso8859-9,
nsFontMetricsGTK.cpp 3224
bitmap (non-scaled) font:
-adobe-times-bold-i-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp
3224
bitmap (non-scaled) font:
-adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp
3224
bitmap (non-scaled) font:
-adobe-times-medium-i-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp
3224
bitmap (non-scaled) font:
-adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp
3224
loaded -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9
returns -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9
loaded -adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9
returns -adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9
.... snip....

At first I was puzzled by the existence of these fonts
at 17px because 'xlsfonts | grep iso8859-9 | grep 17'
yielded nothing on my Linux box(RH 7.1). xlsfonts
uses XListFonts() used by nsFontMetricsGTK.cpp 
to get the list of fonts. However, nsFontMetricsGTK.cpp
found these fonts at 17px (unscaled and bitmap) while
xlsfonts does not. As a last resort, I tried
'xlsfonts -fn -adobe-times-*-*-*--*-*-*-*-*-*-iso8859-9'
and the result does include 

-adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9

There is NO 17 px bitmap font in iso8859-9 on my system,
but somehow XListFonts comes up with it. I was wondering
if this is a bug on X11 library on my system when
I realized that averageWidth field is 0. I don't
yet understand why XListFonts() comes up with this
(non-zero pixelSize and pointSize and zero averageWidth).

What's clear to me, though, is that these fonts have
to be skipped in a loop in GetFontNames(). They're
not unscaled-bitmap fonts (they look really ugly
when used because they're scaled). Moreover, 'genuinely
scaled' counterparts (with all three fields,
pixelSize, pointSize, and averageWidth zero) are
returned by XFontLists() so that skipping these
strange cases don't get bitmap scaled fonts
out of consideration. In case of iso8859-1 encoded
fonts, there are actually unscaled bitmap fonts
at 17px (with non-zero pixelSize,pointSize and
averagewidth) so that these weired cases
(with zero averageWidth and nonzero pixelSize and pointSize) can be safely
skipped in iso8859-1 case
as well.

I'm going to attach a patch to address this issue.
It may not be a very good idea to attach this patch here
because the problem I described above was lying
around in GetFontNames() without Brian's patch.
His patch only moved it up to the surface.

Comment 33

[Jungshik Shin]

Attachment: screenshot with ugly scaled bitmap iso8859-9 fonts

Comment 34

[Jungshik Shin]

Attachment: a patch to skip fonts with zero av.width and nonzero pixel/point size

Comment 35

[Jungshik Shin]

With both Brian's patch and my patch (attachment 53094 [details] [diff] [review]),
it seems like example pages in bug 103159 are rendered
fine, but I'm not sure because I don't know
how the sample URL given in that bug is supposed
to be rendered. (at least, two tables in the page
have the same widths and fit well with the rest of the page to my eyes). 

rbs, can you test it with
both Brian's fix and attachment 53094 [details] [diff] [review] in? 
 

Comment 36

[kill this account]

Fonts are about 95% reasonable and about 5% chaos.

I am somewhat uncomfortable hardcoding in cases like this.
+      // skip 'mysterious' and 'spurious' cases like
+      // -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9
+      if (pixelSize[0] != '0' || pointSize[0] != 0 ) 
+        continue;

Perhaps we need to add font banning before we can enable AFRE.

Comment 37

[kill this account]

need font banning first. see bug 104075

Comment 38

[kill this account]

--> ftang

Comment 39

[Frank Tang]

Linux font problem. give to shanjian for research. Change the milestone by your
judgement. take your time. 

Comment 40

[Roland Mainz]

shanjian:
Why milestone 0.9.9 ?
We have a working patch - and the "font banning code"(=bug 104075) is ready
within a few days (depends on how fast I can get reviews) ...
... I still vote for 0.9.7 as target milestone  ...

Comment 41

[Shanjian Li]

I have no objection if we can get it for 097. I reset target just because I have 
too many issue on my plate for 097. It is good to know things are in progress. 
I can take a look of 104075 tomorrow to see if I can give you a review. I have 
to focus on another issue today. 

Comment 42

[Roland Mainz]

shanjian wrote:
> I have no objection if we can get it for 097. I reset target just because I 
> have too many issue on my plate for 097.

bstell, wanna steal this bug from shanjian ? :)

> It is good to know things are in progress.

:-)

> I can take a look of 104075 tomorrow to see if I can give you a review. I have 
> to focus on another issue today.

Thanks!
Note that the patch in bug 104075 is Xlib-toolkit only, e.g. you have to build
with "configure --enable-toolkit=xlib" ...

Comment 43

[Roland Mainz]

Stealing this from shanjian. I just want to make it sure that we do not miss the
0.9.7 train ...

Comment 44

[Roland Mainz]

Comment on attachment 53094 [details] [diff] [review]
a patch to skip fonts with zero av.width and nonzero pixel/point size

This workaround breaks Xprint "printer buildin fonts" for some reason...

Printing on a 300DPI PS printer gives me the follwoing list of fonts which are
banned by the code - but AFAIK some of them should not be banned:
-- snip --
xxlib_find_handle: 'xprint' entry 0
xxlib_register_handle: new entry 'xprint' a7d6f8
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--0-0-1200-1200-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--0-0-1200-1200-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--0-0-1200-1200-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--0-0-1200-1200-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--0-0-0-0-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--0-0-0-0-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--0-0-0-0-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--0-0-0-0-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--0-0-75-75-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--0-0-75-75-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--0-0-75-75-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--0-0-75-75-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-i-normal--0-0-100-100-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-bold-r-normal--0-0-100-100-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-i-normal--0-0-100-100-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1'
attempt to ban (possible) printer-buildin font
'-adobe-times-medium-r-normal--0-0-100-100-p-0-iso8859-1'
XpuCheckSupported: XpGetOneAttribute(job-attributes-supported) returned
'job-name job-owner notification-profile xp-spooler-command-options '
-- snip --

Comment 45

[Roland Mainz]

Attachment: All-in-one (GTK+ and Xlib) patch for 2001-11-30-08-trunk

Updated patch, includes attachment 49307 [details] [diff] [review], attachment 50067 [details] [diff] [review] and attachment 53094 [details] [diff] [review]
(except that I disabled it when the destination is a printer)

Comment 46

[Roland Mainz]

jst:
Wanna give me an rs= for the new patch, please ?

Comment 47

[Johnny Stenback (:jst)]

- Fix the messed up indentation in NodeAddScalable().

- In NodeAddSize(), fix the next-line argument indentation in the method
declaration, and this code leaks |copy| if new nsFontGTKNorma() return null
(i.e. out of memory).

- Loose the empty string argument to the nsCAutoString constructor at:

+    nsCAutoString nodeName("");

and use Assign() in stead of Append() when you know the string is empty (just
below the above line):

+    if (aAnyFoundry)
+      nodeName.Append('*');
+    else
+      nodeName.Append(foundry);

same thing at line ~3400.

- No error checking after PR_smprintf() at the end of NodeAddScalable() (two
occurances).

rs=jst with that fixed...

Comment 48

[Roland Mainz]

Attachment: Patch for 2001-11-30-08-trunk to match rs=jst

Comment 49

[Roland Mainz]

bstell:
Wanna check this "in", please ?

Comment 50

[Roland Mainz]

Checked in...

Followups are...
- bug 104075 ("need X font banning")
  Which adds a way to ban fonts via (user-editable) prefs
and
- bug 103159 ("sorting fonts by foundry names cause font size of css ignored in
some cases")
  We have to check whether attachment 53094 [details] [diff] [review] really fixes this ...

Comment 51

[R.K.Aa.]

Fonts on linux now look like shit.

I used to have these fonts set:
Fonts for:    Western
Proportional: Serif
Serif:        monotype-arial-iso8859-1
Sans-serif:   monotype-arial-iso8859-1
Fantasy:      adobe-courier-iso8859-1
Monospace:    monotype-courier new-iso-8859-1

Starting up moz after rebuilding CVS with this checkin, all my fonts were reset
to native linux font adobe-courier. All font selections have become truncated
down to nearly none, and it is impossible to select for instance truetype fonts
- they are no longer an option.

Comment 52

[R.K.Aa.]

The checkin also causes truetype fonts to be ignored in CSS on pages.
Moz doens't seem to be able to display TT fonts on linux anymore.

Backing out the two checkins fixed the problem. I suggest this whole patch is
backed out from the main tree untill the bugs are sorted out.

Comment 53

[R.K.Aa.]

Attachment: CNN.com before the checkin: looks OK on Linux

Comment 54

[R.K.Aa.]

Attachment: CNN.com after the checkin: Does not look OK on Linux. Hard to read

Comment 55

[hacker formerly known as [e-mail]]

Patch has been backed out.

Comment 56

[Roland Mainz]

[e-mail]:
OK, looks that the font ban was to "tight".
But... what is wrong with attachment 60139 [details] (screenshot after "checkin"). Can you
point out where do you see the "bad" fonts ?!

----

I'll rework the font ban part and add a rule that it does not reject outline
scaled fonts ...

Comment 57

[R.K.Aa.]

Roland Mainz: All fonts are bad there. I find the difference pretty striking.
Adobe-Helvetica is used instead of Verdana, Arial and more - all over the page. 

Adobe helvetica is a much narrower font, and with less spacing between fonts.
Readability is lower than with for instance a typical good webfont like Verdana,
which is used a lot on the page (if available)

Comment 58

[Roland Mainz]

Attachment: Same patch as attachment 60105 but added a rule to avoid banning outline scaled fonts

Comment 59

[Roland Mainz]

R.K.Aa:
Wanna try the new patch, please ?

Comment 60

[R.K.Aa.]

Am at work without Mozilla. Back home in 3h 15m.
Will test patch first thing.

Comment 61

[kill this account]

> But... what is wrong with attachment 60139 [details] (screenshot after "checkin"). 
> Can you point out where do you see the "bad" fonts ?!

It might be that his display is a bit blurry in which case the slight
reduction in font size (now that the correct size is available) causes the
text to be much harder to read. In bug 102199 I have people asking that
moz go back to buggy behavior because now that it uses the *requested* size
(requested by the html) they find it hard to read.


> I'll rework the font ban part and add a rule that it does not reject outline
> scaled fonts ...

Careful, the urw fonts which support scalable fonts are very ugly.

Comment 62

[R.K.Aa.]

I started reading the first attachment in this bug.. silly me..

If attachment 45076 [details] is correct, the HPUX font setup creates faulty fonts.dir
files (or equivalent), as shown by the quoted setup for the font Arial Black.
(Initial xlsfonts output in attachment id=45076 added as "Submitter_Text(Added
010710)")

I don't know the X font system all that well, but the X Window System User
Guide, Motif 1.2 Edition, does not mentioned "black" as a weight. Only medium,
bold and demibold. All "arial black" fonts are weight medium, which for some
reason seem to get truncated when "black" fills its placeholder - but it's still
not a valid weight.

However: "black" as a weight in the X font system is not the real issue here.
The issue is that the Arial Black setup above explicitly tells X that Arial
Black *IS* Arial. If the person wished otherwise, and wanted to tell X about a
separate font called "Arial Black", he/she should use the real font name
INCLUDING the space. I believe the issue would have been identical had the font
been called "arial white" - someone with access to Fontmonger might want to test
that.

By adding a separator after Arial, X is told that "here ends the name". And in
other words that all fonts arial are arial, and any "Arial Black" effectively
does not exists anymore.

In comment from "************ marketing(Added 010718 by) ***********
a few "workarounds" are suggested, but the most obvious thing to try is not
mentioned: simply correcting the extra "-" in fonts.dir/scale files - or
whatever files HPUX X server fetches its info from. 

And should it choke on the space, there's still the fonts.alias left to correct
for it all, where fonts can be completely protected by quotes.

I really don't like the idea of Mozilla suddenly trashing my font options
because of what appearantly is a bug in HPUX X server. Before fonts on Linux are
lobotomized for good, can affected persons try the approach above? (Removing the
extranous "-" between "arial" and "black", and replace it with a space.)

I have never seen X mistake Arial for Arial Black on Linux. Below is the setup
ttmkfdir makes on XFree86 3.3.6 as well as 4.01 for the particular font in
fonts.dir, followed by how xlsfont sees that font. 

$ grep Black fonts.dir 
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-adobe-standard
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ascii-0
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-fcd8859-15
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp437
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp850
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp852
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp866
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-1
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-10
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-15
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-2
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-3
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-4
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-5
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-7
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-9
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-koi8-r
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-koi8-ru
ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251


$ xlsfonts |grep black
-bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-1
-bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-2
-bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-9
-bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-1
-bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-2
-bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-9
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-adobe-standard
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-adobe-standard
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ascii-0
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ascii-0
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-fcd8859-15
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-fcd8859-15
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp437
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp437
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp850
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp850
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp852
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp852
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp866
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp866
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-1
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-1
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-10
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-10
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-15
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-15
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-2
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-2
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-3
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-3
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-4
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-4
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-5
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-5
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-7
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-7
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-9
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-9
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-r
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-r
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-ru
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-ru
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251
-monotype-arial black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251
-monotype-arial black-medium-r-normal--10-100-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--10-100-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--11-110-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--11-110-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--12-120-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--12-120-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--13-130-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--13-130-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--14-140-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--14-140-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--15-150-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--15-150-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--18-180-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--18-180-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--24-240-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--24-240-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--6-60-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--6-60-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--7-70-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--7-70-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--8-80-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--8-80-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--9-90-100-100-p-0-iso8859-1
-monotype-arial black-medium-r-normal--9-90-100-100-p-0-iso8859-1
[dark@localhost TrueType]$

(additional sizes due to a fonts.alias)

(Ok.. i'll test that patch..)

Comment 63

[R.K.Aa.]

My display is not blurry. If you don't see that the fonts in use are very
different in those two screenshots, we have a problem. The slight reduction in
size is not the issue. Adobe Helvetica is simply  a "cramped" font with little
space between characters, compared to the rounder and spacier verdana, which is
widely accknowledged for it's good onscreen readability.

When Verdana is the first suggested font in the CSS of a page, i would much
prefer that to having Helvetica displayed. Helvetica is not a particular good
webfont.

Comment 64

[R.K.Aa.]

Applied patch - so far so good. Haven't discovered anything missing yet.

-TrueType fonts are back in preferences
-CNN.com is intact. TT fonts visible, appearing as in attachment 60138 [details]
-MSN.com appears to have fonts one number larger than it used to (?)

(Doesn't hurt (!) - they were a number too small. May not be due to this patch
at all - comparing to a month old screenshot.)

Comment 65

[Roland Mainz]

R.K.Aa:
Thanks!

Please r= the new patch that we can check in it again ...

Comment 66

[Roland Mainz]

RKA wrote:
> My display is not blurry. If you don't see that the fonts in use are very
> different in those two screenshots, we have a problem.
etc. etc.
No no, _now_ I see the difference. I simply did not compared the type of the
used fonts, I only looked at the screen dump and thougth "WTF, what should be
wrong with this screenshot ?! I can read the text... and it looks good for
me...").

Comment 67

[R.K.Aa.]

r=R.K.Aa

Comment 68

[kill this account]

The weight black is correctly recognized by moz as a bold weight.

The problem this bug is addressing is that the font search code stops at the 
first "arial" group and does not try other arial groups from different 
foundries. The first arial group only has the arial font in a black weight
and from that group moz picks the best choice "in that group" ignoring all
other groups with that fontname.

Using the name "arial black" would be another solution to "this particular
font problem" but the problem shows up in other areas such as forcing
bitmap scaling because the first font group of a given name has limited
sizes even though there are other groups available with closer sizes.

The HP issue is only part of a larger problem:

  for a given "fontname" moz only looks in the first "foundry-fontname" group 
  and ignores fonts in other "foundry-fontname" groups

Is verdana the first font in the CSS for attachment 60138 [details] and attachment 60138 [details]?

Comment 69

[Darin Fisher]

fixed-on-trunk

Comment 70

[R.K.Aa.]

>The weight black is correctly recognized by moz as a bold weight.

Wrong, I believe. Arial Black is not bold. It's "medium" and comes in that
weight only. Another sample of a "medium only" but "fat" looking font from The
Monotype Corporation is Impact.

>Using the name "arial black" would be another solution to "this particular
>font problem" 

It would be the CORRECT solution. The fonts name is 'Arial Black', not 'Arial'.

>Is verdana the first font in the CSS for attachment 60138 [details] and attachment 60138 [details]?

Can't swear if it's the first in the CSS - no font is explicity stated in
".cnnMainT2Area", but it obviously inherits Verdana from somewhere since it's
Verdana displaying.

Comment 71

[kill this account]

the HP bug had this list of fonts (see attachment 45076 [details])
  $ xlsfonts -fn "*arial*"
  -mono-arial-black-r-normal--0-0-0-0-p-0-hp-roman8
  -mono-arial-black-r-normal--0-0-0-0-p-0-hp-roman8
  -mono-arial-black-r-normal--0-0-0-0-p-0-iso8859-1
  -mono-arial-black-r-normal--0-0-0-0-p-0-iso8859-1
  ...

For whatever reason it is named "arial" not "arial black" and is being used
everywhere a medium weight arial font is requested because the font code
only looked at the first arial.

> It would be the CORRECT solution. The fonts name is 'Arial Black', not 
> 'Arial'.

Do you see the code parsing the space as a field separator?

The macro that finds the field does not stop on spaces
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#3467
3467 #define FIND_FIELD(var)           \
3468   char* var = p;                  \
3469   while ((*p) && ((*p) != '-')) { \
3470     p++;                          \
3471   }                               \
3472   if (*p) {                       \
3473     *p++ = 0;                     \
3474   }                               \
3475   else {                          \
3476     continue;                     \
3477   }

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#3495
3493     FIND_FIELD(foundry);
3494     // XXX What to do about the many Applix fonts that start with "ax"?
3495     FIND_FIELD(familyName);
3496     FIND_FIELD(weightName);
3497     FIND_FIELD(slant);
3498     FIND_FIELD(setWidth);
3499     FIND_FIELD(addStyle);

If you do find it separating on a space then kindly file a bug.

> > Is verdana the first font in the CSS for attachment 60138 [details] and 
> > attachment 60138 [details]?

> Can't swear if it's the first in the CSS - no font is explicity stated in
> ".cnnMainT2Area", but it obviously inherits Verdana from somewhere since 
> it's Verdana displaying.

We need to be careful here. If we don't know what is specified we cannot
determine the "correct" behavior.

Comment 72

[R.K.Aa.]

I'm simply saying that Moz should not "guess" how an X fontserver might be
misconfigured. The missing whitespace is NOT a concern of Mozilla's of course -
moz simply interprets what its told - which is the right thing. I'll drop the
"black" weight for now, but it's wildly incorrect. This bug was
oh-so-next-to-bogus when filed, but as you say: There are other considerations
where other foundries may have a better and more scaleable version of a
requested font.

So don't misunderstand me: I'm *pleased* with the outcome of this fix.
Attaching a screenshot I believe demonstrates the improvement on Linux very
well. Assembled from 3 screenshots of same page at different times, from
http://jigsaw.w3.org/css-validator/

top:    before antialiasing of bitmap fonts
middle: after antialiasing of bitmap fonts ("adobe-times" is still used)
bottom: after THIS fix: ("monotype-times new roman" is used)

Comment 73

[R.K.Aa.]

Attachment: 3-in-one screenshot showing font rendering improvement on Linux

Comment 74

[R.K.Aa.]

I'm lying: the 3'rd sample is using -urw-times instead of adobe-times !

Comment 75

[kill this account]

The 1st is a bitmap scaled (up) font (very ugly)

The 2nd is an anti-aliased bitmap scaled (aasb) (up) font
 the anti-jagging is the rounding of the corners. 
 aasb, bug 90813, helps alot at smaller sizes. At 
 larger sizes the aasb glyphs are "somewhat" better
 but still not great.

The 3rd is a outline scaled (non anti aliased) and is
good looking (yeah)

Comment 76

[Peter B. West]

On linux redhat 7.0.  Build 2001120512 has completely destabilised my font
sizes.  Fonts now display too big.  Accessing my fonts lists gives me only
8859-3 fonts, but I don't know how long this situation has pertained, because I
have had no cause to modify my font settings for many months.

I reverted through a number of previous builds which I had on hand, and am  now
on  2001120206, but the instability remains.  My prefs.js has only

user_pref("font.default", "sans-serif");
user_pref("font.language.group", "[object Window]");
user_pref("font.name.cursive.x-western", "2rebels-cairo-iso8859-1");
user_pref("font.name.fantasy.x-western", "2rebels-cairo-iso8859-1");
user_pref("font.name.monospace.x-western", "monotype-courier new-iso8859-15");
user_pref("font.name.sans-serif.x-western", "monotype-arial-iso8859-15");
user_pref("font.name.serif.x-western", "monotype-times new roman-iso8859-15");
user_pref("intl.font_charset", "iso-8859-1");
user_pref("intl.font_spec_list", "monotype-courier_new-0-scale-fixed-iso-8859-15
,monotype-arial-0-scale-prop-iso-8859-15,monotype-andale mono-0-noscale-fixed-ko
i8-r,monotype-andale mono-0-noscale-prop-koi8-r,monotype-andale mono-0-noscale-f
ixed-x-user-defined,ult1mo-alexandria-0-noscale-prop-x-user-defined,nsPseudoFont
-courier-100-noscale-fixed-UTF-8,nsPseudoFont-times-120-noscale-prop-UTF-8,isas-
fangsong ti-120-noscale-fixed-gb_2312-80,isas-fangsong ti-120-noscale-prop-gb_23
12-80,daewoo-gothic-0-noscale-fixed-ks_c_5601-1987,daewoo-gothic-0-noscale-prop-
ks_c_5601-1987,misc-fixed-120-noscale-fixed-jis_x0201,misc-fixed-120-noscale-pro
p-jis_x0201,admas-fidel-120-noscale-fixed-jis_x0208-1983,admas-fidel-120-noscale
-prop-jis_x0208-1983,cbs-song-120-noscale-fixed-x-cns11643-2,cbs-song-120-noscal
e-prop-x-cns11643-2,cbs-song-120-noscale-fixed-x-cns11643-1,cbs-song-120-noscale
-prop-x-cns11643-1,monotype-andale mono-0-noscale-fixed-iso-8859-9,bitstream-ame
ricana-0-noscale-prop-iso-8859-9,monotype-andale mono-0-noscale-fixed-iso-8859-7
,monotype-andale mono-0-noscale-prop-iso-8859-7,monotype-andale mono-0-noscale-f
ixed-iso-8859-5,monotype-andale mono-0-noscale-prop-iso-8859-5,monotype-andale m
ono-0-noscale-fixed-iso-8859-2,ult1mo-alexandria-0-noscale-prop-iso-8859-2,monot
ype-courier_new-0-scale-fixed-iso-8859-1,monotype-arial-0-scale-prop-iso-8859-1,
");

that contain the word "font".

What surprises me is that I cannot recover my previous font setup.  What has
changed, and how can I revert it?

Comment 77

[Yuying Long]

Brian, could you please verify this bug instead of me?  Thanks!
Change QA contact to Brian.

Comment 78

[Peter B. West]

A further comment on this.  linux redhat 7.0 with XFree86 4.1.0
My proportional fonts (san-serif) are now stuffed, but my mono-spaced font still
appears to be at the original size (from memory, 13pt for proportional and 12pt
for mono. BTW, where are such values defined?)
In the months that I have been using Mozilla, the most obvious attraction of the
product was its font handling.  After the miseries of Netscape 4.7..., fonts
Just Worked.  I could set font sizes without agonies, and the full set of my
fonts seemed to be available.
These changes are like 4.7 deja vu.  It now Just Doesn't Work.
I would be very grateful if someone could tell me how to get back to the
previous stable font situation while this stuff is sorted out.

Comment 79

[Roland Mainz]

[e-mail]:
Could you please open a seperate bug for this (and assign it to me or bstell),
please ?
I'd like to treat this one as "fixed" and hunt your problems using a seperate
bug...

Comment 80

[kill this account]

In the months that I have been using Mozilla, the most obvious attraction of the
product was its font handling.  After the miseries of Netscape 4.7..., fonts
Just Worked.  I could set font sizes without agonies, and the full set of my
fonts seemed to be available.

Peter: Erik van der Poel, myself, Roland, rbs, and other have put a lot of
work in to this and we are glad to hear your positive comments. There is
still lots of things to be improved so the code is still changing. Bumps in the
road do happen and we apologize for the current difficulty. We ask for your
patience and help as we fix this.


Roland: I would recommend that you ask him to make a minimal html page that 
demonstrates the problem, set the environment variable NS_FONT_DEBUG=1D 
(see nsFontMetricsGTK.cpp for the values and printfs), do a minimal run
"./mozilla html:///dirs/filename.html", and then attach the html and moz's 
output to this bug. (I like the output attached rather than insert inline 
since they tend to be longish and it makes scanning the bug hard for new
people.)

(I added these to the font search code since every system tends to have 
different fonts and it was often hard to debug problems since I could not
reproduce the setup.)

Comment 81

[rbs]

The font prefs are horked at the moment (bug 108939) and this is complicating
tracking font problems. There is a similar default font-size mystery on the Mac
at bug 111673.

Comment 82

[Ian Wehrman]

pbwest: did you ever open a separate bug for this? it's been driving me insane
since the fix for this bug went in a few weeks ago. an example url in which the
fonts have changed for the worse is this: http://html.satelliterecords.com/HOUSE.HTM
if i decrement the font size on this page once (via ctrl -) everything is back
to normal, and incrementing the size makes it readable, but too large. sorry for
the spam here, i'm just wondering if the appropriate bug has been filed yet... 

Comment 83

[Peter B. West]

Ian Wehrman: I raised bug 113814, which was marked as a duplicate of 108939.

I tried the URL you mentioned, and had no problems with it (linux redhat 7.0;
XFree86 4.1.0) on build within the past two days.  The page shows up initially
at a compact but readable size; Ctrl - reduces the font to an uncomfortable
size, and Ctrl + then restores it to the original size.

Comment 84

[kill this account]

When determining proper behavior the question should always be:

  Is moz following the html/css as closely as possible?

Past behavior is at best a crude indicator. This is why it is critical
to know what font sizes are being requested.