Questions about font linking, etc.

by Michael S. Kaplan, published on 2006/01/22 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/22/515864.aspx

It seems like every time I turn around there is another question about font linking. Like this one from the Suggestion Box from Mike Lippert:

I'm definitely interested in a font linking follow-up post. In particular I was trying to figure out why on my computer our application writes a tooltip containing the rightwards arrow (U+2192) and it displays fine, while on the new QA WinXP system it displays as a box.

I suspect it has to do with font linking, and that our applicattions install could update a font linking registry setting so it would work consistently.

Or this recent one from Yury:

Hello Michael,

I'm looking for solution of following task: user should have a possibility to enter (thru keyboard) a ‘custom’ character into richedit boxes of MS offices applications (e.g. “to,cc,bcc” fileds of MS outlook). By ‘custom character' I mean ‘hand-made’ glyph which not exists in any present font.

My view of solving is following:
1. Edit keyboard mapping with Microsoft Keyboard Layout Creator (http://www.microsoft.com/globaldev/tools/msklc.mspx) and map some key combination to unused Unicode character (I m think ‘private’ E000+ area is good choice) so let it be uniE001 character.
2. Create a font with one glyph mapped to uniE001. (I’ve used FontForge)

As far as I understood (inclusive of your blog posts) font linking should took place here, and I should see my character because the only font which 'private' E000 section is my 'one-glyph' font. Unfortunately something goes wrong and I see only “ugly box” instead of my character.
Another experiment I’ve already done: I map my glyph on character already present in Arial Unicode MS font (actually ‘a in circle’ U+24D0 charcter). Then I’ve tried experiment with installing \uninstalling of ArialUnicodeMS and my font. And I’ve noted what font linking is really worked, ArialUnicodeMS is used if it currently installed for 'a in circle' character but my one-glyph font was never used.

My question is following: which is the difference between my and ArialUnicodeMS fonts? Does ArialUnicodeMS have ‘magic’ properties which my font doesn’t?
Does ArialUnicodeMS hardcodded in richedit font linking algorithm?
Is it possible to customize (influence on) font linking algorithm used in richedit.

To make this topic more attractive to others:
Can you explain a “the way of character [in richedit] from keyboard to screen via font mapping and other things”? As far as I understood from your posts you are one of few people who can describe a “whole picture”.

Thank you in advance,
Yury Zelensky

There are of course a few things going on here.

First, there are some of the issues mentioned in the prior posts I have done:

Well, that second one especially should help point out one the biggest problems here -- that font linking is unlikely to apply to either situation (or most of the other ones that come up). And neither one is a mechanism designed to pick up random code points from a font on that machine that happens to cover them.

Though for that there is the font linking feature in MLang which can be useful in some cases but obviously requires work on the part of a developer to get set up. Although the definition of font linking is different in MLang than it is for the rest of Windows (as I described in that post about linking versus fallback), they are both actually working to make a specific font "bigger" in a virtual sense by having it covered by other fonts to find missing characters.

The font fallback feature, on the other hand, is more what RichEdit an Uniscribe do, and there is no system set up to extend them to use fonts that they do not know about. Which is why it takes more than simply adding a font to get it to see support for fonts that cover areas of the PUA.

The truth is that there is no mechanism to see full support for PUA type solutions, or more generally for any user provided solutions with fonts, so generally it requires explicitly choosing the font.

In Mike Lippert's case (trying to support → (U+2192, a.k.a. RIGHTWARDS ARROW), the real issue is usually not the font fallback change (since the arrow has no complex script language dependecies that would involve Uniscribe) or what on would usually think of using East Asian font linking for. Though ironically enough installing East Asian support will make it visible since although the character is not in Tahoma or Microsoft Sans Serif it is in Gulim:

and MS UI Gothic:

and MingLiU:

and even SimSun:

And if you look at the display you'll see a random assortment of other characters in these fonts as well, in addition to the various Hangul and Kana and Ideographic code points that we expect....

So if I had to guess about the problem that Mike was having, it would be that East Asian support was not installed (it is one of those checkboxes on the second tab of Regional and Language Options). Though you want to be careful since the solution involves the installation of hundreds of megabytes of non-uninstallable files. So if the desire is to get a simple arrow then it may be a tad much.

Yury's interest, which is having an influence on what Office and RichEdit (which is produced by the Office team) do in this space, has a less happy answer, since such methods are not currently exposed....

This post was brought to you by "→" (U+2192, a.k.a. RIGHTWARDS ARROW)

# Nick Lamb on 22 Jan 2006 8:40 PM:

Last time you answered Mike about U+2192 you wrote that it would be wrong to do complete fallback (as for example Pango does in a last resort) because...

"the glyphs in that font may not be preferred at all, which can make it problematic as a fallback"

I don't think I agree with you even for Han characters where the preferred glyph may be very different for some locales. Outside Han unification I'm quite sure I don't agree. Pango's results seem both more pleasing and easier for users to understand (some characters don't render? just drop a suitable font into the font folder)

We see from today's post that Mike's problem didn't go away. I suspect that he got his wires crossed last time and believed that you were telling him U+2192 should work out of the box.

Also, I don't understand why adding a registry entry for font linking can't solve Yury Zelensky's problem. That looks like an easy one to me, can you explain where it falls down?

# Michael S. Kaplan on 22 Jan 2006 10:26 PM:

I still find the solution of adding EA support to be a little heavy handed, since you are adding a lot of stuff on the disk an more importantly a lot of stuff to the font cache for the sake of a single glyph.

In general, all font linking is heavy handed in this sense, and is often the lazy way to get the suppot (with the additional price being that you never know where the glyph is coming from and whather it is the on you want.

In Yury's case, I would not recommend changing the font link chain for all of the above reasonsx, plus additional ones like:

* not supported

* covers the whole OS and not every app will necessarily be expecting it

* the font cache can get really out of hand, an searching through all those fonts for glyphs is less than ideal

* conflicts with other PUA solutions like symbols, EUDC, HKSCS, an other third party solutions

Explicitly choosing fonts for PUA is a much better solution and much less likely to ever run in to the above problems. And also less likely to be stomped by others using the PUA....

# Dean Harding on 23 Jan 2006 7:25 PM:

I was looking at the IE blog the other day, and one of the commenters pointed out this website: http://us.metamath.org/mpeuni/clim4a.html

If you look at that site in IE, the right arrows show up as boxes, but in Firefox, they show up as proper arrows. I haven't tried the site on a machine with east asian support, so I don't know if that would fix it, but I thought that IE used Uniscribe and all that whether EA support was installed or not?

# Michael S. Kaplan on 23 Jan 2006 8:01 PM:

It appearss that the font being used is Arial Narrow -- which of course does not include most of these characters.

Now I am a huge fan of displaying stuff, but this is hardly a mainstream font to be using. If you copy/paste the text into Notepad and look at it with either Tahoms or Microsoft Sans Serif then it shows up just fine.

IN FACT, if I save that file as UTF-8 and look at it in a browser, it works just fine then, too.

So I would consider this :

1) a page bug -- the page should pick no font, of better fonts, and

2) a FireFox bug -- doing font linking, fallback, or aubstitution when it is not appropriate.

# Dean Harding on 23 Jan 2006 8:27 PM:

Oops, it was the double-struck "C" that doesn't show up properly in IE, not the right-arrow in this case...

Anyway, I'm not sure it's a page bug. I made up a very small page which doesn't specify any fonts directly, and it also demonstrates what's happening: http://www.codeka.com/tmp/double-struck-c.html (I can get the page to display properly if I specify the font "arial unicode ms" for example, but you can't be sure end-users will all have the fonts you expect installed...)

My page uses the method used by that other page (i.e. using ℂ) but it also has the character directly encoded as UTF-8.

It shows up correctly in Fire Fox, but not IE. If I cut and paste the text from IE into Visual Studio, the characters show up correctly (which means VS is doing different font-linking to IE because this is still all on a machine with no EA language support).

So I'm fairly sure it's an IE bug, but perhaps not a Uniscribe/GIFT bug (since VS.NET gets it right)

# Michael S. Kaplan on 24 Jan 2006 12:47 AM:

Hmmmm.... I still have trouble thinking of font linking/fallback/substitution/whatever code that takes a limited, almosr specialty font like Arial Narrow and adding random characters as being a good thing.

I'd feel better if either browser did it for the case where font linking/fallback/substitution/whatever is expected, like in the more general fonts....

# Dean Harding on 24 Jan 2006 1:52 AM:

OK, I can agree with you on the Arial Narrow case. (:p)

But if you look at the source to my sample page, I don't specify *any* font, and IE still displays a box.

I've put some Korean text in there as well, and it does the font linking on that, it's just the double-struck "C" that it doesn't do it for.

Like I said, if I open the .html file in Visual Studio, then it displays the double-struck "C" (and the Korean text) properly.

# Dean Harding on 24 Jan 2006 2:07 AM:

I've uploaded some pics now as well. The following two show both Visual Studio and Firefox displaying the double-struck "C" correctly:

http://www.codeka.com/tmp/double-struck-c/vs.png
http://www.codeka.com/tmp/double-struck-c/firefox.png

And this one shows IE displaying boxes instead:

http://www.codeka.com/tmp/double-struck-c/ie.png

# Yury Zelensky on 26 Jan 2006 9:16 AM:

Thank you for answer. Unfortunately I know nothing about blog of somebody of aouthors RichEdit :)
One more question about registry keys. I've already read about
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink in your previous articles. I understand all negative sides of modification of font linking sequence thru changing registry but unfortunately i can not even try it. There are no such registry key on my Windows XP proffesional.

# Michael S. Kaplan on 26 Jan 2006 10:07 AM:

that means you do not have EA langs installed? You have to install them as the first step....
Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2007/06/09 Guilt by [font ]association (aka The consequences of picking the wrong font #3)

2006/03/18 What about logical fonts?

2006/03/14 GDI Font Linking in GDI+

go to newer or older post, or back to index or month or day