Solaris XListFonts reports invalid (no glyph) fonts

Assigned to



17 years ago
9 years ago


(Reporter: kill this account, Assigned: Masaki Katakai)




Firefox Tracking Flags

(Not tracked)



(3 attachments)



17 years ago
Solaris fonts.alias includes font aliases for cns11643 planes 4-16 when in fact 
these fonts do not have any glyphs.

Comment 1

17 years ago
Actually, with the changes of bug 71197 and disabling cns-4-16 entries
in gfx/gtk, whole GBK characters on that page are displayed properly.

It is worth thinking modify the gfx/gtk codes only for Sun's Netscape.
Yes, the side-affect would happen when Mozilla is running on Solaris
mechine and display to the other host's display which has proper cns 4-16 fonts.
But I don't think it's serious.

Comment 2

17 years ago
P1 bug for Sun;  setting Priority = P1;  adding intl, nsbeta1 keywords
Keywords: intl, nsbeta1
Priority: -- → P1

Comment 3

17 years ago
Masaki- I think Sun should also consider remove these "fake" fonts.

Comment 4

17 years ago
Yes, but as you know, it would be very difficult to remove the fonts
from Solaris platform. We will need to provide OS patches for existing
Solaris 7, 8 and their update (patch) releases also will need to do
integration for the next version of Solaris.

We're going to pre-define

 gb2312 for zh-CN
 big5 for zh-TW

for our product, so actually this problem would often happen in zh-CN,
but If we *could* fix the bug 69139 (fallback to language fonts),
we can solve this problem also because gtk-0 fonts exist in most case.
The exact problem is fallback happens in random to cns fonts, not to
gbk-0 fonts first.


Comment 5

17 years ago
Please be careful here:

Bug 69139 helps the code look for glyphs in the best place first.

It does not guarantee the code wouldn't find the fake fonts.

It will solve the current symptoms we see but please be forewarned that having 
fake fonts could well cause problems in other areas.

Comment 6

17 years ago
I started checking this again with the temp patch for bug 67732 and
bug 73697. Even with the dummy fonts, the original problem bug 66744
(missing some GBK characters) is working fine by the patch. The font
fallback can pick up the proper language font if gbk font exists.
I believe we can solve most cases by the patch.

However, we're seeing the problem when we browse UTF-8 document on
zh_TW locale, which means when "zh-TW" is used as language group
and non chinese glyphs need to be displayed. cns-4-16 fonts are
picked up for "zh-TW" and Mozilla are trying to draw the code points
by the fonts.

Yes, the right fix is to provide cns-4-16 glyphs in Solaris. But
it's very difficult in short time. How about the following,

 disable cns-4-16 in Mozilla codes

Actually, it would cause the problem when cns-4-16 fonts become available,
user would try to install cns-4-16 fonts on Solaris, also when Mozilla
is displayed on other display which has cns-4-16 fonts. However, I don't
thik these cases happen often. And, yes, the glyphs will be displayed
by the fallbacks if available.

So, "disabling cns-4-16 in Mozilla" is the best solution
for now and I understand it would not cause big problem
for users. Any comments?

Btw, is "#ifndef sun" in *Mozilla* tree acceptable
for this fix? Frank, Brian?

#ifndef sun
  { "cns11643-4",         &FEG_ZHTW, &CNS116434     },
  { "cns11643-5",         &FEG_ZHTW, &CNS116435     },
  { "cns11643-6",         &FEG_ZHTW, &CNS116436     },
  { "cns11643-7",         &FEG_ZHTW, &CNS116437     },


Comment 7

17 years ago
Changing QA contact to
QA Contact: andreasb → katakai

Comment 8

17 years ago
Linda - Changing to nsbeta1-. This one does not meet beta stopper guidelines, 
but it maybe be a stopper for Sun to distribute or participate in beta program. 
Pls let us know, if we should escalate.
Keywords: nsbeta1 → nsbeta1-

Comment 9

17 years ago
Created attachment 34907 [details] [diff] [review]
using ifndef sun

Comment 10

17 years ago
I've just put simple patch. Please evaluate. As I mentioned
in comments, disabling cns 4-7 would not cause serious problem
even when the changes in Mozilla tree.

Comment 11

17 years ago
Katakai, could you describe what Sun is doing to actually fix these fonts?

I do not want to put this hack in mozilla:

  1) it sets a very bad precedent (hacking mozilla to workaround OS problems)

  2) it reduces the pressure on the OS vendor to fix their problem

As an alternate, I would consider a change (read hack) to the mozilla install 
script that removed these invalid fonts.

Comment 12

17 years ago
We can fix the problem in next release, but the problem has been in all of the
previous releases, so I think a workaround in the new released Mozilla will be a
better solution.

Comment 13

17 years ago
Again, I would consider a change (read hack) to the mozilla *install*
script that removed these invalid fonts.

Comment 14

17 years ago
Thanks Brian@Netscape, I completely agree with the following,

> it reduces the pressure on the OS vendor to fix their problem

OK, I'll close this as WONTFIX for Mozilla side.

Brian@Sun, can you provide the instruction how users remove
the cns4-7 fonts on Solaris? Those should be described in
release notes for both Mozilla and our product.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 15

17 years ago
Good news. I checked this patch of bug 81528 for this problem.
I found it works. The current patch is checking
only for jisx201 but I believe it will be generic, which
means this problem can be fixed in Mozilla side.

I reopened this bug.
Resolution: WONTFIX → ---

Comment 16

17 years ago
fixed as part of bug 81528
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
verified the fix by debugging messages.

Those fonts are not handled as "invalid" and will not be used.

  { "cns11643-4",         &FEG_ZHTW, &CNS116434     },
  { "cns11643-5",         &FEG_ZHTW, &CNS116435     },
  { "cns11643-6",         &FEG_ZHTW, &CNS116436     },
  { "cns11643-7",         &FEG_ZHTW, &CNS116437     },


Comment 18

17 years ago
> ------- Additional Comments From Masaki Katakai 2001-06-14 23:15 -------
> Those fonts are not handled as "invalid" and will not be used.

Does this statement mean the fonts were correctly detected as empty/invalid
and hence are not used?

Comment 19

17 years ago
"not" isn't correct. I had to say "fonts are handled as "invalid"


Comment 20

17 years ago
my my linux system, when I set NS_FONT_DEBUG=1
I see that these fonts are marked as invalid when they do have glyphs

invalid font "-misc-fixed-medium-r-normal--16-*-*-*-c-*-jisx0201.1976-0",
invalid font "-misc-fixed-medium-r-normal--13-*-*-*-c-*-jisx0201.1976-0",
invalid font "-sony-fixed-medium-r-normal--13-*-*-*-c-*-jisx0201.1976-0", 
Resolution: FIXED → ---

Comment 21

17 years ago
Created attachment 40554 [details] [diff] [review]
patch; actually check that the glyphs have bits set (has debug prints)

Comment 22

17 years ago
Created attachment 40578 [details] [diff] [review]
patch; just check if there is more than one char in the char range

Comment 23

17 years ago
Brian, the patch can work for Solaris cns 4-7 fonts, good.

But do you remember invalid font on Redhat6.2 Japanese? 

invalid font "-wadalab-gothic-medium-r-normal--13-*-0-0-c-*-jisx0201.1976-0",
nsFontMetricsGTK.cpp 1893

is found as valid font with the patch. So ascii glyphs are blank.


Comment 24

17 years ago
Katakai: thanks for pointing that out. I had not tested
QA Contact: masaki.katakai → i18n
You need to log in before you can comment on or make changes to this bug.