41552 - Strange Linux font selection causes table layout failure

Status: RESOLVED INCOMPLETE

(Core :: Layout, defect, P3)

Description

[tenthumbs]

The attached page specifies 40pt. This is 42px on my system but Mozilla chooses
to load these fonts:

-adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso8859-1
-misc-fixed-medium-r-normal--42-*-*-*-c-*-iso8859-15
-adobe-symbol-medium-r-normal--34-240-100-100-p-191-adobe-fontspecific
-misc-fixed-medium-r-normal--42-*-*-*-c-*-jisx0201.1976-0

even though scalable helvetica and symbol fonts are available. From the attached
screen shot it looks like Mozilla lays out the table based on the helvetica and
symbol font metrics so the 42px fonts don't fit into the boxes.

I have no idea why Mozilla thinks 42 and 34 are close.

Comment 1

[tenthumbs]

Attachment: 40pt test page

Comment 2

[tenthumbs]

Attachment: PNG screen shot

Comment 3

[R.K.Aa.]

here my screenshot of the testcase
2000-060420
As you see i don't have fonts that large, so it's jagged and ugly, but it scales
correct..or so i think.

Comment 4

[R.K.Aa.]

Attachment: part of screenshot

Comment 5

[tenthumbs]

So, which fonts did it load? From a bash shell you can say
  NS_FONT_DEBUG=3 ./mozilla file:///test.html
and see what Mozilla does.

Comment 6

[tenthumbs]

I forgot that Mozilla thinks in px at the moment. Change 40pt to 42px in the
test page and the problem should be more obvious

Comment 7

[tenthumbs]

Just to confirm this, I'm attaching a 34px and a 42px screen shot. Note that the
table is exactly the same size in both which clearly should not be.

Comment 8

[tenthumbs]

Attachment: 34px screenshot

Comment 9

[tenthumbs]

Attachment: 42px screenshot

Comment 10

[Erik van der Poel]

X fonts are my area. Taking bug.

Comment 11

[Erik van der Poel]

I don't think I'll get to this soon. Marking Future.

Comment 12

[Hixie (not reading bugmail)]

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.

Comment 13

[Frank Tang]

reassign this to bstell and keep it as Future

Comment 14

[kill this account]

maybe this code (trying to avoid bitmap scaled fonts) is why "Mozilla thinks 42 
and 34 are close"

   2266   /*
   2267    * XXX Maybe revisit this. Upper limit deliberately set high (1.8) in
   2268    * order to avoid scaling Japanese fonts (ugly).
   2269    */
   2270   if ((ratio > 1.8) || (ratio < 0.8)) {
   2271     scalable = 1;
   2272   }

perhaps if we could distinguish bitmap scaled fonts from outline scaled fonts
(bug 27551) we could remove this code.

Comment 15

[tenthumbs]

Blindly preferring bitmap fonts is clearly bad, at least I think so, but it may
well be necessary.

To me, this bug is about the fact that, having selected a different font size
(by going for a bitmap font), mozilla should remember that decision for the
particular page and always use the chosen size. The problem becomes visible
because mozilla doesn't remember what it did.

Comment 16

[kill this account]

> Blindly preferring bitmap fonts is clearly bad, at least I think so, but 
> it may well be necessary.

The code's intent is to avoid bitmap scaled fonts since at that time we
could not distinguish bitmap scaled fonts (udly) from outline scaled fonts.

> To me, this bug is about the fact that, having selected a different font size
> (by going for a bitmap font), mozilla should remember that decision for the
> particular page and always use the chosen size. The problem becomes visible
> because mozilla doesn't remember what it did.

The issue here is that most fonts do not support all Unicode characters. Thus
to display a page we may need to open many fonts to get glyphs. If later in a
page we see a character not in the current font but available in a different
sized font we have no way to resize the earlier fonts.

