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.

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).

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?

> 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.

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

reassign to myself. Which fonts have those glyph?

We probably need to look into the 'OS/2' table of the TrueType/OpenType.

or we just fake it to let any MacRoman font also available on Cyrillic/CentralEurope/Baltic/Turkish/Greek.

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.

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.

looks like a isolated improvement, consider for m94

Is the 0.9.4 milestone realistic? We are branching on Friday.

move to m0.9.5

move to m0.9.7

move to 0.9.8

mass move unimportant m9.8 bug to m9.9 for now.

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.

give to nhotta

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.

nsbeta1+ per triage meeting

reassign to ftang

reassign to ftang

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.

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.

+ PRUint32 mUsb[4]; + PRUint32 mNoUsb[4]; Could you explain about those? Are those related to TrueType table? What does the nuber 4 mean?

+ 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.

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

nhotta, please r=

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.

nhotta, please r=

+ 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 on attachment 73611 [details] [diff] [review] v4 of patch r=nhotta

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.

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

P4

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

> 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?

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.

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.

> 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.

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+.

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.

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....

Exactly what Bug 157967 is about.

FIXED in bug 120401, but we still needs ATSUI for better rendering.

FIXED in bug 120401, but we still need ATSUI for better rendering.