Closed
Bug 95978
Opened 23 years ago
Closed 20 years ago
Can't change Central European, Baltic, Cyrillic and Greek font prefs
Categories
(Core :: Internationalization, defect, P4)
Tracking
()
RESOLVED
FIXED
mozilla1.2beta
People
(Reporter: hsivonen, Assigned: ftang)
References
()
Details
(Keywords: intl, Whiteboard: MacOS X,adt3)
Attachments
(1 file, 3 obsolete files)
6.97 KB,
patch
|
nhottanscp
:
review+
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
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).
Reporter | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
> 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.
Reporter | ||
Comment 4•23 years ago
|
||
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
Summary: Tiny font on ISO-8859-2 page → Can't change Central European, Baltic, Cyrillic and Greek font prefs
Assignee | ||
Comment 5•23 years ago
|
||
reassign to myself. Which fonts have those glyph?
Assignee: yokoyama → ftang
Assignee | ||
Comment 6•23 years ago
|
||
We probably need to look into the 'OS/2' table of the TrueType/OpenType.
Assignee | ||
Comment 7•23 years ago
|
||
or we just fake it to let any MacRoman font also available on Cyrillic/CentralEurope/Baltic/Turkish/Greek.
Reporter | ||
Comment 8•23 years ago
|
||
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.
Reporter | ||
Comment 9•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
looks like a isolated improvement, consider for m94
Status: NEW → ASSIGNED
Whiteboard: MacOS X
Target Milestone: --- → mozilla0.9.4
Updated•23 years ago
|
QA Contact: andreasb → ylong
Comment 11•23 years ago
|
||
Is the 0.9.4 milestone realistic? We are branching on Friday.
Assignee | ||
Updated•23 years ago
|
Priority: -- → P3
Assignee | ||
Comment 13•23 years ago
|
||
move to m0.9.7
No longer blocks: 103669
Target Milestone: mozilla0.9.5 → mozilla0.9.7
Assignee | ||
Comment 15•23 years ago
|
||
mass move unimportant m9.8 bug to m9.9 for now.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 16•23 years ago
|
||
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.
Assignee | ||
Comment 17•22 years ago
|
||
give to nhotta
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 18•22 years ago
|
||
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.
Status: NEW → ASSIGNED
Assignee | ||
Comment 19•22 years ago
|
||
nsbeta1+ per triage meeting
Assignee | ||
Comment 20•22 years ago
|
||
reassign to ftang
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 22•22 years ago
|
||
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.
Assignee | ||
Comment 23•22 years ago
|
||
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•22 years ago
|
||
+ PRUint32 mUsb[4]; + PRUint32 mNoUsb[4]; Could you explain about those? Are those related to TrueType table? What does the nuber 4 mean?
Assignee | ||
Comment 25•22 years ago
|
||
+ 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.
Assignee | ||
Comment 26•22 years ago
|
||
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
Assignee | ||
Updated•22 years ago
|
Attachment #72987 -
Attachment is obsolete: true
Assignee | ||
Comment 27•22 years ago
|
||
Assignee | ||
Comment 28•22 years ago
|
||
nhotta, please r=
Assignee | ||
Comment 29•22 years ago
|
||
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.
Assignee | ||
Comment 30•22 years ago
|
||
Attachment #73097 -
Attachment is obsolete: true
Assignee | ||
Comment 31•22 years ago
|
||
nhotta, please r=
Comment 32•22 years ago
|
||
+ 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.
Assignee | ||
Comment 33•22 years ago
|
||
Attachment #73578 -
Attachment is obsolete: true
Comment 34•22 years ago
|
||
Comment on attachment 73611 [details] [diff] [review] v4 of patch r=nhotta
Attachment #73611 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Comment 35•22 years ago
|
||
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.
Assignee | ||
Comment 36•22 years ago
|
||
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
Assignee | ||
Updated•22 years ago
|
Assignee | ||
Updated•22 years ago
|
Whiteboard: MacOS X → MacOS X,adt3
Assignee | ||
Comment 38•22 years ago
|
||
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
Reporter | ||
Comment 39•22 years ago
|
||
> 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?
Assignee | ||
Comment 40•22 years ago
|
||
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.
Assignee | ||
Comment 41•22 years ago
|
||
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.
Reporter | ||
Comment 42•22 years ago
|
||
> 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.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.0 → mozilla1.2beta
Comment 43•21 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
Exactly what Bug 157967 is about.
Comment 47•20 years ago
|
||
FIXED in bug 120401, but we still needs ATSUI for better rendering.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 48•20 years ago
|
||
FIXED in bug 120401, but we still need ATSUI for better rendering.
You need to log in
before you can comment on or make changes to this bug.
Description
•