Last Comment Bug 95978 - Can't change Central European, Baltic, Cyrillic and Greek font prefs
: Can't change Central European, Baltic, Cyrillic and Greek font prefs
Status: RESOLVED FIXED
MacOS X,adt3
: intl
Product: Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: PowerPC Mac OS X
: P4 normal with 2 votes (vote)
: mozilla1.2beta
Assigned To: Frank Tang
: Yuying Long
: Makoto Kato [:m_kato]
Mentors:
http://www.unics.uni-hannover.de/nhtc...
Depends on: 120401
Blocks: 103669
  Show dependency treegraph
 
Reported: 2001-08-19 06:48 PDT by Henri Sivonen (:hsivonen)
Modified: 2004-08-09 19:51 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch v1 (6.70 KB, patch)
2002-03-07 09:16 PST, Frank Tang
no flags Details | Diff | Splinter Review
patch v2, add comment about OS/2 table (6.80 KB, patch)
2002-03-07 17:21 PST, Frank Tang
no flags Details | Diff | Splinter Review
v3 patch (6.82 KB, patch)
2002-03-11 14:44 PST, Frank Tang
no flags Details | Diff | Splinter Review
v4 of patch (6.97 KB, patch)
2002-03-11 18:16 PST, Frank Tang
nhottanscp: review+
Details | Diff | Splinter Review

Description Henri Sivonen (:hsivonen) 2001-08-19 06:48:24 PDT
Build ID: 2001081505 FizzillaCFM

The page http://www.unics.uni-hannover.de/nhtcapri/central_european.html2 uses
the Latin-2 encoding. The text is tiny, but it should be the normal size.
Comment 1 Jacek Piskozub 2001-08-19 20:27:22 PDT
It means you probably have a wrong font (or jus font size) chosen for the
Central European codepages. Go to Properties -> Appearance -> Fonts and change
the settings for "Central European". It should solve your problem (if you have
the right fonts installed).
Comment 2 Henri Sivonen (:hsivonen) 2001-08-20 09:35:38 PDT
Mac OS X comes with adequate fonts by default. Even though the text is tiny, I
can see the glyphs are correct. Also, if I copy the text to TextEdit, I can
verify that I have adequate fonts. However, in the Mozilla font prefs, the
Central European prefs are disabled.

What's the point in having a separate font size pref for Central European
anyway? If I like to read Western European at 18px, why would I want to read
Central European (or Cyrillic or Greek) at a different size?
Comment 3 Jacek Piskozub 2001-08-20 09:48:11 PDT
> What's the point in having a separate font size pref for Central European
> anyway? If I like to read Western European at 18px, why would I want to read
> Central European (or Cyrillic or Greek) at a different size?

Because you may use different fonts for different encodings. And the same
"perceived" look for both may require different pixel size. I've seen this
happen under Linux. 

Comment 4 Henri Sivonen (:hsivonen) 2001-08-20 09:52:56 PDT
OK. I checked my prefs.js. The Central European size was set to 8px.

Morphing bug to reflect the real issue and starting discussion in n.p.m.ui.

Steps to reproduce:
1) Run Mozilla on Mac OS X
2) Take a look at the Central European, Baltic, Cyrillic and Greek font prefs

Actual results:
Can't edit the prefs.

Expected results:
Expected to be able to adjust the prefs, since Mac OS X comes with fonts with
glyphs for displaying:
* the Russian subset of Cyrillic
* basic Greek (without diacritics)
* Central European* Baltic
Comment 5 Frank Tang 2001-08-20 17:58:05 PDT
reassign to myself. 
Which fonts have those glyph?
Comment 6 Frank Tang 2001-08-20 17:58:59 PDT
We probably need to look into the 'OS/2' table of the TrueType/OpenType.
Comment 7 Frank Tang 2001-08-20 18:00:19 PDT
or we just fake it to let any MacRoman font also available on
Cyrillic/CentralEurope/Baltic/Turkish/Greek.
Comment 8 Henri Sivonen (:hsivonen) 2001-08-21 02:26:02 PDT
Times, Courier, Helvetica, Geneva, Apple Chancery, Charcoal, Chicago, Textile,
Sand, Skia and Palatino support Western European (including Icelandic), Baltic,
Central European, South European (Maltese, Esperanto) and Turkish. (Basically
Latin-you-name-it.)

