Closed
Bug 64231
Opened 24 years ago
Closed 24 years ago
The Edit|Preferences|Fonts has problem with display some foreign fonts.
Categories
(Core :: Internationalization, defect, P2)
Core
Internationalization
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: amyy, Assigned: jbetak)
Details
(Keywords: intl)
Attachments
(8 files)
133.30 KB,
image/jpeg
|
Details | |
75.51 KB,
image/jpeg
|
Details | |
3.49 KB,
patch
|
Details | Diff | Splinter Review | |
4.16 KB,
patch
|
Details | Diff | Splinter Review | |
5.82 KB,
patch
|
Details | Diff | Splinter Review | |
5.82 KB,
patch
|
Details | Diff | Splinter Review | |
6.39 KB,
patch
|
Details | Diff | Splinter Review | |
6.06 KB,
patch
|
Details | Diff | Splinter Review |
The Edit|Preferences|Fonts has problem with display some foreign fonts.
Tested on 01-03-2001 Mtrunk build/Mac 9.0:
1. Very interesting thing is, the first time you choose most languages except
Japanese, Western, Unicode font(e.g. Korean, Chinese , Central European.. etc.)
when you go to Edit|Preferences|Fonts are different than after you click on
other languages without problems(Japanese, Unicode...) and then choose those
language fonts.
a. Korean: First time works fine, however "Serif" default value shows blank if
you visit some other language font like Japanese first, but you still can choose
the font by the drop down list.
b. Other languages( Chinese, Central European, Cyrillic... etc.): First time the
2 font "Size" areas are disable, however, if you Choose Japanese or Unicode etc.
which are no problem with diaplay all area of fonts, the default value of either
"Sans Serif" or "Serif" or both shows blank. Like Korean, you still can choose
the font by select from drop down menu.
Reporter | ||
Comment 1•24 years ago
|
||
Change QA contact and add keywords.
Comment 2•24 years ago
|
||
add ben and matt to the cc list.
ylong, can you open Task:Tools:JavaScript Console and attach any warning / error
repored during that testing ?
set it as P3 moz0.9.1
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
Reporter | ||
Comment 3•24 years ago
|
||
I didn't see any warning/error in Task:Tools:JavaScript Console during this
test.
Reporter | ||
Comment 4•24 years ago
|
||
Reporter | ||
Comment 5•24 years ago
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 6•24 years ago
|
||
I tried manually edit the prefs.js file so that the fonts for TW, KO, CN
have entry. Mozilla wiped out those entries upon launch. No workaround yet.
Updated•24 years ago
|
Priority: P3 → P2
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9
Assignee | ||
Comment 9•24 years ago
|
||
changing platform to "All".
This problem results from the fact that in absence of a preset font face
preference, we are trying to default to the last selected face. If the last
selected item happens to be from a different language group (e.g. Western vs.
Japanese), the assignment will fail when the face doesn't exist in the current
language froup. This then results in the reported JS error.
Suggested remedy: clear the previous selection and default to the first list
item unless a font face preference has been already established.
OS: Mac System 9.x → All
Comment 10•24 years ago
|
||
Why fonts of outside the language group can be selected?
Isn't the UI filtering out faces which does not belong to the language?
Assignee | ||
Comment 11•24 years ago
|
||
>Isn't the UI filtering out faces which does not belong to the language?
Clarifying: the last-selected item is cached regardless of its language group
membership... If the cached face doesn't exist in the new language group and
there is no user preference for it yet, it results in this problem.
As discussed with Naoki, a possible temporary workaround is to select a face
from the dropdown and come back a second time to adjust the face size.
Assignee | ||
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
r=nhotta
Comment 14•24 years ago
|
||
sr=alecf
(in the future, please use cvs diff -u for the benefit of the reviewers!)
Assignee | ||
Comment 15•24 years ago
|
||
works as of 04/05/2001
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 16•24 years ago
|
||
Fixed verified on 04-05-2001 Mac trunk build.
Status: RESOLVED → VERIFIED
Updated•24 years ago
|
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 17•24 years ago
|
||
Reopening.
I am not sure how it is supposed to work.
Here is what I see in 2001040911 Mac trunk.
Preferences|Fonts
Under Western, I can see Times for Serif, Helvetica for San-Serif and Courier
for fixed width.
When I switch to Japanese, HeiseiMincho, HeiseiGothic, and Osaka-monospace,
respectively.
Then I switch to either Traditional Chinese, Simplified Chinese, or Korean.
There is blank looking tab or sometimes "No fonts available" for Serif,
HeiseiGothic for San-Serif, and Osaka-monospace for fixed-width.
Now I click the tabs and set all of them to Beijin, Taipei, or Seoul and switch
back to Japanese.
Here What I see is blank tab for Serif, Beijin (Taipei, or Seoul if that has
been selected immediately before switching) for San-Serif and Fixed-width.
If you switch to Western first and then to either Traditional Chinese,
Simplified Chinese, or Korean, there is no font for 2-byte language in the list.
Assignee | ||
Comment 18•24 years ago
|
||
spam: attempting to reproduce... Yuying?
Reporter | ||
Comment 19•24 years ago
|
||
OK, here is what's the problem:
1. If you have all default font for all lauguages, then you won't see this
problem - that's why when I mark it as verified on Mac.
2. I change platform to "All" - cause it is not only on Mac.
3. If there are some language's font is not avalible at first time, e.g.
Traditional Chinese, then the default font for "Serif" will greyed out - not
avalible at the first time, then you go back to those languages that don't have
problem at first visiting time, e.g. Japanese or Western... etc. you will
"Serif" will display incorrectly(blank). It might because after the "Not
avalible" message stay there, so that confuse other language pick up the fonts.
Hardware: Macintosh → All
Assignee | ||
Comment 20•24 years ago
|
||
accepting: the <not available> list item breaks the default value
functionality...
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 21•24 years ago
|
||
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
Assignee | ||
Comment 24•24 years ago
|
||
adding alecf
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
review still pending for the latest patch - moving to 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 27•24 years ago
|
||
Jurai,
I'm reworking the font enumerator api which will affect this code.
Could you check with me before checking anything in?
thanks
Comment 28•24 years ago
|
||
oops:
s/Jurai/Juraj/
Assignee | ||
Comment 29•24 years ago
|
||
an attempt to "untangle" this patch somewhat. Brian, Naoki - thanks for going
over this change!
Assignee | ||
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
r=nhotta
Comment 32•24 years ago
|
||
sr=alecf
(also, diff -u -w -b will eliminate even more whitespace changes)
Assignee | ||
Comment 33•24 years ago
|
||
thanks everyone! One more off the list...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 34•24 years ago
|
||
> Suggested remedy: clear the previous selection and default to the first list
> item unless a font face preference has been already established.
Is this what you are doing?
What happens if a user selects a new font from halfway down the list on Western,
then changes to Korean and back to Western? Does the pref panel remember the new
font he selected?
The fonts panel needs to keep a matrix of encodings versus font types, both the
original values and the new values. Or something like that.
Note the work going on over in bug 28899 may have an effect on this.
Gerv
Assignee | ||
Comment 35•24 years ago
|
||
Gerv,
glad you asked. I just tried the suggest scenario in my local build and it
seems to work satisfactorily. My comment and the patch only pertain to the
initialization values. It seems that the code was less than smart about
selecting defaults and the change should have no effect on the persistence of
user-selected pref values. I believe they are cached in the languageData array
and I haven't really touched that.
BTW would you know about any performance-optimization work being done on this
pref? We could fully e.g. populate the drop-down lists only when clicked and in
addition avoid multiple font enumerator calls. There is also bug 33340 to keep
in mind. I'm very keen on getting work on that started soon. I know Matt Fisher
and Brian Stell are currently doing some font prefs work. Would you know of
anyone else?
J.
You need to log in
before you can comment on or make changes to this bug.
Description
•