Last Comment Bug 83403 - at some scaling factors national character glyphs sizes/styles are mismatched
: at some scaling factors national character glyphs sizes/styles are mismatched
Status: NEW
: intl
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Linux
: -- normal with 1 vote (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: Makoto Kato [:m_kato]
Depends on:
  Show dependency treegraph
Reported: 2001-05-30 16:52 PDT by Robert Spalek
Modified: 2009-08-23 08:37 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

screenshot of (251.48 KB, image/jpeg)
2001-05-30 16:54 PDT, Robert Spalek
no flags Details
patch to add addtional lang group (5.00 KB, patch)
2001-06-28 17:12 PDT, Frank Tang
no flags Details | Diff | Splinter Review
gzipped listing of the fonts (30.96 KB, application/x-gzip)
2001-08-26 10:06 PDT, Robert Spalek
no flags Details

Description Robert Spalek 2001-05-30 16:52:58 PDT
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
Comment 1 Robert Spalek 2001-05-30 16:54:23 PDT
Created attachment 36583 [details]
screenshot of
Comment 2 John Morrison 2001-05-30 17:02:09 PDT
-> i18n
Comment 3 nhottanscp 2001-05-30 17:09:16 PDT
Reassign to bstell, cc to ftang.
Comment 4 Frank Tang 2001-06-05 15:17:08 PDT
Maybe we should put ISO-8859-2 into a seperate group than WESTERN in 
nsFontMetricsGTK.cpp 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 2001-06-07 08:19:18 PDT
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 2001-06-22 12:54:55 PDT
I think the problem is we do not have language group for all in the 
 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 };

-   { "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 2001-06-22 12:55:18 PDT
reassign to bstell
Comment 8 Frank Tang 2001-06-22 12:56:13 PDT
I will put a real patch later. 
Comment 9 Frank Tang 2001-06-28 14:40:22 PDT
I think this is one of the low risk fix.
Comment 10 Frank Tang 2001-06-28 16:51:08 PDT
reassign to ftang
Comment 11 Frank Tang 2001-06-28 17:12:07 PDT
Created attachment 40555 [details] [diff] [review]
patch to add addtional lang group
Comment 12 Frank Tang 2001-06-28 17:12:41 PDT
bstell- can you code review this one ?
robert- does this fix your problem ?
Comment 13 kill this account 2001-06-28 18:29:25 PDT
I'd like to study this a bit.

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
Comment 14 kill this account 2001-06-28 20:34:06 PDT
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 2001-07-03 16:51:12 PDT
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 2001-07-06 16:19:13 PDT
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 2001-07-11 15:58:56 PDT
remove m9.3
Comment 18 Frank Tang 2001-07-11 16:08:16 PDT
move to bstell
Comment 19 Robert Spalek 2001-08-26 10:05:20 PDT
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 ( is not available now).

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

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 2001-08-26 10:06:34 PDT
Created attachment 47162 [details]
gzipped listing of the fonts
Comment 21 kill this account 2001-08-28 14:49:33 PDT
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 2001-11-02 15:51:51 PST
--> ftang
Comment 23 Frank Tang 2001-11-07 17:51:57 PST
bulk move NEW FUTURE bug to ASSIGN
Comment 24 Frank Tang 2005-03-01 23:55:11 PST
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 2005-03-02 03:42:52 PST
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own
Comment 26 Travis Chase 2005-03-02 04:15:11 PST
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

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