I suggest these defaults for all Latin variants:
Serif: Times
Sans-serif: Helvetica
Monospaced: Courier
Cursive: Apple Chancery
Fantasy: Sand

Hiragino Kaku Gothic Pro and Hiragino Maru Gothic Pro support extended Greek and
the Russian subset of Cyrillic

Hiragino Mincho Pro supports basic Greek and the Russian subset of Cyrillic.
Comment 9 Henri Sivonen (:hsivonen) 2001-08-21 07:01:50 PDT
Oops. In the Hiragino family, the width Greek and Cyrillic glyphs is tuned for
mixing with Han/Kanji blocks making the Hiragino fonts unusable for pages where
Greek or Cyrillic is the dominant script.

Lucida Grande has variable-width glyphs for Cyrillic & Greek.
Comment 10 Frank Tang 2001-08-21 13:38:31 PDT
looks like a isolated improvement, consider for m94
Comment 11 Hong Kwon 2001-08-29 13:15:53 PDT
Is the 0.9.4 milestone realistic?  We are branching on Friday.
Comment 12 Frank Tang 2001-08-31 10:57:01 PDT
move to m0.9.5
Comment 13 Frank Tang 2001-10-08 11:42:30 PDT
move to m0.9.7
Comment 14 nhottanscp 2001-11-20 13:48:54 PST
move to 0.9.8
Comment 15 Frank Tang 2002-01-16 17:53:32 PST
mass move unimportant m9.8 bug to m9.9 for now. 
Comment 16 Greg K. 2002-01-20 10:39:59 PST
Note also that Unicode fonts that may cover the character range of the encoding
in question are not selectable as the font for that range in Fizzilla.
Comment 17 Frank Tang 2002-02-12 19:58:05 PST
give to nhotta
Comment 18 nhottanscp 2002-02-14 11:09:48 PST
I tried IE and it has the same problem, no default selection for Central
European. But the list is not disabled so the user can select something.
I think we can list all the fonts instead of disabling the list, let the user
choose whatever appropriate.
Comment 19 Frank Tang 2002-02-15 17:03:05 PST
nsbeta1+ per triage meeting 
Comment 20 Frank Tang 2002-03-05 14:33:12 PST
reassign to ftang
Comment 21 Frank Tang 2002-03-05 14:33:40 PST
reassign to ftang
Comment 22 Frank Tang 2002-03-07 09:16:43 PST
Created attachment 72987 [details] [diff] [review]
patch v1

we have the following issue:
1. we put the FMFontFamily into the hash for MacOS X but we get it and cast it
as FondID in here. So we need to change that, we need to cast to FMFontFamily
for MacOS X to match the other place
2. The current code only list the font which belong to a script code. We need
to check the OS/2 table to list all the font(but not CJK fonts) which have the
glyph for some subrange.
Comment 23 Frank Tang 2002-03-07 14:24:39 PST
two issue.
1.  currently, in the Carbon build (see
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#793 )

nsDeviceContextMac :: InitFontInfoList()

we put a FMFontFamily into the hash but in the (see
http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#1099 )


1099 EnumerateFont(nsHashKey *aKey, void *aData, void* closure)

we cast the hash data into a short which mean FontID and then call
::FontToScript (fontID) to get the script code. 

1106 short fondID = (short) aData;
1107 ScriptCode script = ::FontToScript(fondID);
1108 if(script == info->mScript) 

This is ok on non carbon build since we put the FontID into the hash, but for
carbon build, it is NOT a font ID but a FMFontFamily, therefore, we need to use
a different way to get the script

2. some font could be use for langgroup other than the script code , for
example,. some Latin font could be used for x-western, x-central-euro and tr
(turkish) . In that case, we need to access the OS/2 table in the TrueType font
to find out the hint. 
Comment 24 nhottanscp 2002-03-07 14:49:19 PST
+  PRUint32    mUsb[4];
+  PRUint32    mNoUsb[4];

Could you explain about those? Are those related to TrueType table? What does
the nuber 4 mean?
Comment 25 Frank Tang 2002-03-07 16:51:00 PST
+  PRUint32    mUsb[4];
mUsb[4] mean if those bits are on in ulCharRange[4] of the TrueType 'OS/2'
table, then we should list the font also

+  PRUint32    mNoUsb[4];
mNoUsb[4] mean if those bits are on in ulCharRange[4] of the TrueType 'OS/2'
table, then we should NOT list the font even there are other condiction said we
should list it. 

So, for example, for "el" (greek lang group), we turn on the Greek bits in the
mUsb[4] but also turn on the HanIdeograph bits in the mNoUsb[4] . In this way,
all the TrueType font have the Greek bit set but no HanIdeograph bit set will be
listed. We need the mNoUsb so we won't list Japanese or Chinese font (Usually
have wider Greek Glyph) for Greek but list Latin font for Greek. 
Comment 26 Frank Tang 2002-03-07 16:54:14 PST
see http://developer.apple.com/fonts/TTRefMan/RM06/Chap6OS2.html
for ulCharRange[4]
The meaning of bits could be found at 
http://www.microsoft.com/typography/otspec/os2.htm
Comment 27 Frank Tang 2002-03-07 17:21:04 PST
Created attachment 73097 [details] [diff] [review]
patch v2, add comment about OS/2 table
Comment 28 Frank Tang 2002-03-08 08:55:56 PST
nhotta, please r= 
Comment 29 Frank Tang 2002-03-11 09:02:11 PST
nhotta verbally ask me to put
+  // but if we match the following bits, we don't list it
+  // need this so we can exclude CJK fonts for Latin/Greek/Cyrillic
+  for (i=0; i<4; i++) {
+    if (signature.fsUsb[i] & info->mNoUsb[i]) 
+    {
+      match = PR_FALSE;
+      break;
+    }
+  }


into the previous else block. 
Comment 30 Frank Tang 2002-03-11 14:44:01 PST
Created attachment 73578 [details] [diff] [review]
v3 patch
Comment 31 Frank Tang 2002-03-11 14:45:44 PST
nhotta, please r= 
Comment 32 nhottanscp 2002-03-11 14:58:19 PST
+  PRUint32    mUsb[4];

Please add a comment to indicate this means bits 0-127.

+  FMFontStyle aStyle;
+  FMFont aFont;

Please change not to prepend 'a' for the local variables.

+    // get the encoding of the font
+    status = ::FMGetFontFamilyTextEncoding(aFontFamily, &fontEncoding);
+    // convert the encoding to script code
+    status = ::RevertTextEncodingToScriptInfo(fontEncoding,
&aSignature.scriptCode , nsnull, nsnull);

Please check an error after ::FMGetFontFamilyTextEncoding.
Comment 33 Frank Tang 2002-03-11 18:16:51 PST
Created attachment 73611 [details] [diff] [review]
v4 of patch
Comment 34 nhottanscp 2002-03-12 11:33:59 PST
Comment on attachment 73611 [details] [diff] [review]
v4 of patch

r=nhotta
Comment 35 Simon Fraser 2002-03-12 16:31:03 PST
I'm getting very worried about all the special-case font/i18n logic that seems
to be scattered throughout the Mac gfx code. This logic really doesn't live in
nsDeviceContextMac; some of it should be off in a class that deals with the
internals of TrueType fonts, so the reader can easily see what the main logical
decisions in the code are. As someone who is investing some amount of time in
text rendering code on Mac, I need this code to be clean and self-documenting.
Right now, it's scattered and confusing.
Comment 36 Frank Tang 2002-03-12 17:36:03 PST
ok. it make sense. Let's spin this bug into two issue. One is the fix the
straight forward FMFontFamily cast to fontID problem and other is to enhance the
Mac font pref code to look at the TrueType 'OS/2' table. Let's keep this one for
the enhancement and put the FMFontFamily casting bug into bug 130443
Comment 37 Frank Tang 2002-03-15 08:06:09 PST
P4 
Comment 38 Frank Tang 2002-04-01 11:38:21 PST
Impact Summery
Impact Platform: MacOS X only
Impact language users: Central European, Baltic, Cyrillic and Greek (30.7 M, 5.6%)
Probability of hitting the problem: low, depend on users action
Severity if hit the problem in the worst case: Users cannot set the font
preference but they can still see the text.
Way of recover after hit the problem: None
Risk of the fix: Low
Potential benefit of fix this problem: None
Comment 39 Henri Sivonen (:hsivonen) 2002-04-01 12:36:28 PST
> Risk of the fix: Low

One possible fix is letting the user pick any font--even those that are bad choices.

> Potential benefit of fix this problem: None

No benefit?
Comment 40 Frank Tang 2002-04-02 13:34:22 PST
I suggest we nsbeta1- this bug. Even we show all the font on the pref, the back
end code probably won't use the font we selected. It is not just a ui issue.


Comment 41 Frank Tang 2002-04-04 12:56:01 PST
nsbeta1- because we can see the page, 
also, I do see "Time CE" etc for Central European listed 
and if people have Cyrillic and Greek font, they will still be listed in font pref. 
Comment 42 Henri Sivonen (:hsivonen) 2002-04-05 14:15:48 PST
> also, I do see "Time CE" etc for Central European listed 

Times CE, Helvetica CE, etc. are no longer supposed to be required for Central
European chars. The character repertoire of those fonts has been merged into
Times, Helvetica, etc. but Mozilla doesn't allow the user to select those.
Comment 43 Socratis Kalogrianitis 2003-05-23 07:06:04 PDT
Anyone working on this one? It's targetted for 1.2 beta! It's been more than a
year since anyone has posted any comments... I still cannot change the Greek
fonts in Mozilla 1.4b or Camino 0.7+.
Comment 44 Jungshik Shin 2004-06-15 05:20:02 PDT
It seems like even v4 patch wouldn't be sufficient to deal with fonts with
various character repertoires (that go beyond 'traditional' repertoires
corresponding to Mac OS Classic 'script codes') because the patch still relies
on Mac OS Classic 'script' code.

As far as I can tell, barring the transition to ATSUI, we have to do something
similar to what's done in Gfx:Win. For instance, take a look at 

http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp#1590

Gfx:Xft (Gfx:Gtk-FT2) doesn't need to deal with the cmap table directly because
fontconfig (and freetype) offers a nice set of APIs. Unless there are similar
Carbon APIs, we have to either duplicate what's done in Gfx:Win (reading
different types of cmap tables in truetype fonts) or factor that out so that it
can be used by both Gfx:Win and Gfx:Mac.
Comment 45 Jungshik Shin 2004-06-15 06:06:42 PDT
Sorry for spamming.
Perhaps, I have to take back most of what I wrote in the previous comment.
gfx/src/mac/nsUnicodeRenderingToolkit.cpp has a bulk of code for rendering
'Unicode text' including MathML and even Korean fallback. It appears that it's
still a mix of 'script'-based code and 'ATSUI' and is not so easy to read.  The
cleanest way, I guess, is to go all the way to ATSUI APIs (because QuickDraw
APIs are based on 'Mac classic scripts'), but there's a lingering performance
concern... Hmm.. Safari must use it. Then, why not Mozilla? Well, there's an
impedance matching issue between Mozilla's layout engine  and ATSUI. Handing
over a small chunk of text at a time to ATSUI APIs instead of a paragraph (the
'natural' working unit of ATSUI) and repeating that many times would be a big
performance hit. I wish there were a set of low-level drawing/measuring APIs....
Comment 46 Greg K. 2004-06-15 11:15:07 PDT
Exactly what Bug 157967 is about.
Comment 47 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-08-09 19:49:00 PDT
FIXED in bug 120401, but we still needs ATSUI for better rendering.
Comment 48 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2004-08-09 19:49:18 PDT
FIXED in bug 120401, but we still need ATSUI for better rendering.

Note You need to log in before you can comment on or make changes to this bug.