This problem was compounded by the fact that we could distinguish between 
bitmap scaled fonts and outline scaled fonts. This often forced the code to
pick a differently sized font.

Now that we can distinguish bitmap vs outline scaling perhaps this issue
will be much less common (wishful thinking?)

Comment 17

[tenthumbs]

My point is that having selected a font size mozilla must stick to it. 
By using a 34px bitmap font, layout rendered the page for that size. 
Switching to a 42px font for a glyph not in the original font just won't 
do. Mozilla should stick to the 34px size.

Unfortunately, the ugly font issue won't go away by eliminating scaled 
bitmap fonts. Many X servers don't anti-alias so even scalable fonts 
sometimes look bad, particularly in the smaller sizes.

Comment 18

[kill this account]

We all agree that sticking to one size is good.

Would you do this even if it meant using a bitmap scaled font?

ie: the glyph is not available in the current font and the font that has the
glyph is only available in a different size font or a bitmapped scaled font?

Which of these two poor choices is better (or worse depending on how one 
choses to phrase the question)?

 1) A bitmap scaled font?
 2) A "similarly" sized bitmap (non-scaled) font

Sadly, the current code's idea of "similarly" sized bitmap font is crude

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#2277

    /*
     * XXX Maybe revisit this. Upper limit deliberately set high (1.8) in
     * order to avoid scaling Japanese fonts (ugly).
     */
    if ((ratio > 1.8) || (ratio < 0.8)) {
      scalable = 1;
    }

but this was put there trying to solve a problem of the code scaling a
font. Forcing the right size will bring this problem back which is not
a positive gain.

This is why I'm hoping that if we distinguish bitmap scaled from outline
scaled fonts we will solve both problems (or at least make it so neither
is so obnoxious).

Re: choosing small size outline scaled fonts vs bitmap (non-scaled) fonts:
It is true that not all outline scaled font are well tuned at small sizes but 
anti-aliasing seems like a separate issue since bitmap font don't anti-alias.

Comment 19

[tenthumbs]

If there were only a few glyphs missing, then I would say use a 
funny-looking glyph that's the right size rather than the other way 
around. It's that definition of "few" that's a problem.

I agree that "similar" is too broad for my tastes but I don't use the 
Asian fonts so they may have special problems, as the code comment 
indicates. Maybe "similar" should be applied only if the font is < 16pt or 
18pt or whatever. That could be a pref.

Maybe a more clever definition of similar would be better. I could see
looking at the bitmap fonts and creating an array of intervals in which
mozilla would use a particular bitmap font. If mozilla discovered that a
set bitmap fonts existed, then it could create an array of boundary points
so that if a request was between two boundaries it would use the proper
bitmap. I would suggest that the geometric, rather than arithmetic mean
would be better. It's probably also a good idea to use decipoints which
would give better resolution and is also the natural unit for X.

For example, if mozilla found 10,12,14,18, and 24 pt bitmap fonts, then it 
would calculate the sqrt(10*12), the sqrt(12*14), up to the sqrt(18*24). 
Create a lower bound with 1/low_ratio and a upper bound with the 
high_ratio. You get an array like this (in decipoints):
 limits:        (91, 110, 130, 159, 208, 277)
 use this font:    10   12   14   18   24
Outside these limits, used scalable or scaled bitmap fonts. If there's 
only one bitmap font size, then mozilla would have to choose a ratio. 
Another pref, I would think.

Maybe combine the two ideas.

As for anti-aliasing, I was just pointing out that the lack thereof is a 
major X failing. There are lots of older X servers out there and mozilla will
run on them so people will complain if it looks ugly.

I'm beginning to think that mozilla font selection is seriously flawed on
all platforms. It need to be carefully compartmentalized, but that's a 
whole other issue.

Comment 20

[kill this account]

--> ftang

Comment 21

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 22

[Frank Tang]

what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.

Comment 23

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 24

[Travis Chase]

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him

Comment 25

[Travis Chase]

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam