Apache OpenOffice (AOO) Bugzilla – Issue 78970
Aqua: Too small ascent, descent, leadings for Asian fonts
Last modified: 2007-08-07 11:02:20 UTC
Font metric about ascent, descent, leadings for Japanese fonts seems small in current aquavcl01. This cause line space of a options dialogs too narrow. Also line space of text with MS font like "MS Mincho" too small in documents.
Set keyword
hdu->hdu reminder: we probably need the heuristic "CJK-fonts need extra 30% leading" (#107888#) is a good idea on aqua, too.
Aha. For the test purpose, I 've tested the attached code, which checks OS/2 table and adds the heuristic as in Windows version. It seems the linespace is fine for both "Hiragino Mincho Pro W3" and "MS Mincho" fonts.
Created attachment 46340 [details] test code to check OS/2 table for CJK font
Since only a few OSX fonts have an OS/2 table I wonder if the heuristic from the WIN port is sufficient here. Anyway, this issue will make it earliest into the successor CWS aquavcl01.
As far as I know, all Mac OS X truetype/opentype fonts has OS/2 table. So I think checking ulUnicodeRange2 in OS/2 table makes sense. However, Mac's fonts don't use usWinAscent and usWindecent offsets (they are assigned as zero).
On my factory installed system some fonts (like NewPeninimMT*.ttf and Raanana*.ttf) do not have an OS/2 table. They don't need the 30%-heuristic though :-)
I see. So I've examined the return value of ATSFontGetTable() for 'OS/2', and found following fonts don't seem to have the table. Most of them are for Hebrew, Korean, Latin, and Chinese (I'm not sure exactly though). Anyway, to import documents created by Windows, I think this heuristic helps very much :) AppleGothic Regular Apple LiGothic Medium Apple LiSung Light AppleMyungjo Regular Arial Hebrew Blackmoor LET Plain:2.0 Bordeaux Roman Bold LET Plain Corsiva Hebrew Courier #GungSeo Regular #HeadLineA Regular Hei Regular Helvetica InaiMathi Jazz LET Plain:1.0 Kai Regular Monaco New Peninim MT Palatino Party LET Plain:1.0 #PCMyungjo Regular #PilGi Regular Raanana Savoye LET Plain:1.0 Times Roman
Fixed in CWS aquavcl02.
These fonts do not seem to have an OS/2 table either: - Apple LiGothic Medium - AppleGothic - Courier - Hei - Helvetica - Monaco - Symbol - Times @ ekato: I'm wondering if you find the metrics of the fonts "Apple LiGothic Medium", "AppleGothic" and "Hei" good enough? Since they do not contain an OS/2 table the IsCJKFont() method returns false and the 30%- heuristic isnn't triggered?
@ hdu: Here is a screenshot of sample text about Chinese (Apple LiGothic, Hei), Japanese (Hiragino Gothic Pro W3, MS Gothic), and Korean (AppleGothic) using MS Word, OOo, TextEdit. In MS Word, I disabled grid alignment for line number (which seems to be the default for Word 2004 for Mac Japanese). In OOo, I just used default setting (Format->Page->Text Grid->No grid). With TextEdit I used single line spacing. Upper left is MS Word, which seems to show relatively constant line spacing. Lower left is OOo Writer, and shows 30% heuristic only for Japanese fonts. Upper right is TextEdit, and doesn't seem to show such a heuristic.
Created attachment 46605 [details] screenshot
@ekato: thanks alot for the screenshot (the other legacy app shown in the image is not available here). It shows that the heuristic needs some rework on this platform. Maybe we should check in vcl/aqua/source/gdi/ salatsuifontutils.cxx's GetDevFontAttributes() whether one of the font's FontLanguageCode indicates CJK? We have to be very careful though to apply the heuristic only to fonts that require it. No false positives or false negatives would be best.
@ hdu: I've tested your suggestion about checking script code and language code in GetDevFontAttributes(), and found it is rather difficult to detect CJK fonts with it. This is because it detects some non-CJK fonts as CJK font because ATSUGetIndFontName() sometimes return CJK language codes for these fonts. For example, Monaco has kFontSimpleChineseScript and kFontSimpChineseLanguage at nNameIndex is 27. Geneva also has all four CJK codes at some indices. Contrarily, it doesn't work for Hei and Kai (Simplified Chinese) fonts as they only contain kFontRomanScript and kFontEnglishLanguage. So next, I've tested encoding check of cmap subtable for Mac fonts as in the attached patch, and found it works perfectly to detect whether the font is CJK capable. I've implemented the checks after generic OS/2 table detection. As in the new screenshot, it also works for Korean and Chinese Mac fonts which lack OS/2 table.
Created attachment 46787 [details] New patch
Created attachment 46788 [details] new screenshot
@ekato: thanks for looking into this. Too bad that the font name language trick does not work reliably. Its great that the Mac-Encoding test you suggested works at least with most of the fonts on a standard install. On the other hand most of the CJK fonts from other platforms (e.g. Sazanami), from the MacTestDrive apps and many other sources do only contain a Mac-Encoding (Roman), which wouldn't trigger the new heuristic. Since the font is already selected when we need this info it is not too expensive to get the whole CMAP and check for a few typical unicodes. Which unicodes would be best? Maybe we should do combine these different tricks: - use the Mac-Encoding trick for fonts which are typical for older Mac platforms - use the OS/2 table unicode ranges if the OS/2 table is available - use the "test a few typical unicodes" heuristic for other fonts
> On the other hand most of the CJK fonts from other platforms (e.g. > Sazanami), > from the MacTestDrive apps and many other sources do only contain a > Mac-Encoding (Roman), which wouldn't trigger the new heuristic. Right. New one is intended to check older Mac platform fonts only. As you can see in the patch, it is assumed to be used with the OS/2 check. i.e. a check for cmap encoding is only performed even when OS/2 check cannot determine the CJK information. It may be too expensive to check every cmap subtable header (also I forgot to add 'break' when mbHasCJKSupport is detected in the loop of subtable check). So I've modified the patch to use mbHasOs2Table member and do Mac CMAP encoding check only for fonts without OS/2 table. In this way, most fonts can be determined with OS/2 unicode range check only, and the rest can be checked with Mac-Encoding trick I think. > Since the font is already selected when we need this info it is not too > expensive to get the whole CMAP and check for a few typical unicodes. > Which unicodes would be best? Sorry, I couldn't follow your meaning. Could you elabolate more please?
Created attachment 46848 [details] Revised patch about mac encoding check
@ekato: ok, the Mac-Encoding test + the OS2-unicoderange test should suffice, thanks for the patch >> Since the font is already selected when we need this info it is not too >> expensive to get the whole CMAP and check for a few typical unicodes. >> Which unicodes would be best? > > Sorry, I couldn't follow your meaning. Could you elabolate more please? Calling the method ImplMacFontData::GetImplFontCharMap() and using its result to test the availability of a few typical CJK unicodes (by calling the ImplFontCharMap::HasChar() or ImplFontCharMap::CountCharsInRange() methods) would we a very reliably indicator of CJK-ness, too.
@ hdu: OK. I'll commit the patch later. And thanks for the explanation about the cmap!
ericb->ekato Can you confirm this issue is fixed ?
ericb: Yes, fixed in aquavcl02.
One way to verify the issue, please compare the layout of "Tool->Options" dialog (see below and the attached screenshots) with ja package. Hiragino fonts is automatically used in the dialog with ja locale. sparcmoz: Could you verify this when you have a free time? 0. Set "International->Language" to Japanese in System Preferences, and re-login. 1. Launch m222 ja package (from http://ooopackages.good-day.net/pub/OpenOffice.org/MacOSX/SRC680_m222/) and open "Tool->Options". Line space in the dialog is very narrow and some parts of text and buttons are not shown correctly (m222_ja.png). 2. With aquavcl02, it should have appropriate amount of line spaces (aquavcl02_ja.png).
Created attachment 47139 [details] narrow line space
Created attachment 47140 [details] appropriate line space with aquavcl02
I confirmed the narrow line space as shown in the maho m222 build, and verified the appropriate line space with aquavcl02 built here. I also verified the last patch attached is in aquavcl02. The attached screenshot shows on the left side dialog with Japanese in System Preferences - International - Language, and the right hand side with English. The line spacing and dialog box height are greater in the Japanese (left side) version.
Created attachment 47142 [details] Japanese and English system pref
I made a new issue 80109 for the languages changing dialog size.
Got into SRC680_m225 => closing