83403 - at some scaling factors national character glyphs sizes/styles are mismatched

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Robert Spalek]

Mozilla 0.9 2001050521
language-preferences: czech [cs], english [en]
codepage used: windows-1250

In all URL's (example given above) the default fonts look well.  But when I
scroll the font sizes by a mouse wheel, standard and national characters are
taken from another fonts sometimes -- sometimes one font is in italic and the
other is not, sometimes one font is bigger than another one.

I don't know how the font selection mechanism works, perhaps the missing fonts
is the problem, but perhaps there's an error.

I send a screenshot too (but it is not the worst one, I've seen much more ugly
pages).

Comment 1

[Robert Spalek]

Attachment: screenshot of http://zive.cz/

Comment 2

[John Morrison]

-> i18n

Comment 3

[nhottanscp]

Reassign to bstell, cc to ftang.

Comment 4

[Frank Tang]

Maybe we should put ISO-8859-2 into a seperate group than WESTERN in 
nsFontMetricsGTK.cpp
[e-mail]- do you have a local build? can you try patch if I can send you 
one? I cannot reproduce your problem right now. 

mark moz0.9.3 

Comment 5

[Robert Spalek]

I have not built the sources, I just downloaded the nightly build, now it is the
version 2001060411, which has the error too.

If you tell me, how to download a local build and how to apply your patch, I
surely would try it.  But I'm afraid it would take too long time to compile
Mozilla on my K6-300.

Comment 6

[Frank Tang]

I think the problem is we do not have language group for all in the 
nsFontMetricsGTK.cpp
 x-central-euro,  x-cyrillic, el, tr, he, ar, th,x-baltic
later to solve this
we should add
nsFontLangGroup FLG_CE =      { "x-central-euro", nsnull };
nsFontLangGroup FLG_CYRILLIC ={ "x-cyrillic", nsnull };
nsFontLangGroup FLG_BALTIC =  { "x-baltic", nsnull };
nsFontLangGroup FLG_EL =      { "el", nsnull };
nsFontLangGroup FLG_TR =      { "tr", nsnull };
nsFontLangGroup FLG_HE =      { "he", nsnull };
nsFontLangGroup FLG_AR =      { "ar", nsnull };
nsFontLangGroup FLG_TH =      { "th", nsnull };

and 
-   { "cp1251-1",           &FLG_NONE,    &CP1251        },
-   { "iso8859-13",         &FLG_WESTERN, &ISO885913     },
-   { "iso8859-2",          &FLG_WESTERN, &ISO88592      },
-   { "iso8859-4",          &FLG_WESTERN, &ISO88594      },
-   { "iso8859-5",          &FLG_NONE,    &ISO88595      },
-   { "iso8859-6",          &FLG_NONE,    &ISO88596      },
-   { "iso8859-7",          &FLG_WESTERN, &ISO88597      },
-   { "iso8859-8",          &FLG_NONE,    &ISO88598      },
-   { "iso8859-9",          &FLG_WESTERN, &ISO88599      },
-   { "koi8-r",             &FLG_NONE,    &KOI8R         },
-   { "koi8-u",             &FLG_NONE,    &KOI8U         },
-   { "tis620.2529-1",      &FLG_NONE,    &TIS620        },
-   { "tis620.2533-0",      &FLG_NONE,    &TIS620        },
-   { "tis620.2533-1",      &FLG_NONE,    &TIS620        },
-   { "tis620-0",           &FLG_NONE,    &TIS620        },
-   { "iso8859-11",         &FLG_NONE,    &TIS620        },

+   { "cp1251-1",           &FLG_CYRILLIC,&CP1251        },
+   { "iso8859-13",         &FLG_BALTIC,  &ISO885913     },
+   { "iso8859-2",          &FLG_CE,      &ISO88592      },
+   { "iso8859-4",          &FLG_BALTIC, &ISO88594      },

