by Michael S. Kaplan, published on 2007/04/14 21:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/14/2137215.aspx
OK, we are getting close to the end of this little mini-series....
First there was a comment from Dennis E. Hamilton asking about the DPI in the screen shots of that first post:
I notice two things here. First, the impact of Cleartype is amazing. Secondly, the Vista rendering seems fuzzy somehow and not as crisp as the XP SP2 Cleartype. I realize the sizes are different, with different assumed resolutions, but the subjective experience at scale is important. (I think I see this on my Vista-equipped Tablet PC too, so I really wonder ... )
If you use the same DPI, how well does Vista match the XP Cleartype case?
I decided to engage in a bit of experimental DPI viewing. I used the funniest string from Why that is positively Ethiopic! (፳፩፼፳፰፻፷፯፼፶፫፻፱) and took screen shots at 96, 120, 134, and 144 DPI (note that I did not change the sample application; I just pasted the string into the TextBox controls):
I'll let you decide on your own about the quality (the code was unchanged so it was trying to use a 32pt size for the font in all four cases).... :-)
Now the additional issues to keep in mind here for font embedding....
First we'll take a look at Nyala's OpenType support from 10,000 feet:
Notice that it does have some OpenType tables that provide support for Ethiopic, though the main reason to consider Ethiopic to be a complex script is for that undocumented sixth reason to be considered s complex script that I described in Font Linking vs. Font Fallback, #2.
The technology provides the selected [subset of the] font and allows you to embed it in your application if the font's licensing restrictions allow it. But it does not give you updates to shaping engines and it does not give you pieces of the font that are excluded by subsetting decisions you might make. In the end, this means that any time the language you are trying to display is a complex script, the proper display might be limited by what the machine itself can support (for an example of this imagine some of the complex scripts added in Vista like Khmer or Sinhalese or Tibetan and try to imagine displaying them in Windows 2000!).
XP SP2 will actually do very well here, much better than one might expect at first. But it turns out that the update to the Uniscribe shaping engines provided by the update I first described in Lions and tigers and bearsELKs, Oh my! included some of the (not completely finished but certainly in progress) updates that eventually made their way into Vista. So you may find you have better luck in XP SP2 then in most other downlevel platforms. But n matter what you will always have the constraint of the platform's support to contend with.
This also applies to keyboards (you'll have to provide them via MSKLC or whatever), locale support (custom cultures, anyone?), or collation (currently no solution for this one, sorry -- so beware this problem!).
You will probably always want to be using .NET Framework >= 2.0 so that you can use Uniscribe and not be limited to what GDI+ supports.
And then when you are done, be sure to call TTDeleteEmbeddedFont as the sample does in its FormClosing event. And in your real world samples you probably should embed the font in your application's resources and then just use a MemoryStream rather than a FileStream to read it (though even is you treat it as a file like the sample does, there is not really anything else that you can do with the file anyway....
As a final note, let me once again remind people to follow the licensing restrictions of the font you want to use. Your font foundry will thank you for attention to your attention to this particular detail!
This post brought to you by ጵ (U+1335, a.k.a. ETHIOPIC SYLLABLE PHE)
# Cory Nelson on 15 Apr 2007 1:32 AM:
Did you intend for the Vista DPI scaling to happen? It looks like those are all being rendered at 96dpi and scaled up as a bitmap.
You need to call SetProcessDPIAware() before you create any windows to make the app truely use high DPI.
# Michael S. Kaplan on 15 Apr 2007 1:48 AM:
In this case, you have the source. So you know that I did not go to any special effort here along those lines, right?
# Dean Harding on 15 Apr 2007 8:45 PM:
> I did not go to any special effort here along those lines, right?
That's why it looks so bad, then. For some reason, Windows assumes that applications, by default, are not able scale properly in high DPI modes and so it does bitmap scaling -- unless you specify in your manifest (or by calling SetProcessDPIAware()) that you scale properly. Even worse, WinForms (and MFC and pretty much every other GUI framework) usually scales perfectly well.
As a quick test, you can right-click on the .exe and in the Properties dialog, check the "disable scaling for high DPI" (or whatever it is called) and try making the screenshots again -- it'll look MUCH, MUCH better.
In my opinion, it should have been the other way around: by default, do NOT do bitmap scaling, but include it as an option. Oh well...
# Michael S. Kaplan on 15 Apr 2007 9:22 PM:
Okay, this is new info for me. :-)
I put up some screenshots at multiple resolutions with that checkbox toggled, you can try them and tell me if you think they look better than the ones in that first post....
# Dean Harding on 15 Apr 2007 10:54 PM:
Yeah, those ones look much better :-)
You can tell if you zoom in on the images. The old ones have two (or more) columns of blue/red pixels, while the news ones only have 1 column (which is what it is supposed to look like).
You can force it to work permanently with that call to SetProcessDPIAware() or using a manifest (though I've never been able to find the documented method for using a manifest in WinForms...)
# Michael S. Kaplan on 16 Apr 2007 12:31 AM:
It is weird though.
Why does the "Custom DPI setting" dialog have a "Use Windows XP style DPI scaling" (which I did not set) if it is going to do the old style DPI scaling anyway?
# Dean Harding on 16 Apr 2007 12:55 AM:
The "old-style" scaling is what you see in the "new" screenshots. The "new-style" scaling is bitmap scaling when you don't have a manifest/call SetProcessDPIAware.
So if you have "use Windows XP-style DPI scaling" OFF then you get the ugly scaling. If you have "use Windows XP-style DPI scaling" ON you get the good scaling. Yes, that means Windows XP had better defaults than Vista (that's my opinion, at least).
It's all a bit confusing. Basically, the bitmap scaling was added in Vista, and is the default (except for a few well-known apps like Office, and ones that have the manifest setting). Bitmap scaling also looks MUCH WORSE than any other kind of scaling...
Alex on 20 Mar 2013 11:47 PM:
Michael, have You archive with this project? Put it to sendspace.com please! Hosting is dead now..
Thank You!
Michael S. Kaplan on 21 Mar 2013 12:34 AM:
Sorry about that! Fixing now...
referenced by