Closed Bug 30856 Opened 25 years ago Closed 25 years ago

The charset handling in nsFontMetricsGTK.cpp is broken.

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: amundson, Assigned: erik)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.14-1.3.0f2 i686) BuildID: 2000030608 The charset handling in nsFontMetricsGTK.cpp is broken. On my RedHat 6.1 system, the result is that outline versions of courier are chosen over bitmaps of the right size. The results is poorly displayed fixed fonts. Reproducible: Always Steps to Reproduce: 1. install a font with bitmaps of one charset, outlines of another charset 2. select font in mozilla Actual Results: Outline fonts will always be chosen by mozilla if it randomly selected the outlines' charset first. Expected Results: It should have selected the bitmap fonts of the appropriate size. Here are the versions of courier available to my X installation, as installed by RedHat 6.1: ------------ |abacus>xlsfonts -u -fn "-*-courier-medium-r-*" -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1 -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1 -adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1 -adobe-courier-medium-r-normal--18-180-75-75-m-110-iso8859-1 -adobe-courier-medium-r-normal--24-240-75-75-m-150-iso8859-1 -adobe-courier-medium-r-normal--8-80-75-75-m-50-iso8859-1 -adobe-courier-medium-r-normal--11-80-100-100-m-60-iso8859-1 -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1 -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1 -adobe-courier-medium-r-normal--20-140-100-100-m-110-iso8859-1 -adobe-courier-medium-r-normal--25-180-100-100-m-150-iso8859-1 -adobe-courier-medium-r-normal--34-240-100-100-m-200-iso8859-1 -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2 -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-3 -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-9 -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2 -bitstream-courier-medium-r-normal--0-0-0-0-m-0-iso8859-9 -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1 -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1 -adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1 -adobe-courier-medium-r-normal--18-180-75-75-m-110-iso8859-1 -adobe-courier-medium-r-normal--24-240-75-75-m-150-iso8859-1 -adobe-courier-medium-r-normal--8-80-75-75-m-50-iso8859-1 -adobe-courier-medium-r-normal--0-0-75-75-m-0-iso8859-1 -adobe-courier-medium-r-normal--11-80-100-100-m-60-iso8859-1 -adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1 -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1 -adobe-courier-medium-r-normal--20-140-100-100-m-110-iso8859-1 -adobe-courier-medium-r-normal--25-180-100-100-m-150-iso8859-1 -adobe-courier-medium-r-normal--34-240-100-100-m-200-iso8859-1 -adobe-courier-medium-r-normal--0-0-100-100-m-0-iso8859-1 ------------ Notice that (1) The bitmaps fonts are first in the list. (2) There is an 11-point font available (3) All the bitmaps are iso8859-1. No matter what I do, I find that mozilla chooses to use one of the scaled fonts for courier instead of the bitmap fonts. In order to find out why, I built the source myself, and added the lines #define NOISY_FONTS #define REALLY_NOISY_FONTS to nsFontMetricsGTK.cpp. Looking through the output for the first reference to "courier", I see this: font = 'monospace' (no-name): searching for character c=0x61 (97) 'a' in ISO-8859-9 ==> charset=ISO-8859-9 weightIndex=3 strechIndex=4 -adobe-courier-medium-r-normal--11-*-*-*-m-*-iso8859-9[ISO-8859-9]: desired 11 chose 11 ==> found '-adobe-courier-medium-r-normal--11-*-*-*-m-*-iso8859-9' The search for courier is initially limited to ISO-8859-9. Looking at the list above, you will see that only outline fonts are available for ISO-8859-9. Of course, it finds a font of size 11. It would find any size because the fonts for that charset are all outline fonts. Having found a font of the right size, all future searches are restricted to ISO-8859-9. The end result is that the user can set all his font paths properly, but he has no way to stop mozilla from using an ugly scaled font, even though an unscaled one is available and earlier in the list. Looking at the code, it is pretty clear why, against all logic, ISO-8859-9 is preferred over ISO-8859-1: void TryFamily(nsFontSearch* aSearch, nsFontFamily* aFamily) { // XXX Should process charsets in reasonable order, instead of randomly // enumerating the hash table. if (aFamily->mCharSets) { PL_HashTableEnumerateEntries(aFamily->mCharSets, SearchCharSet, aSearch); } } The comment says it all. If I try the same thing on a machine with no fonts other than ISO-8859-1, everything is fine -- since the only choice is the right one, mozilla can't help but make the right decision and choose ISO-8859-1. After looking at the code, I can indentify the problem, but I cannot suggest a solution because I do not understand the rationale that goes into the searching algorithm. The bottom line is that mozilla makes a random choice which turns out to be the wrong one. There is no way for the user to override it. Mozilla will always look ugly on some systems until this problem is fixed. I would be happy to discuss this over email. --Jim Amundson
rendering gtk problem so reassigning to Kevin
Assignee: troy → kmcclusk
Reassigning to waqar.
Assignee: kmcclusk → waqar
CC'ing pavlov and blizzard
I have two additional comments: 1) I think it is possible that bug 27378 arises from the problem I described in this bug report. 2) FYI: ISO-8859-9 is Turkish. Mozilla believes my courier fonts should be Turkish...
Re-assigning to myself, since it's in my code.
Assignee: waqar → erik
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thanks for a very thorough report Jim, and sorry for the inconvenience.
Status: NEW → ASSIGNED
Target Milestone: M15
Target Milestone: M15 → M16
Fixed by processing charsets in the order that XListFonts returns them in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking verified oper last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.