Community
Participate
Working Groups
On Windows, org.eclipse.swt.graphics.TextLayout should support font substitution. If the user types any text not supported by the current font on StyledText which calls TextLayout, the text becomes blank (in Eclipse3.0M9) on Windows. For Example, if the user selects "Microsoft Sans Serif" font on Windows, and type Japanese text which "Microsoft Sans Serif" font does not contain, then notepad.exe still can display Japanese text. It is because notepad.exe supports font substitution and finds Japanese "MS Gothic" or something like that. (maybe because notepad.exe may simply call TextOutW(), though.) Since StyledText/TextLayout is implemented by Uniscribe, TextLayout should support font substitution.
TextLayout does perform font substitution. BTW, do you know how/if Uniscribe has any support to help the application to implement font substitution ? The only think I found is the HRESULT with the SCRIPT_NOT_IN_FONT when the ScriptShape fails. The hard part is how to select a different font, and for doing this I didn't find any help on the MSDN.
If you have a case where font substitution doesn't work please let me wich font and wich text (in Unicode) I should use to reproduce the problem.
Sorry I did not reply for a long time... I was checking the code in Eclipse3.0M8 when I wrote this report. At that time there was no implementation for the font substitution in TextLayout class in Eclipse3.0M8 Nice to see the font substitution code in Eclipse3.0! Currently I still have the problem on Eclipse3.0. I cannot display Japanese Hiragana character in my environment, when I select Tahoma. This is because EnumFontFamilyEx picks up "IBMLogo" (Type1) font and the Hiragana characters are defined as blank characters in "IBMLogo" font... Basically EnumFontFamilyEx picks up any font which TextLayout finds at first. This causes the user see the strange font by accident. It would be nice if TextLayout picked up the user's preferrable font according to the locale. (MS UI Gothic in Japanese, SimSun in Chinese, Gulim in Korean so on) So to do this, I think, maybe, we can use IMLangFontLink or IMLangFontLink2 in MLang: http://msdn.microsoft.com/workshop/misc/mlang/tutorials/fontlinking.asp then TextLayout can get the substitute font, without checking the fontlink entry directly in: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink What do you think ?
Sounds like this should be reopened.
Created attachment 13820 [details] Proposed additional fix for font substitution by MSIE MLang This is my proposal to provide additional font substitution code by MLang included in MSIE. This fix will substitute better fonts, such as MS PGothic for Japanese, Gulim for Korean Hungle, when Tahoma is set on TextLayout. Regarding MLang, please see http://msdn.microsoft.com/workshop/misc/mlang/mlang.asp This fix is based on Eclipse3.0GA code.
Hiroyuki Okamoto: Do you have a T-Chinese machine available for testing ? Pls, see bug62435.
I don't have Traditional Chinese localized version of Windows, but I tried my fix after swithcing the *system* language to Chinese(Taiwan) in English WinXP. Basically MLang did not pick up PMingLiU in Chinese (Taiwan) locale. when TextLayout class displays some Han character such as in CJK Unified Ideographs, Seems MLang tries to assign Japanese "MS PGothic" first, then Chinese Simplified "SimSun" or Korean "Gulim" even in Chinese Taiwan locale... (Actually it does not seem different order from fontlink entry in Registry...)
Sorry. I did not mean: (Actually it does not seem different order from fontlink entry in Registry...) I meant: (Actually it seems different order from fontlink entry in Registry...)
Currently being investigated. SN to decide if fix is too scary for R3.0.1.
Hiroyuki Okamoto: - It fail cause your machine is not a 'real' t-chinese machine, the only way to be sure is running on the real machine. - Question about the patch (I'm not familiar with MLang) a) Why do you need mLangFontLink2 and mLangFontLink. During my tests they returned always the same results. Having both just makes the code complex. From the doc I think the only advantage of mLangFontLink2 is that you can call MapFont() passing the char array instead of the codepage set, saving the call to GetStrCodePages. In our code you always call GetStrCodePages anyway. b) Why do you need to release the font and the font cache after shape ? Looks wrong cause the font is still in use. Wouldn't be safer to delete the font when the run is disposed ? Wouldn't be better to removed the SWT cache and use the MLang cache instead ? I tested performance of MLang I think it needs any addition cache. The SWT cache that is there is because our implementation of font substitution is too slow. Maybe it would be good to have a phone call to discuss the code, sometime problem report is not good for that.
Probably a good idea to have VI checking all the OLE/COM code before releasing any code.
Hiroyuki: would you know if your patch also fixes Bug63793 ?
I tried https://bugs.eclipse.org/bugs/attachment.cgi?id=11190&action=view in Bug63793 with my patch + Felipe's modification. Seems like, the characters in pr63793-MS932.txt and pr63793-utf8.txt are displayed correctly at first... but when I scroll the text, some characters change to whitebox characters. I also see the similar problem on StyledText sample in SWT Custom Controls plugin. when I type some characters not included in Tahoma, then BackSpace some characters, then some of characters change to whitebox sometimes... My evironmet is WinXP English Changed system language to Japanese, User language to Japanese.
Another additional idea is to call GetStockObject(DEFAULT_GUI_FONT) and shape (), the first time shape() fails, before trying MLang font substitution. I tested GetStockObject(DEFAULT_GUI_FONT) on Korean localized Win2000, then GetStockObject(DEFAULT_GUI_FONT) returned Gulim. so I expect GetStockObject(DEFAULT_GUI_FONT) should return PMingLiU on Taiwanese localized Windows. This may fix bug62435.
Created attachment 13929 [details] TextLayout new version This version of TextLayout replaces the one inside the zipfile attached by Hiroyuki. It contains some important bug fixes. Fuse-san: use this to test bug 63793.
fixed > 20040813 in HEAD
Hiroyuki: I had to change the code cause in graphics we can not have references to OLE.
To follow up on comment #9, will this also be fixed in 3.0.1?
No - We think the code is too risk to be backported into 3.0.1. The fix invalidades the TVT testing that was performed before 3.0.
*** Bug 70322 has been marked as a duplicate of this bug. ***
