91145 - bold and italics do not work on ASCII strings when editing a CJK page

Status: VERIFIED WONTFIX

(Core :: Internationalization, defect)

Description

[Tracy Walker [:tracy]]

seen on recent linux branch builds including linux 2001-07-17-04-0.9.2

steps to reproduce:

-send a japanese encoded mail message to yourself (html)
-reply to that message
-attempt to bold or italicize some text; japanese or english, it makes no 
differnece

note: I have been seeing this for several days.  It wasn't until today that I 
was able to pinpoint steps to reproduce why I was seeing some text bold and 
italic in my mail tests just fine and others not. It is a linux branch bug only.

Comment 1

[ji]

It happens to Chinese, Korean and UTF-8 mail as well.
It's a regression from 6.01, and it's reproduciable with 6.1 beta1 build.
New mail compose window doesn't have this problem.

Comment 2

[nhottanscp]

I cannot reproduce. I used 7/12 branch build win32.

Comment 3

[ji]

Noaki, this is a linux specific bug.

Comment 4

[nhottanscp]

Can this also happen on HTML composer?

Comment 5

[ji]

This problem also occurs when editing a Japanese web page.
To see it,
1. Go to http://home.netscape.com/ja
2. Select File | Edit Page
3. Enter ascii chars, and highlight the string, click on the bold or italic
icon. You'll see the highlited string doesn't change to the style you desired.

Comment 6

[nhottanscp]

Reassign to editor group.

Comment 7

[ji]

Same problem seen when editing a Chinese or Korean web page.
Modified the summary accordingly.
The bold and italic problem for Japanese chars are reported in bug 15611.

Comment 8

[nhottanscp]

Reassign to bstell.

Comment 9

[Yuying Long]

I'm not familiar with Mail, but for Browser and Editor:
If you go Netscape homepage of Japan, Korean, Chinese in browser, you will find 
there are no bold face been displayed in those pages. (Note bug 15611 still 
open)

I belive I have discussed this issue with Frank before, and I was tolded by him:
Unix has limitation for display bold and italic even in N4.7.

Comment 10

[ji]

We do have limitations for bold and italic display of Japanese characters. (bug 
115611)
This bug is about bold and italic display for ASCII strings in editing window 
for CJK pages. And this is a repression from 6.01.

Comment 11

[Yuying Long]

Sorry, I didn't realize this is for ASCII string - I kept thinking it's 
non-ASCII string.

Comment 12

[kill this account]

In the past mozilla ignored all the ascii glyphs in Japanese fonts along
with a variety of other characters like 'smart-quotes'. This was done because
Japanese characters are often quite a bit larger than Western characters and
if a Japanese 'smart-quote' was used as a fill-in glyph in a western document
it was much larger than the surrounding glyphs and this was felt to look poor.

The patch for bug 33162 re-enabled all the glyphs in Japanese fonts. What you
are seeing is Japanese glyphs being used for Japanese documents. Because the
Japanese fonts do not have bold/italic we do not see those.

Comment 13

[kill this account]

humm...

I think that the previous statement was incorrect.

Comment 14

[kill this account]

It looks like it is displaying a Japanese font.

All 8 weights for all 3 styles appear to be the same value. Hence, no visual
difference between normal/italic/bold

Naoki: were there any recent changes to the lang group or encoding of the
mail reply edit area?

Comment 15

[kill this account]

Can IQA determine when this started?

Thanks

Comment 16

[nhottanscp]

I think no change for lang group or encoding related change for mail reply since
NS6.0.
Xianglan, is the HTML composer problem also a regression from 6.01?

Comment 17

[ji]

Yes.
This bug doesn't exist on 2001-05-05-0.9 build. So it was introduced between 
05/05 and 06/07.

Comment 18

[Yuying Long]

If in that period, I don't know if there is anything related to bug 81528?

Comment 19

[kill this account]

I do not know if it is a font issue or an encoding issue.

I was wondering: is it possible to narrow down the time frame to a day or two?

