Closed Bug 7521 Opened 25 years ago Closed 24 years ago

default Japanese font on Mac looks weired

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: momoi, Assigned: ftang)

References

Details

(Keywords: intl) 

** Observed with 6/2/99 Mac 5.0 build for M7 **

I first saw this bug using Mail HTML editor on Mac. It is also
observable on the Editor.

1. Bring up Mac HTML Editor or Mail Composer
2. Change encoding to a Japanese one.
3. Choose an area where the rest of characters are non-bold normal
   type. Now start inputting in Japanese Hiragana mode. You see that
   the input appears in bold type. When you commit Hiragana to the
   canvas, the characters remain in bold type.
4. Now try inputting another string but this time, convert Hiragana to
   Kanji. Then commit them to the canvas. You see that Kanji strings
   non-bold normal type style.

Both Hiragana and Katakana are commited in bold type while Kanji
input is commited in normal type. They should both use the same
style, i.e. whatever is the area is set for.
Assignee: ftang → tague
reassign this to tague, Tague, do you know what happened here ?
Assignee: tague → ftang
this is a drawing problem, it's *NOT* an IME problem.  this is how the
editor/gecko is drawing Japanese text insertions.  we currently aren't applying
any kind of clause or UI style information to IME text.  It is being interted as
an InsertText  -- same as english text.
Blocks: 7228
momoi, please clearify is this a drawing problem (it also show the same thing in
a web page in browser) or a IME related issue (only use bold in the IME text).
Frank, I think this is a general drawing problem.
It happens in the browser, too, but somewhat differently there because I think there are
many more characters you see in the browser window. In most cases, Katakana and Hiragana seem
to be in bold-type in the browser diaplay and so are some (but not many)  of the Chinese characters.

In the composer test I was conducting, I wasn't using that many Chinese characters for input
and probably did not see the bold-type Chinese characters because of that.

Are we still defaulting a Chinese font in Japanese display on Mac? Is there a bug for it?
Depends on: 5100
Depends on: 5099
Status: NEW → ASSIGNED
Summary: [PP]: Hiragana & Kanji JPN input uses different styles → Hiragana are not rendered by Japanese font, but Chinese font
Ok, change the summary from "[PP]: Hiragana & Kanji JPN input uses different
styles" to "Hiragana are not rendered by Japanese font, but Chinese font".

First of all, this is not a [PP] bug since it does not stop QA perform feature
testing. It is different between platforms, but it cannot be count as [PP] bug.

Second, it is a Mac only rendering problem. It depend on bug 5100,5099

peterl, please you currently mark 5099 and 5100 as M7. Is that what you can
commit ?
Target Milestone: M7
since peterl mark 5099, 5100 M7, I mark this M7 also
Summary: Hiragana are not rendered by Japanese font, but Chinese font → [PP]Hiragana are not rendered by Japanese font, but Chinese font
Summary: [PP]Hiragana are not rendered by Japanese font, but Chinese font → Hiragana are not rendered by Japanese font, but Chinese font
remove "[PP]" form summary
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
It should be fixed now. Please verify.
Status: RESOLVED → REOPENED
I tested this in 6-16-09 build.

Hiragana and Katakana I type in Editor are showed as bold.
After I chage Hiragana to Kanji, I still see the Kanji as Bold.
I reopen this.
Resolution: FIXED → ---
Target Milestone: M7 → M8
Not stopper, mark it M8
Status: REOPENED → ASSIGNED
I mark it M8.
Teruko, I am confused. The origional problem is "Both Hiragana and Katakana are
commited in bold type while Kanji input is commited in normal type."
Now you say "Hiragana and Katakana I type in Editor are showed as bold.
After I chage Hiragana to Kanji, I still see the Kanji as Bold."

Is it really Bold ? or different type face which looks bold to you. How about
HTML viewing, are they also use such BOLD type to show in browser ?
After Frank and I looked this, we found out that this is not BOLD type.
Somehow, times fonts are rendering to Osaka-Tohaba.
Target Milestone: M8 → M9
push to M9
So, what remains to be fixed in this bug?

It seems to be me that:

1. The candidate window now displays in normal style
   and seem like it's in 12 pt.
2. The text itself seems to be using a 16t. Osaka/Osaka[tohaba].

Is the size the only issue or is there a more general
font-mapping issue remaining? If so, what font do you
want it to be?
Target Milestone: M9 → M11
Is it Osaka or Osaka Tohaba now. I fix a bug which related to Mac font last
week. I am not sure that fix will also fix this problem or now. Momoi and
teruko, could you verify this again. Does it still use Osaka Tohaba on KanjiTalk
? What font it use in JLK ?
I tested this in 8-03-13 Mac build.  Osaka Tohaba 16 bit is used for Japanese input.
Since Editor is not stable, yet, I will try to test again this in the more stable build.
Summary: Hiragana are not rendered by Japanese font, but Chinese font → default Japanese font on Mac looks weired
Change the summary from "Hiragana are not rendered by Japanese font, but Chinese
font" to "default Japanese font on Mac looks weired".
Anyone know why the default font size is 16 pt, but not the old 12 pt ?
move to M12. No time to work on Mac for M11
Target Milestone: M11 → M12
Target Milestone: M12 → M13
I have partial fix in my tree which will let Mac listent to the pref for a
particular language. Erik have already check in the font size pref changes. We
should mark this bug close after
1) I check in my chnages
2) matt check in his font pref work
3) put a good size for Japanese in the macpref.js
Whiteboard: font name pref code fixed in local tree.
Whiteboard: font name pref code fixed in local tree.
check in the first part. Need to improve it to listen to the pref dynamically.
Also need to put default face into the pref.
Target Milestone: M13 → M14
Move it to M14.
Keywords: beta1
check in font face name into macpref.js
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
No longer depends on: 5100
I tested this in 2000021008 Mac build.  Osaka Tohaba 16 bit is still used for Japanese input.
Status: RESOLVED → REOPENED
Keywords: beta1
Resolution: FIXED → ---
Is this a problem on Japanese MacOS also ?
Status: REOPENED → ASSIGNED
I mark this depend on 27826.
Depends on: 27826
Move to M16
Target Milestone: M14 → M16
Bug 27826 is about the font prefs not reading/writing non-ASCII font names.
But if we directly edit (or create as default) the prefs file and add the
UTF-8 encoded font name, does this work?
It seems fixed. No problem in Mac 03-23-05-M15b1 bld.

Osaka Tohaba 16 bit is still used.  Tested 2000040509 Mac build. 
m17
Target Milestone: M16 → M17
reassign to garywade@desisoftsystems.com
Assignee: ftang → garywade
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Keywords: intl
Assignee: garywade → ftang
Status: ASSIGNED → NEW
to ftang.
The font size is 16 because the mozilla/modules/libpref/src/init/all.js said so
for Japanese font. I think it is currently using Osaka.
In this point, I am not sure what is the open issue in this bug. I will close
this bug for now. momoi - if you think we need to change the default size for
Japanese on Mac, please file a new bug. Thanks.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
Verified as Wonfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.