Closed Bug 91145 Opened 23 years ago Closed 22 years ago

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

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: tracy, Assigned: ftang)

Details

(Keywords: intl, platform-parity)

Attachments

(1 file)

japanese bold fonts can be used on Solaris
261.66 KB, image/jpeg
Details 
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.
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.
I cannot reproduce. I used 7/12 branch build win32.
Keywords: intl
Noaki, this is a linux specific bug.
Can this also happen on HTML composer?
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.
Product: MailNews → Browser
Assignee: nhotta → beppe
Component: Internationalization → Editor
Keywords: pp
Reassign to editor group.
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.
Keywords: pp
Summary: bold and italics do not work on reply to Japanese encoded message → bold and italics do not work on ASCII strings when editing a CJK page
Reassign to bstell.
Assignee: beppe → bstell
Keywords: pp
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.
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.
Sorry, I didn't realize this is for ASCII string - I kept thinking it's 
non-ASCII string.
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.
Status: NEW → ASSIGNED
humm...

I think that the previous statement was incorrect.
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?

Can IQA determine when this started?

Thanks

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?
Yes.
This bug doesn't exist on 2001-05-05-0.9 build. So it was introduced between 
05/05 and 06/07.
If in that period, I don't know if there is anything related to bug 81528?
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.

Unfortunately, there are no such old builds on sweetlou.
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.


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.

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.
Component: Editor → Internationalization
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 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Marked it as verified. Will check this once bug 94327 is fixed.
Status: RESOLVED → VERIFIED
bug 94327 has been marked fixed and this issue still exist on linux...

...reopening
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Hmm... I don't see this on 12-17-06-trunk linux build.
it may depend on what kind of font available on the system. 
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.
QA contact to Yuying. Thanks.
QA Contact: ji → ylong
-> ftang
Assignee: bstell → ftang
Status: REOPENED → NEW
Status: NEW → ASSIGNED
still an issue for RedHat 6, but it seems no longer an issue for RedHat 7.
mark this future
Target Milestone: --- → Future
this bug seems related to bug 120913
Can reproduce this on RH7.2 with Korean and Chinese(SC and TC) characters but
not Japanese.
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?
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WONTFIX
marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: