Closed
Bug 30856
Opened 25 years ago
Closed 25 years ago
The charset handling in nsFontMetricsGTK.cpp is broken.
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
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
Comment 3•25 years ago
|
||
CC'ing pavlov and blizzard
Reporter | ||
Comment 4•25 years ago
|
||
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...
Assignee | ||
Comment 5•25 years ago
|
||
Re-assigning to myself, since it's in my code.
Assignee: waqar → erik
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 6•25 years ago
|
||
Thanks for a very thorough report Jim, and sorry for the inconvenience.
Status: NEW → ASSIGNED
Target Milestone: M15
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15 → M16
Assignee | ||
Comment 7•25 years ago
|
||
Fixed by processing charsets in the order that XListFonts returns them in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•