+   { "iso8859-5",          &FLG_CYRILLIC,&ISO88595      },
+   { "iso8859-6",          &FLG_AR,      &ISO88596      },
+   { "iso8859-7",          &FLG_EL,      &ISO88597      },
+   { "iso8859-8",          &FLG_HE,      &ISO88598      },
+   { "iso8859-9",          &FLG_TR,      &ISO88599      },
+   { "koi8-r",             &FLG_CYRILLIC,&KOI8R         },
+   { "koi8-u",             &FLG_CYRILLIC,&KOI8U         },
+   { "tis620.2529-1",      &FLG_TH,      &TIS620        },
+   { "tis620.2533-0",      &FLG_TH,      &TIS620        },
+   { "tis620.2533-1",      &FLG_TH,      &TIS620        },
+   { "tis620-0",           &FLG_TH,      &TIS620        },
+   { "iso8859-11",         &FLG_TH,      &TIS620        },


will this solve your problem ? If so, let's try to put into moz0.9.3 as nsBranch 
since it is low risk.

Comment 7

[Frank Tang]

reassign to bstell

Comment 8

[Frank Tang]

I will put a real patch later. 

Comment 9

[Frank Tang]

I think this is one of the low risk fix.

Comment 10

[Frank Tang]

reassign to ftang

Comment 11

[Frank Tang]

Attachment: patch to add addtional lang group

Comment 12

[Frank Tang]

bstell- can you code review this one ?
robert- does this fix your problem ?

Comment 13

[kill this account]

I'd like to study this a bit.

Robert: 
1) can you set the environment variable NS_FONT_DEBUG=9 and capture moz's
   output when displaying this page and attach it to this bug?

2) Can you also attach the output of "xlsfonts -u"?

3) What system are you running?

4) Does you system just have stock fonts or have you installed additional
   fonts?

Comment 14

[kill this account]

This patch (attachment 40555 [details] [diff] [review]) is a fairly large change who's ramification are 
not well know to solve the problem:

  at some sized the glyphs do not all match

Comment 15

[Frank Tang]

ok, definitely too risky for nsbranch. remove nsbranch.
I think we should try to land to trunk at least. bstell- can you r= this one and 
we get a sr= so we can land to the trunk?

Comment 16

[kill this account]

I would be more comfortable making this change if we saw the problem
in a more standard situation and/or other pages.

Comment 17

[Frank Tang]

remove m9.3

Comment 18

[Frank Tang]

move to bstell

Comment 19

[Robert Spalek]

Sorry, I've been out for a long time.  I don't compile Mozilla, so I can not
apply source patches.  Now I use mozilla 0.9.3 build id 2001080104 and
everything seems OK on other pages (zive.cz is not available now).

I run Debian 3.0 woody system on i386 platform, XFree86 4.0.2, SawFish window
manages.

I've some additional iso-latin-2 fonts installed on the system.  I don't know
their original source, I got them from my friend :-)

Comment 20

[Robert Spalek]

Attachment: gzipped listing of the fonts

Comment 21

[kill this account]

Many factors control how the Linux/Unix Mozilla displays characters.

The CSS font name spec (if specified) tells the font subsystem which is the 
web page designer's desired font. If a font of this name is available it will 
be the first font in the list of fonts to get glyphs from. 

The user's font preference provides a fallback font name which the font 
subsystem uses if the CSS font name is not specified or is not available.
This font will be next in the list of fonts to get glyphs from. This setting
is per language group so depending on what encoding the browser thinks the
page is in the glyphs may be selected from a different font.

The CSS font size spec (if specified) tells the font subsystem which is the 
web page designer's desired font size. If the CSS font size is missing the
font size comes from the user's pref for the document's language group. When 
picking fonts the font subsystem will try to find a font a near to this size 
as possible.

If a font style of the exact style (regular vs bold, roman vs italic, etc)
is not available, the font subsystem will try to make the text readable
even if it means the style is not an exact match.

If there are characters that are not available in the first font the
browser still needs to display those characters so it will go looking for
other fonts to fill in from. The code first looks in fonts in the document's
language group. Next it looks in fonts in the user's locale's language 
group. Next it looks at all the fonts in user font preferences. Next it
looks in all fonts available. Next it tries to transliterate (eg: "(c)" for
the copyright symbol). The last choice is a question mark, '?', character.

I'm not surprised that at some sizes it showes that the font subsystem is 
doing this character fill-in.

If the system has a font of the desired name, of the desired size, of the 
desired style, and with the desired characters and the font subsystem is
filling in from other fonts this would be a bug.

Can we identify such a case?

Comment 22

[kill this account]

--> ftang

Comment 23

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 24

[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 25

[Travis Chase]

Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own

Comment 26

[Travis Chase]

Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own