If we could I could then look at all the changes that went in.

Comment 20

[ji]

Unfortunately, there are no such old builds on sweetlou.

Comment 21

[Masaki Katakai]

I understand this is dup of bug 15611, which is Linux limitation.

Now we use jisx201 as ascii parts by changings of bug 67732 and there are
not enough jisx201 ascii fonts, bold and italic style on Linux, especially
RedHat 6.2J. We should test this on Linux distribution which provides more
variable fonts for Japanese, I think the latest version of Kondara and Vine
are good, or RedHat6.2J + bold japanese fonts.

For Solaris, bold fonts are available for japnaese. I'll attach the screen
shot. If we could configure font setting properly, yes, the bold fonts can
be used.

Comment 22

[Masaki Katakai]

Attachment: japanese bold fonts can be used on Solaris

Comment 23

[Tracy Walker [:tracy]]

this is working again on linux commercial build 2001-07-19-04-0.9.2

replying to a japanese encoded message allows me to bold and highlight ascii 
text.

Comment 24

[Tracy Walker [:tracy]]

whoa...wait a second...this works if and only if the font size is "+" once or 
three times from the orignal size. at original size or "+" twice it does not 
work.

Comment 25

[kill this account]

I suspect that what is happening here is similar to bug 94327:

1) the font system sorts all the fonts into nodes where a node holds all
   the fonts with the same foundry-family-registry-encoding. The node holds
   all sizes for all variations (3 * 8 * 8 = 192 variations)
   3 slants (eg: normal/italic)
   8 weights (eg: light/regular/bold)
   8 widths (eg: narrow/medium/wide)

2) the font system finds the the first node that "could" have a font with the 
   character

3) There were only a handful of variations actually found so most of the
   spots in the node are actually empty. The code "fills" in the missing
   spots by finding the nearest real font. Since there are only a few
   actual fonts some of the "filled in" fonts get "less than perfect" fonts

If someone thinks this is not a dup please reopen.


*** This bug has been marked as a duplicate of 94327 ***

Comment 26

[ji]

Marked it as verified. Will check this once bug 94327 is fixed.

Comment 27

[Tracy Walker [:tracy]]

bug 94327 has been marked fixed and this issue still exist on linux...

...reopening

Comment 28

[ji]

Hmm... I don't see this on 12-17-06-trunk linux build.

Comment 29

[Frank Tang]

it may depend on what kind of font available on the system. 

Comment 30

[Yuying Long]

Yes, we noticed the diference between Tracy's system and Xianglan's system:
Tracy's: RH6.2-US + language pack.
Xianglan's: RH7.1-JA.

Comment 31

[ji]

QA contact to Yuying. Thanks.

Comment 32

[kill this account]

-> ftang

Comment 33

[Frank Tang]

still an issue for RedHat 6, but it seems no longer an issue for RedHat 7.
mark this future

Comment 34

[kill this account]

this bug seems related to bug 120913

Comment 35

[Yuying Long]

Can reproduce this on RH7.2 with Korean and Chinese(SC and TC) characters but
not Japanese.

Comment 36

[Tracy Walker [:tracy]]

Frank,

I recently noticed that with redhat 6.2 the encoding for the bold and italics is
actually getting put in the document (ie. compose an email with japanese, use
bold and italics. send the mail.  Read it from a windows or mac machine and the
bold and italics are rendered.

This bug has been around for ages.  Come resource refresh, I will probably be
upgrading to redhat 7.x, at which time I will no longer see this in
smoketesting. Is Future status of this bug necessary?  I'd imagine most of the
redhat community has already upgraded to 7.x.  Perhaps status Won't Fix is in
order for this bug?

Comment 37

[Frank Tang]

mark it as wontfix. if people install the bold font, they won't see this
problem. we may fix it by our code to fake one bold font. But the ROI seems
quite low. Also, this won't be a issue once we have the truetype font there. 

Comment 38

[Tracy Walker [:tracy]]

marking verified