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

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.

P1 bug for Sun; setting Priority = P1; adding intl, nsbeta1 keywords

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

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.

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.

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 }, #endif

Changing QA contact to katakai@japan.sun.com.

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.

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.

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.

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.

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

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.

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.

fixed as part of bug 81528

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 },

> ------- 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?

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

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",

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.

Katakai: thanks for pointing that out. I had not tested http://bugzilla.mozilla.org/show_bug.cgi?id=81528

Decreasing the priority as no update for the last 2 years on this bug. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage about the priority meaning.