71199 - Solaris XListFonts reports invalid (no glyph) fonts

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect, P5)

Description

[kill this account]

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

Comment 1

[Masaki Katakai]

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

[Linda Baliman]

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

Comment 3

[Frank Tang]

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

Comment 4

[Masaki Katakai]

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

[kill this account]

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

[Masaki Katakai]

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

Comment 7

[Andreas Becker]

Changing QA contact to [e-mail].

Comment 8

[Jaime Rodriguez, Jr.]

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.

Comment 9

[Masaki Katakai]

Attachment: using ifndef sun

Comment 10

[Masaki Katakai]

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

[kill this account]

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

[Brian Yuan]

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

[kill this account]

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

Comment 14

[Masaki Katakai]

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.

Comment 15

[Masaki Katakai]

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.

Comment 16

[kill this account]

fixed as part of bug 81528

Comment 17

[Masaki Katakai]

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

[kill this account]

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

[Masaki Katakai]

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

Comment 20

[kill this account]

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

Comment 21

[kill this account]

Attachment: patch; actually check that the glyphs have bits set (has debug prints)

Comment 22

[kill this account]

Attachment: patch; just check if there is more than one char in the char range

Comment 23

[Masaki Katakai]

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

[kill this account]

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

Comment 25

[Sylvestre Ledru [:Sylvestre]]

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.

Comment 26

[Henri Sivonen (:hsivonen)]

We no longer support non-TTF/OTF fonts.