Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Description • 18 years ago

We should support FontLink for East Asian environments.
# old gfx did not support this feature.

testcase:
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=3395&action=view

On Win-Ja, Tahoma is linking to Japanese sans-serif font, so the all characters of testcase should be rendered by sans-serif fonts.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 1 • 18 years ago

Ah, there is bug 332649. That blocks this feature, but it may be minor issue.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 2 • 18 years ago

I hope that Kimura-san reviews this before Stuart.

	Masatoshi Kimura [:emk]
	Comment 3 • 18 years ago

Comment on attachment 251084 [details] [diff] [review]
Patch rv1.0

> +            if (records[i].mPlatform == PLATFORM_UNICODE)
> +                continue;
You could skip the fallback if platform/encoding is either 3/1 or 3/2.
> +        for (PRUint32 j = 0; j < records[i].mLength; j++) {
> +            ENSURE_SUCCESS(binStream->Read8(c))
> +            // XXX Some Chinese font has strange encoded name, should skip it.
> +            if (*c == 0) {
> +                cname.Truncate();
> +                break;
> +            }
> +            c++;
> +        }
I meant to say use the code such as:
>        for (PRUint32 j = 0; j < records[i].mLength; j++) {
>            ENSURE_SUCCESS(binStream->Read8(c))
>            // XXX Some Chinese font has strange encoded name, should skip it.
>            if (*c)
>                c++;
>        }
>        cname.SetLength(c - (PRUint8 *)cname.BeginWriting());
You could convert correctly by skipping null character.
华康简综艺(Simplified Chinese) and FB어떤사람UL(Korean) will require this trick.
I believe a lot of similar fonts may present because the former is made by 华康(Dynacomware).
> +            PRInt32 len = ::GetLocaleInfo(records[i].mLanguage,
> +                                          LOCALE_IDEFAULTANSICODEPAGE,
> +                                          NULL, 0);
> +            nsCAutoString buf(len);
> +            char* cpname = buf.BeginWriting();
> +            ::GetLocaleInfo(records[i].mLanguage,
> +                            LOCALE_IDEFAULTANSICODEPAGE,
> +                            cpname, len);
> +            cp = atoi(cpname);
Please guess the encoding from EncodingID instead of LanguageID if possible. LanguageID doesn't affect the encoding. The font name may contain the CJK characters even if LanguageID is 0x409(en-us). Again, FB어떤사람UL has such a font name.
> +            else if (StringEndsWith(font, NS_LITERAL_STRING(".ttf")) ||
> +                     StringEndsWith(font, NS_LITERAL_STRING(".otf"))) {
You will miss the uppercase font files. use |nsCaseInsensitiveStringComparator|.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 4 • 18 years ago

Thank you for your review, Kimura-san.

The case issue is not correct. My patch make lower case string before Find/StringEndsWith. But the debug code has a bug. So, my code was not good for readable. Therefore, I changed the code to using nsCaseInsensitiveCStringComparator, thanks.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 5 • 18 years ago

Oops, sorry. I found a mistake in the comment.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 6 • 18 years ago

Sorry for the spam :-(

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 7 • 18 years ago

Sorry...

	Masatoshi Kimura [:emk]
	Comment 8 • 18 years ago

Comment on attachment 251348 [details] [diff] [review]
Patch rv2.0.2

Looks good, r=vyv03354.
> The case issue is not correct. My patch make lower case string before
> Find/StringEndsWith. But the debug code has a bug.
Sorry, I confused it with debug code (I've found this when changing debug code on my tree to print foreign character correctly).
Probably it's faster to use |ToLowerCase|.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 9 • 18 years ago

Comment on attachment 251348 [details] [diff] [review]
Patch rv2.0.2

Thank you, Kimura-san.

Stuart, would you review too?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 10 • 18 years ago

We found the widget emulation issue (bug 368216). It should be fixed. Now, this should not be "enhancement".

Stuart, I hope that you review the patch in early time.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 11 • 18 years ago

Updating to latest trunk. And optimizing the coding style to 120 characters per line.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 12 • 18 years ago

Oops, the debug code is enabled...

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 13 • 18 years ago

Stuart:

Would you review this?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 14 • 17 years ago

Sorry for the delay. I'll post new patch soon.

This will fix bug 368216.

I confirmed that there are two FontLink: one is implemented on Windows; It is using the registry and user customizable. other is implemented on IE; It is used for Trident. They are really different implementation. And IE6's and IE7's are different. IE6 prefers the system registry. But probably, IE7 uses similar rule like Gecko. So, I think that we don't need to implement FontLink for web page rendering. *However*, it is really necessary for system fonts (i.e., for UI of Fx and etc.). Therefore, this patch use prefs for enable/disable the FontLink. By the default setting, the FontLink is only enabled for system fonts. I think that this is best choice for compatibility for IE7 rendering result and other native application's UI. And the risk is minimum.

I need some works for this patch, so, I need a few days...

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 15 • 17 years ago

Oops, I posted wrong patch...

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 16 • 17 years ago

And the new patch is independent from necko!

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 17 • 17 years ago

I need more works and testings...

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 18 • 17 years ago

O.K. This works fine for me. And this also fixes bug 368216.

And this patch can remove the adhoc approach for Chinese Windows in gfx/src/thebes/nsSystemFontsWin.cpp. Because Chinese UI default font is western font, so, FontLink is used in default settings on Chinese Windows. And the size changing by FontLink is applied. I think that the current Firefox UI western font size is wrong on Chinese Window. The cause is the adhoc approach. Maybe, this patch fixes the long standing bug too.

And this patch doesn't change the web page's rendering result. Because FontLink emulation is used only for system fonts. (gfxFontStyle.systemFont is true)
Therefore, this patch only has low risk. But for CJK users, this patch has high return. Because some Windows/Firefox themes might specify the western font and the size might be 8pt. In such case, the CJK text is too small, but this patch increases the CJK font size at linking.

And I think the users can enable the FontLink to web pages by the hidden pref. IE7 doesn't use system FontLink, so, if we enable it on default settings, we lost the compatibility with IE7. But some CJK users use FontLink aggressively. They will prefer to use FontLink on web page rendering. And the hidden pref helped me for testing! (The system font changing is too troublesome.)

I wrote the details of FontLink in gfxWindowsFonts.h, please check it.

> /**
>  * LinkingFontEntry is a FontEntry that is linking font by FontLink. Note that this
>  * class doesn't have all detail of the font, so, if you need to get the detail of
>  * the font, you need to use |FontEntry::GetOriginalFontEntry| or |FontEntry::mOriginalFont|.
>  * The all methods of FontEntry should be always refer the original font entry.
>  *
>  * FontLink:
>  *     This is the name of virtual font mechanism on Win32 (NT4 or later).
>  *     A font is linked one or more fonts. The font is called "base font".
>  *     And the fonts which link to the base font is called "linking fonts".
>  *     If base font doesn't have some glyphs in intl text, there are some missing glyphs
>  *     without FontLink. However, TextOut API users linking fonts for rendering the missing glyphs.
>  *     And note that the linking font size is not same as base font size. The size changing rule is
>  *     complex, we emulate the rule in |LinkingFontEntry::GetLinkingSize|. See it for the detail.
>  *
>  *     The FontLink combinations is defined in the system registry:
>  *         HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
>  *     The registry name means base font name. And the values (REG_MULTI_SZ) are linking font files.
>  *     If the font file is TTC, there is a font name after the file name and a comma.
>  *     And on Vista (probably and later), the linking fonts are specified the linking size ratio from
>  *     the base font size. The format is comma separated a numerator and a denominator after a comma.
>  *     E.g., Windows Vista-Ja has folloing entry:
>  *         Segoe UI
>  *             TAHOMA.TTF
>  *             MEIRYO.TTC,Meiryo,128,85
>  *             MEIRYO.TTC,Meiryo
>  *             MSGOTHIC.TTC,MS UI Gothic
>  *             MSJH.TTF,128,96
>  *             MSJH.TTF
>  *             MSYH.TTF,128,96
>  *             MSYH.TTF
>  *             MALGUN.TTF,128,96
>  *             MALGUN.TTF
>  *     In this example, the Western font "Segoe UI" is a base font, it is linked by:
>  *         Tahoma (Western),
>  *         Meiryo (Japanese, the first line has size ratio (128/85),
>  *                 but for campatibility, the nexe line doesn't have the radio),
>  *         MS UI Gothic (Japanese),
>  *         Microsoft JhengHei (Traditional Chinese),
>  *         Microsoft Yahei (Simplified Chinese),
>  *         Malgun Gothic (Korean)
>  *     So, the "Segoe UI" is a Western font, but TextOut API can render the CJK characters too.
>  *     Especially, this is important for UI, because third party (Windows's and Firefox's) themes
>  *     might use western fonts in UI.
>  *
>  * Our Limitations:
>  *     The system FontLink allows to use non-installed font files (I'm not sure, but the MSDN document
>  *     said so), however, it's unnecessary for us, because it should be rare case.
>  *     So, if the file name in registry has '\', we ignore the font.
>  *
>  *     The linking fonts may be non-TTF/OTF fonts. But we don't support them.
>  *
>  *     If the base font is not antialiased, the linking fonts are not antialized too with TextOut API.
>  *     But we cannot control whether we use antialiased.
>  *
>  *     The FontLink in TextOut API doesn't align the different font characters to base line,
>  *     But we always align them to base line, it's better :)
>  *
>  *     TextOut API get the registry value when the system was booted. We get them when the Firefox is
>  *     booted. So, if the registry values are changed before Firefox booting, the results are different
>  *     between TextOut API and us.
>  *
>  * FontLink of Internet Explorer
>  *     IE has original FontLink themselves. In IE6, the behavior was similar to the system FontLink.
>  *     However, IE7 might be ignoring the registry. IE7 prefers the font setting of IE.
>  *     So, the IE7's behavior is similar to our font selection. Therefore, the system FontLink
>  *     emulation should not be used on web contents for compatibility with IE7.
>  *
>  *     So, we should only use the system FontLink emulation in UI fonts in default setting.
>  */

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 19 • 17 years ago

for UI compatibility with other win32 applications in CJK, this should be landed beta2.

	Stuart Parmenter
	Comment 20 • 17 years ago

not a regression, not going to block on it

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 21 • 17 years ago

Comment on attachment 286964 [details] [diff] [review]
Patch rv3.0

This patch has a bug, the next patch is coming soon.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 22 • 17 years ago

fix a bug and some nits.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 29 • 17 years ago

Stuart:

These screenshots are with western system menu font. So, the CJK fonts are selected from FontLink or our font switching. And the CJK font size is changed at using FontLink.

So, the current trunk build rendering is very ugly for us in this case (attachment 289136 [details] and attachment 289139 [details]). Especially, the CJK fonts are not used Anti-Aliased rendering, because our default CJK font setting is not use new CJK fonts on Vista. The CJK fonts are too small size. However, my patch can fix it and we can get the similar behavior.

This bug is not a regression, but this is *important* bug for some CJK users.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 30 • 17 years ago

Updating for latest trunk.

Stuart, what's a problem for you not reviewing this?

	KENZ (Kenji Irie)
	Comment 31 • 17 years ago

Updated the patch rv3.2 for trunk

	Roy Tam
	Comment 32 • 17 years ago

I hope this patch will have an update for RC1 so that I can test if missing glyph issue in my computer can be solved by fontlink.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 33 • 17 years ago

(In reply to comment #32)
> I hope this patch will have an update for RC1 so that I can test if missing
> glyph issue in my computer can be solved by fontlink.

It's not easy work. The related code architecture was changed in this few months. I need to create new patch for this bug, but I cannot work on this now.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 34 • 17 years ago

Stuart:

I want to fix this bug in 1.9.1. If I'll post new patch, do you review it?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 35 • 16 years ago

The patch is simpler than the previous patch, I need to test...

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 36 • 16 years ago

fix a mistake

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 37 • 16 years ago

fix a bug that cannot change the font size at linking.

	Roy Tam
	Comment 38 • 16 years ago

(In reply to comment #37)
> Created an attachment (id=332787) [details]
> Patch v4.2
> 
> fix a bug that cannot change the font size at linking.
> 

Does this patch supports VC 2003 SP1? I got errors after applying this patch.

/cygdrive/c/moz2/mozilla-central/build/cygwin-wrapper cl -FogfxWindowsPlatform.obj -c  -DIMPL_THEBES -DMOZILLA_INTERNAL_API -D_IMPL_NS_GFX -D_IMPL_NS_MSG_BASE -D_IMPL_NS_WIDGET  -DOSTYPE=\"WINNT5.1\" -DOSARCH=WINNT  -I/cygdrive/c/moz2/mozilla-central/gfx/thebes/src -I. -I../../../dist/include/cairo -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/xpcom -I../../../dist/include/unicharutil -I../../../dist/include/lcms -I../../../dist/include   -I../../../dist/include/thebes -I../../../dist/include/nspr     -I../../../dist/sdk/include       -GR- -TP -nologo -W3 -Gy -Fdthebes.pdb  -DNDEBUG -DTRIMMED -Ob2gity -GLFAT7s -arch:SSE -I../../../dist/include/cairo  -MD            -DMOZILLA_CLIENT -D_MOZILLA_CONFIG_H_ -DWINVER=0x500 -D_WIN32_WINNT=0x500 -D_WIN32_IE=0x0500 -DX_DISPLAY_MISSING=1 -DMOZILLA_VERSION=\"1.9.1a2pre\" -DMOZILLA_VERSION_U=1.9.1a2pre -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -D_WIN32=1 -DWIN32=1 -DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DSTDC_HEADERS=1 -DWIN32_LEAN_AND_MEAN=1 -DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DMOZ_EMBEDDING_LEVEL_DEFAULT=1 -DMOZ_EMBEDDING_LEVEL_BASIC=1 -DMOZ_EMBEDDING_LEVEL_MINIMAL=1 -DMOZ_PHOENIX=1 -DMOZ_BUILD_APP=browser -DMOZ_XUL_APP=1 -DMOZ_DEFAULT_TOOLKIT=\"cairo-windows\" -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1 -DMOZ_NO_XPCOM_OBSOLETE=1 -DMOZ_OGG=1 -DMOZ_MEDIA=1 -DMOZ_XTF=1 -DMOZ_CRASHREPORTER_ENABLE_PERCENT=100 -DMOZ_MATHML=1 -DMOZ_ENABLE_CANVAS=1 -DMOZ_SVG=1 -DMOZ_SVG_FOREIGNOBJECT=1 -DMOZ_UPDATE_CHANNEL=default -DMOZ_DISABLE_VISTA_SDK_REQUIREMENTS=1 -DMOZ_DISABLE_PARENTAL_CONTROLS=1 -DMOZ_PLACES=1 -DMOZ_FEEDS=1 -DMOZ_STORAGE=1 -DMOZ_SAFE_BROWSING=1 -DMOZ_URL_CLASSIFIER=1 -DNS_DISABLE_LOGGING=1 -DMOZ_USER_DIR=\"Mozilla\" -DMOZ_STATIC_BUILD=1 -DMOZ_TREE_CAIRO=1 -DHAVE_UINT64_T=1 -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_RDF=1 -DMOZ_MORKREADER=1 -DMOZ_DLL_SUFFIX=\".dll\" -DJS_THREADSAFE=1 -DMOZILLA_LOCALE_VERSION=\"1.9a1\" -DMOZILLA_REGION_VERSION=\"1.9a1\" -DMOZILLA_SKIN_VERSION=\"1.8\"  -UWIN32_LEAN_AND_MEAN /cygdrive/c/moz2/mozilla-central/gfx/thebes/src/gfxWindowsPlatform.cpp
cl : Command line warning D4025 : overriding '/DWIN32_LEAN_AND_MEAN=1' with '/UWIN32_LEAN_AND_MEAN'
gfxWindowsPlatform.cpp
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(574) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(828) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\istream(1064) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(455) : error C2926: 'gfxWindowsPlatform::GetFontNameFromTTF::NameRecord' : types with no linkage cannot be used as template arguments
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(455) : error C2955: 'nsTArray' : use of class template requires template argument list
        c:\moz2\mozilla-central\obj\dist\include\xpcom\nsTArray.h(764) : see declaration of 'nsTArray'
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(455) : error C2133: 'records' : unknown size
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(455) : error C2512: 'nsTArray' : no appropriate default constructor available
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(455) : error C2262: 'records' : cannot be destroyed
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(470) : error C2660: 'nsTArray<E>::AppendElement' : function does not take 1 arguments
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(470) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(474) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(475) : error C2228: left of '.mLength' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(475) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(477) : error C2228: left of '.mOffset' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(477) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(489) : error C2228: left of '.mPlatform' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(490) : error C2228: left of '.mPlatform' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(491) : error C2228: left of '.mEncoding' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(491) : error C2228: left of '.mEncoding' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(489) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(490) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(491) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(491) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(492) : error C2228: left of '.mLength' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(492) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(493) : error C2228: left of '.mLength' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(493) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(508) : error C2228: left of '.mOffset' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(508) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(512) : error C2228: left of '.mLength' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(512) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(515) : error C2228: left of '.mLength' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(515) : error C3861: 'records': identifier not found, even with argument-dependent lookup
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(530) : error C2228: left of '.mEncoding' must have class/struct/union type
c:/moz2\mozilla-central\gfx\thebes\src\gfxWindowsPlatform.cpp(530) : error C3861: 'records': identifier not found, even with argument-dependent lookup
make[6]: *** [gfxWindowsPlatform.obj] Error 2
make[6]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj/gfx/thebes/src'
make[5]: *** [libs] Error 2
make[5]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj/gfx/thebes'
make[4]: *** [libs] Error 2
make[4]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj/gfx'
make[3]: *** [libs_tier_gecko] Error 2
make[3]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj'
make[2]: *** [tier_gecko] Error 2
make[2]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/c/moz2/mozilla-central/obj'
make: *** [build] Error 2

	Roy Tam
	Comment 39 • 16 years ago

After following Microsoft's guideline, moving NameRecord out from GetFontNameFromTTF(), it compiles.
http://msdn.microsoft.com/en-us/library/h4k0111f(VS.80).aspx

	John Daggett (:jtd)
	Comment 40 • 16 years ago

Masayuki,

Could you describe the use case for this feature?  As I understand it, it's primarily for use with chrome, not content, correct?  And the behavior on Windows is what exactly?  Tahoma/SegoeUI are magically linked to MS Gothic, etc. underneath, so Tahoma works as a "universal" font?  And how exactly are the metrics adjusted to make the different glyph sets compatible?

One note on the patch, any code that is parsing name table entries should probably live in gfxFontUtils.cpp, not in Windows-specific code, since we may need code in the future to speed up localized name lookups.

	John Daggett (:jtd)
	Comment 41 • 16 years ago

Also, what's the bugzilla.jp bug associated with this?

	Roy Tam
	Comment 42 • 16 years ago

(In reply to comment #40)
> As I understand it, it's primarily for use with chrome, not content, 
> correct?
> 
seems so but I hope it will work with content just like fx2 does.

fx2:
http://files1.rt.googlepages.com/fx2-fontlink.png
fx3:
http://files1.rt.googlepages.com/fx3-fl.png

both of them use same font file:
http://files1.rt.googlepages.com/MS-GothicEXplus.7z

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 43 • 16 years ago

(In reply to comment #40)
> Masayuki,
> 
> Could you describe the use case for this feature?  As I understand it, it's
> primarily for use with chrome, not content, correct?

Yes. But even if the elements in contents, that is specified the system fonts by CSS, they are applied this Font Linking too. And users can change the behavior with prefs. Disable/Enable/Enable only for system fonts. The last item is default setting.

> And the behavior on
> Windows is what exactly?  Tahoma/SegoeUI are magically linked to MS Gothic,
> etc. underneath, so Tahoma works as a "universal" font?  And how exactly are
> the metrics adjusted to make the different glyph sets compatible?

Yeah, there are complex issue for the metrics. On Vista, the size at linking can be changed (see the comment of the patch), then, I was changed to very large size than base font. The linking glyphs are *not* in base font box. I.e., the too large CJK characters are overflowed and clipped by UI parts. So, I think we don't need such case, if such case is occurred, the system is very unusable :-p

And the system Font Linking is not aligned to baseline of the base font. But we align to the baseline. I have no idea for this emulation. However, in such case, the rendered text is pretty ugly, I think we don't need to emulate it.

> One note on the patch, any code that is parsing name table entries should
> probably live in gfxFontUtils.cpp, not in Windows-specific code, since we may
> need code in the future to speed up localized name lookups.

O.K. But the method ignores the non-Windows encoding names. Because Windows (system) ignores them. So, that is for compatibility with Win32 system. If you need to use the method in other points, you need to improve the method and you need to add a param for to limit the behavior.

(In reply to comment #41)
> Also, what's the bugzilla.jp bug associated with this?

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5242

(In reply to comment #42)
> (In reply to comment #40)
> > As I understand it, it's primarily for use with chrome, not content, 
> > correct?
> > 
> seems so but I hope it will work with content just like fx2 does.

No, Fx2 and older Gecko engine didn't support font linking. The missing glyph issue is another bug.

	John Daggett (:jtd)
	Comment 44 • 16 years ago

Microsoft description of font linking:

http://www.microsoft.com/globaldev/getwr/steps/wrg_font.mspx

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 45 • 16 years ago

yep, but the document also don't specify the font-size computation. I asked the spec to a member of MS, however, he didn't know such behavior :-p (He was surprised!)

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 47 • 16 years ago

* GetFontNameFromTTF is separated to gfxFontUtils.
* The build failure of 38 is fixed. (Thank you, Roy!)

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 49 • 16 years ago

here is a test build:
https://build.mozilla.org/tryserver-builds/2008-08-08_04:35-masayuki@d-toybox.com-attachment332915 [review]/

	John Daggett (:jtd)
	Comment 51 • 16 years ago

Sorry, but I'm still not entirely clear on the need for this feature.  I do see that the text size in the captured screenshots is not ideal.  But I don't see why we need to emulate behavior of IE6 but not IE7 to achieve this.  

It seems like you're trying to effectively implement composite fonts with a size adjust factor for each of the underlying fonts.

Given 

  compositeFont ==> fontA, fontB, fontC

then 

  font-family: compositeFont, serif;

is equivalent to:

  font-family: fontA, fontB, fontC, serif;

with a size adjustment factor associated with fontA, fontB and fontC.

Is this an accurate description of this feature?

We actually will need something like this for handling the @font-face unicode-range descriptor (without the size adjustment factor).

In the attachment showing Vista registry settings, there's an entry for Segoe UI:

Segoe UI
  TAHOMA.TTF
  MEIRYO.TTC,Meiryo,128,85
  MEIRYO.TTC,Meiryo
  MSGOTHIC.TTC,MS UI Gothic
  MSJH.TTF,128,96

So glyphs from Segoe UI are looked up first, then glyphs from Tahoma etc.?  What happens in the case of bolded text?

	John Daggett (:jtd)
	Comment 52 • 16 years ago

One additional note: the code in gfxFontUtils.cpp needs to conditionalize the swapping code, since on big-endian platforms like PPC the data will be in big-endian order already in ReadFromFile16 and ReadFromFile32.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 53 • 16 years ago

(In reply to comment #51)
> But I don't see
> why we need to emulate behavior of IE6 but not IE7 to achieve this.

Sorry, the comment may be misleading. I meant that IE6 uses TextOut API like FontLink on web contents, however, IE7 does not do so. Therefore, I don't think we need to do FontLink emulation on *web contents*. So, I think that we should emulate the FontLink only on UI.

> It seems like you're trying to effectively implement composite fonts with a
> size adjust factor for each of the underlying fonts.
> 
> Given 
> 
>   compositeFont ==> fontA, fontB, fontC
> 
> then 
> 
>   font-family: compositeFont, serif;
> 
> is equivalent to:
> 
>   font-family: fontA, fontB, fontC, serif;
> 
> with a size adjustment factor associated with fontA, fontB and fontC.
> 
> Is this an accurate description of this feature?

Yes.

> We actually will need something like this for handling the @font-face
> unicode-range descriptor (without the size adjustment factor).

The font size adjustment is an important feature of FontLink. That makes bug  	368216 and bug 84668.

> In the attachment showing Vista registry settings, there's an entry for Segoe
> UI:
> 
> Segoe UI
>   TAHOMA.TTF
>   MEIRYO.TTC,Meiryo,128,85
>   MEIRYO.TTC,Meiryo
>   MSGOTHIC.TTC,MS UI Gothic
>   MSJH.TTF,128,96
> 
> So glyphs from Segoe UI are looked up first, then glyphs from Tahoma etc.? 
> What happens in the case of bolded text?

The patch ignores the bold case. I.e., I linked the fonts to Segoe UI at family level, not font level. Therefore, the bolded Segoe UI is linked by bolded Tahoma. I think that this is *not* correct implementation of FontLink, however, we don't have actual problem by this I think.

(In reply to comment #52)
> One additional note: the code in gfxFontUtils.cpp needs to conditionalize the
> swapping code, since on big-endian platforms like PPC the data will be in
> big-endian order already in ReadFromFile16 and ReadFromFile32.

NS_SWAP* macros support both endians.

http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsIStreamBufferAccess.idl#115
> 115 #if defined IS_LITTLE_ENDIAN
> 116 
> 117 # define NS_SWAP16(x) ((((x) & 0xff) << 8) | (((x) >> 8) & 0xff))
> 118 # define NS_SWAP32(x) ((NS_SWAP16((x) & 0xffff) << 16) | (NS_SWAP16((x) >> 16)))

> 157 #elif defined IS_BIG_ENDIAN
> 158 
> 159 # define NS_SWAP16(x) (x)
> 160 # define NS_SWAP32(x) (x)
> 161 # define NS_SWAP64(x) (x)

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 54 • 16 years ago

fix some bugs and updating some comments.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 55 • 16 years ago

Stuart:

I and John-san discussed for this bug.

He don't like my approach that changes the code only for Windows. He suggested that I add a new -moz- CSS property for the font linking and gfx/src/thebes/nsSystemFont*.cpp should set the property. I was thinking about his approach. But I don't have smart idea for the new CSS property. Because the size changing algorithm for FontLink is pretty complex. And that is not good for XP implementation. So, I think that my approach is best way for FontLink emulation, now.

He said that if Stuart agrees my approach, there is no problem. Stuart, how do you think my patch?

Josh-san:
This patch is improved to separate the FontLink emulation code from current code. Please recheck this patch. I believe that the FontLink related code is separated from current code, enough.

And your suggestion gives many works to me, maybe. It's not good, of course :-(

And I can reproduce the theme changing issue on XP with following steps:
1. Select [Property] of the context menu of Desktop.
2. Select [Design] tab.
3. Select [Windows Classic style] of the dropdown list of "Window and Button".
4. Click [OK] button.

Then, the system font of Menus is changed to Tahoma 8pt. I'm not sure why we cannot reproduce this issue on your computer.

And you don't like that this is minor issue for Windows-Ja. However, I believe that this bug fix helps some confusing people like the following forum. I sometimes found such people. They don't know why the fonts of menu of Firefox is smaller than other applications. So, I think this is minor, but important bug for Windows users.

http://forum.mozilla.gr.jp/srch.cgi?no=0&no=0&word=%83%81%83j%83%85%81%5B+%83t%83H%83%93%83g+%8F%AC%82%B3+Win&andor=and&logs=all&PAGE=20

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 56 • 16 years ago

> Josh-san:

Oops, John-san, sorry.

	Roy Tam
	Comment 57 • 16 years ago

(In reply to comment #53)
> (In reply to comment #51)
> > But I don't see
> > why we need to emulate behavior of IE6 but not IE7 to achieve this.
> 
> Sorry, the comment may be misleading. I meant that IE6 uses TextOut API like
> FontLink on web contents, however, IE7 does not do so. Therefore, I don't think
> we need to do FontLink emulation on *web contents*. So, I think that we should
> emulate the FontLink only on UI.
> 
but should we follow IE tightly? and as some people don't use IE7 and still stay in IE6, maybe a perf() option is more suitable.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 58 • 16 years ago

(In reply to comment #53)
> Sorry, the comment may be misleading. I meant that IE6 uses TextOut API like
> FontLink on web contents, however, IE7 does not do so. Therefore, I don't think
> we need to do FontLink emulation on *web contents*. So, I think that we should
> emulate the FontLink only on UI.

If this is just for the UI, and is not a web compat issue, given the code that's required to do this shouldn't we just find another way to solve the UI font problem?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 59 • 16 years ago

(In reply to comment #57)
> (In reply to comment #53)
> > (In reply to comment #51)
> > > But I don't see
> > > why we need to emulate behavior of IE6 but not IE7 to achieve this.
> > 
> > Sorry, the comment may be misleading. I meant that IE6 uses TextOut API like
> > FontLink on web contents, however, IE7 does not do so. Therefore, I don't think
> > we need to do FontLink emulation on *web contents*. So, I think that we should
> > emulate the FontLink only on UI.
> > 
> but should we follow IE tightly? and as some people don't use IE7 and still
> stay in IE6, maybe a perf() option is more suitable.

The FontLink emulation is out of scope of CSS spec. That is a virtual font creating mechanism. I think that even if we apply FontLink emulation to web contents, it doesn't violate the CSS spec. However, that will break the compatibility with other browsers and other platforms Gecko. Of course, this is bad. I think the compatibility is too important for accessibility, because that includes the font size adjusting.

I think the FontLink emulation should be optional by pref for Web Contents.

(In reply to comment #58)
> (In reply to comment #53)
> > Sorry, the comment may be misleading. I meant that IE6 uses TextOut API like
> > FontLink on web contents, however, IE7 does not do so. Therefore, I don't think
> > we need to do FontLink emulation on *web contents*. So, I think that we should
> > emulate the FontLink only on UI.
> 
> If this is just for the UI, and is not a web compat issue, given the code
> that's required to do this shouldn't we just find another way to solve the UI
> font problem?

I don't think so. Because I think that this is just a gfx issue. We have decided that we don't use native UIs, instead of that, we use XUL. Then, XUL should emulate the native UI behavior.

The native UIs may use TextOut API. But we don't use it, we are using lower APIs instead. The lower APIs don't support FontLink, therefore, we have this important issue. (Especially this bug is serious for font size adjusting problem.)

John-san suggested that we should add new font size adjusting CSS property. And I try to think it last week. However, I could not think that the approach is good idea. Because the font size adjusting is too complex. And that is not logically. E.g., that is using magic number, 11px and 13px. I don't think that this should be supported on other platforms. This is only emulate the Windows system behavior. And also the font size ratio can be specified by the user via registry on Vista for each linking fonts. So, if we add a new property, that needs too complex grammar for the values.

I think that if the gfxFontGroup is created from nsFont array instead of family names, we can think another approach that is implementing in gfx/src/thebes. However, it's not so, unfortunately.

	John Daggett (:jtd)
	Comment 60 • 16 years ago

I guess what makes me uncomfortable about this feature is that it adds a lot of complexity to our code for a very, narrowly focused problem.  If the UI font size is a problem on Windows, then we should adjust that more directly by specifying the UI font size to be larger for CJK localizations.

It also seems like this only affects a subset of users, not all users.  For example, the default font on Japanese Windows is set to MS UI Gothic for most UI elements, which means the linking will only occur with Korean/Chinese fonts [see the attachment that lists font link defaults for Windows XP].  From comment 55, it sounds like you're saying that users need to select "Windows Classic style" for Tahoma to be set as the default font, causing the awkward text rendering.

> John-san suggested that we should add new font size adjusting CSS
> property. And I try to think it last week. However, I could not think
> that the approach is good idea. Because the font size adjusting is too
> complex. And that is not logically. E.g., that is using magic number,
> 11px and 13px.

I tried to summarize the font link algorithm in comment 51 but it sounds like I didn't get it completely right, from what you're saying these font substitutions only apply to UI text that uses font sizes 11px to 13px?  Is that correct?

With your patch you create a subclass of FontEntry called LinkingFontEntry.  But given the limited use of this code, I don't see that a LinkingFontEntry class is needed.  You just need a way of catching when one of these special names is being looked up in the right context (i.e. when it's a UI font and the right size) and simply expand out the list when gfxFont's are created with the right size adjustment factor for each gfxFont.

And I really, really wish we didn't have to manually parse the name table for this, although I think we'll probably need code like this eventually.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 61 • 16 years ago

(In reply to comment #60)
> If the UI font
> size is a problem on Windows, then we should adjust that more directly by
> specifying the UI font size to be larger for CJK localizations.

This doesn't make sense, we must get the system font size directly. And the larger font size should not be used for the Western font. It would break something.

> It also seems like this only affects a subset of users, not all users.  For
> example, the default font on Japanese Windows is set to MS UI Gothic for most
> UI elements, which means the linking will only occur with Korean/Chinese fonts
> [see the attachment that lists font link defaults for Windows XP].  From
> comment 55, it sounds like you're saying that users need to select "Windows
> Classic style" for Tahoma to be set as the default font, causing the awkward
> text rendering.

Yeah, I agree that the affected users are not many. However, I believe that this is very important issue for the affected users even if they are not many. Because such users did *not* change the system fonts directly, and also XUL UI should render same text as other native applications UI's.

> > John-san suggested that we should add new font size adjusting CSS
> > property. And I try to think it last week. However, I could not think
> > that the approach is good idea. Because the font size adjusting is too
> > complex. And that is not logically. E.g., that is using magic number,
> > 11px and 13px.
> 
> I tried to summarize the font link algorithm in comment 51 but it sounds like I
> didn't get it completely right, from what you're saying these font
> substitutions only apply to UI text that uses font sizes 11px to 13px?  Is that
> correct?

Not, if the font size ratio is specified in the system registry on Vista (or later), then, we need to use it after 11px and 13px adjusting. And also, if the base font doesn't have bitmap glyph, we need the "ascent size adjust". See |LinkingFontEntry::GetLinkingSize| of the patch.

> With your patch you create a subclass of FontEntry called LinkingFontEntry. 
> But given the limited use of this code, I don't see that a LinkingFontEntry
> class is needed.  You just need a way of catching when one of these special
> names is being looked up in the right context (i.e. when it's a UI font and the
> right size) and simply expand out the list when gfxFont's are created with the
> right size adjustment factor for each gfxFont.

I had another idea for the implementation.
1. FontNameResolver calls linking fonts after base font.
2. gfxWindowsFontGroup creates with size adjusted gfxWindowsFont for the linking fonts.

However, for (1), we need to add an additional param for the callback. And for (2), we need to save a flag array that saves whether each font entry of gfxWindowFont is linking font.

This might be simpler implementation, however, this needs to change XP code...

If someone have better implementation idea, I want it...

> And I really, really wish we didn't have to manually parse the name table for
> this, although I think we'll probably need code like this eventually.

Yeah, basically, Win32 should have FontLinking related API (e.g., getting the linking fonts for a font) for us!

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 62 • 16 years ago

FYI:

See the change of nsSystemFontsWin in the patch. Chinese Windows may have this bug, but it is fixed by the hacky way. So, the XUL UI font size on Chinese Windows may be different than other native applications. The patch should fix it.

	Carter Wang
	Comment 64 • 15 years ago

I don't know why this bug has been there for so long.
It appears people misunderstand this issue a little.

First of all, the problem fontlinking trying to address is not an IE-emulation issue. It is computer typesetting issue.
Second, the problem fontlinking trying to address appears on all platforms including Linux Windows and MAC.  (Linux deals it with another way through fontconfig and freetype. I am not sure how MAC deals with it or they don't deal with it at all :(.)


Font linking is the technology that Microsoft coined to address the problem how to render East-Asian-language Glyphs and Latin-language Glyphs properly and beautifully when they are mixed together on the screen.
Due to the encoding system that we are using today, it is impossible to specify different typefaces for different language 
when Asian language and Latin alike languages are mixed together.

Latin based language and Asian language are very different. Latin glyphs have ascenders and descenders while Asian language glyphs don't.
Therefore when both showing at exactly the same size. Latin glyphs appear a little bit larger than Asian glyphs on screen.
So we will want the Asian glyphs to look a little bit larger when mixed with Latin glyphs.

In a perfect world, web authors can write css like this to address the size problem
body {
font-family-en_US: Arial;
font-size-en_US: 10pt;

font-family-ja: Mingliu;
font-size-ja: 12pt;

font-family-zh_CN: SimSun;
font-size-zh_CN: 12pt;
}
something like this is impossible to implement.
Given the current encoding system we are using, we are unable to specify different font and font size for different language when they are mixed together.

Therefore Microsoft developed font linking to partially address the problem.
Font linking provides a list of fallback fonts for the base font in order to render Asian glyphs.
Font linking also uses a ratio to adjust the font size discrepancy when a fallback font is used.
Both GDI on win32(Uniscribe service) and IE's graphic library uses font linking when rendering fonts.


Font linking is the technolody that microsoft coined to address the problem how to render  
East-Asian-language Glyphs and Latin-language Glyphs properly and beatifully when they are mixed together on the screen.
Due to the the encoding system that we are ussing today, it is impossible to specify different typefaces for different language 
when Asian language and Latin alike languages are mixed together.

Latin based language and Asian language are very different. Latin glyphs has ascenders and descenders while Asian laguange glyphs don't.
Therefore when both showing at exactly the same size. Latiin glyphs appears a little bit larger than Asian glyphs on screen.
So we will want the Asian glyphs to look a little bit larger when mixed with Latin glyphs.

In a perfect world, web authors can write css like this to address the size problem
body {
font-family-en_US: Arial;
font-size-en_US: 10pt;

font-family-ja: Mingliu;
font-size-ja: 12pt;

font-family-zh_CN: SimSun;
font-size-zh_CN: 12pt;
}
somthing like this is impossible to implement.
Given the current encoding system we are using, we are unable to specify different font and font size for different language when they are mixed together.
(Unless the author is will to do like this <>)
Therefore Microsoft developed font linking to partially address the problem.
Font linking provide a sierous of fallback fonts for the base font in order to render Asian glyphs.
Font linking also uses a ratio to adjust the font size discrepency when a fallback font is used.
Both GDI on win32(Uniscribe service) and IE's graphic library uses font linking when rendering fonts.

	Carter Wang
	Comment 65 • 15 years ago

oops, posted twice, copy paste error , :0

	John Daggett (:jtd)
	Comment 66 • 15 years ago

Carter, the patch that Masayuki has deals primarily with the problem of UI fonts, it's not intended to apply to all content.  The larger problem of how to mix Latin and CJK text in general is largely a font problem I think, a font with CJK glyphs can easily accomodate Latin glyphs that are appropriate for use with CJK glyphs from the same font.  Microsoft's font linking is a platform-specific solution, it's not a generalized solution for the web.  Supporting it within chrome so that the UI look-and-feel is consistent with other Windows apps is one thing, supporting it in content is another thing entirely.

In many ways, the font-size-adjust property is an attempt to address a similar issue, the problem that fallback fonts with varying x-heights are problematic in usage:

http://www.w3.org/TR/css3-fonts/#relative-sizing-the-font-size-adjust-pro

One could imagine a new CSS property to allow for more generalized resizing of fallback fonts (using a mixture of @font-face, src: local(xxx) and a new descriptor for the size adjustment?).  

The W3C www-style mailing list would be the appropriate place to post proposals.

	Carter Wang
	Comment 69 • 15 years ago

From what I learn from this patch, this is not just a fix to the chrome UI but will also apply to content. This change, however, will not break the W3 standard.
I uploaded to attachment showing how things are looking currently when CJK and Latin glyphs are together at different sizes.

I mean I am talking about what W3 or standard should do about it right now.
Sometime there is just a little hacking that we can do to make things look good.
I am not a fan of IE. But currently it seems only IE offers good-looking eligible fonts at pixel size like 11px while keeping the Latin and CJK glyphs resizing harmoniously together.
I am from China. I look at CJK and Latin language on the screen all the time. Something like this is like a soar in the eye. I have been hearing people around me complaining this problem many times. They have no idea what this is about. They just say that FF is ugly and turn back to IE. I know this is not right but hey good-looking face is still important.
Making W3 standards to fully address this issue and web authors to fully aware of this will take much time. I am asking this just to make FF looking a little better in the mean time unless this fix will you guys really uncomfortable.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 70 • 15 years ago

John-san, how do you think a plan to implement FontLink? Looks like you don't work on unicode-range.

I still think that we should implement this platform-specific linking system for chrome (bug 368216).

	John Daggett (:jtd)
	Comment 71 • 15 years ago

I do not think FontLink behavior (fallback from Latin fonts to CJK-fonts in CJK locales with automagic resizing) should be used for content.  For chrome rendering I'm fine with it, as the idea is to emulate existing platform UI behavior.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Reporter
	Comment 72 • 9 years ago

WinXP hasn't been dropped from our support yet, actually, it's not worthwhile to emulate this feature in these days. I think that we can mark this as WONTFIX. How about you, John-san?

	John Daggett (:jtd)
	Comment 73 • 9 years ago

yup