Hmm ... it seems that these settings are not system wide, and only apply to WPF applications. Does anyone know why the ClearType Level setting cannot be applied to the old, non WPF version of ClearType?

WPF Blog Article

Interestingly, Adobe has also gone away from having lots of user-configurable control, in favor of a default setting that seems to work quite well in the large majority of cases.

I'll note that as best as I understand it, ClearType in WPF is a distinct animal from both the Vista and XP versions of ClearType.

T

Hi,
WPF uses a different method of ClearType text rendering compared to older Windows components such as GDI and GDI+. The new method allows more precise control over gamma correction, text contrast and the amount of color used.

By the way, we recognize that the current situation is confusing, and your feedback is important to us.

Please let us know if you have any specific concerns, and best regards!

Mikhail Leonov
WPF Text team, Microsoft Corporation

Thomas and Mikhail, thanks for the responses. The documentation I was reading says that WPF replaces Avalon, which I thought was supposed to be the core windows component of Longhorn. But it was decided to separate Avalon so that it could work in either XP or Vista. Does this mean tha, as OSs, both XP and Vista only can display using GDI/GDI+, while the this new ClearType only is usable with applications spicifically written using WPF? Why is it not possible to modify the ClearType system in GDI to take advantage of the improvements in the WPF ClearType? (he asks, expecting a simple answer.)

Sure, here is a bit of history.
Avalon was an internal codename for what is now known as WPF. Originally Avalon was supported only on Longhorn, but after receiving developer feedback about the importance of being able to ship Avalon applications on XP, a decision was made to support Avalon on XP as well.

Note that Vista includes WPF in the box, so on Vista WPF applications are supported just as well as GDI+/Windows Forms applications. External developers are already starting to take advantage of the platform. Apart from well publicized applications such as NY Times Reader, there are other examples at http://msdn2.microsoft.com/en-us/netframework/bb330852.aspx. This situation is somewhat similar to XP being the first OS to include GDI+, which can also run on Windows 2000.

Now, GDI is somewhat special, in that it's a very mature and widely used technology that's been available on Windows pretty much from the beginning. Because of this, any changes made to it have a risk of introducing compatibility issues with existing Windows applications. This alone makes it quite risky and expensive to modify the way it does things. Having said that, technically it's not impossible to improve ClearType in GDI, it's just that the costs are pretty significant.

While I cannot commit on any future improvements at this point, my team is very interested in hearing your feedback, please keep it coming.

I hope this helps, and best regards,
Mikhail Leonov
WPF Text Team, Microsoft Corporation

Wow, those WPF applications run really slow! I've been running an old 700MHz computer since my 2.4GHz system died, and running these sites is like try to browse a Flash website with a 100MHz cpu! I also noticed that Expression is super slow is well; I guess this is the price we have to pay for a new display subsystem?

Anyway, thanks for explaining this about WPF and ClearType, as it's difficult to piece together the history from all the literature online.

Even though I find the text much more readable with ClearType on than off, I was initially just wanting to know if there is a way to adjust the colour settings because, at least on my LCD screen, the colour fringing is a bit annoying. Not annoying enough to not use ClearType, but annoying enough to want to modify the colour settings. Is the problem that the version of ClearType in GDI simply cannot support changes to the color setting? If it doesn't, I can see why it would be costly to change, as it would likely require rewriting the entire way that ClearType works. Or maybe it's the kind of thing which could be changed fairly easily, but ensuring that the changes will work with every configuration of hardware and software out there would be extremely time consuming and thus expensive.

I just want to make sure I have this right: the new features in WPF ClearType such as improved character spacing, greater adjustability, and Y-direction anti-aliasing will never make their way to being OS level improvements in either XP or Vista, and that these improvements will only work with the super-slow WPF-coded apps?

Hi,
what is the video card and the amount of RAM on your old 700MHz system? These two factors are usually more important than the CPU speed for WPF rendering engine. For example, WPF engine requires a modern video card for hardware acceleration. This doesn't have to be the very newest card, even a 2 year old card like ATI Radeon 9800 Pro is usually sufficient. In the absence of a modern video card, WPF has to use a slower rendering logic.

As of Windows Vista, the version of ClearType in GDI does not support the color amount adjustment.

One thing that can noticeably help with both GDI and WPF is using new fonts that have been hinted for ClearType rendering. For example, "Segoe UI", "Verdana" and "Calibri" look great. On another end of the spectrum, condensed faces at small sizes usually show color fringes.

I cannot comment on the future changes in Windows and WPF at this point. In particular, I can neither confirm nor deny possible changes in the text rendering engines.

I can, however, assure you that we do listen to the customer feedback like yours, and it's much appreciated.

Best regards,
Mikhail Leonov
WPF Text Team, Microsoft Corporation

Mikhail,

As it turns out I have two video cards, both of which are very old and so do not contribute much in the way of acceleration. One is a Matrox G550 and the other is an nVidia GeForce2—both are ancient.

You're certainly right about the ClearType fonts. I have them installed via the Office 2007 compatibility pack and they are excellent. I actually can run the monitor in analogue mode and colour fringing is not as evident. But on DVI mode it is quite noticeable. It might just be because these video cards and my monitor are so old that I have this problem. Someday I will be able to upgrade ...

There is also considerable variation between individuals in their sensitivity to color fringing. Some people just notice it and are bothered by it a lot more than others.

T

"One thing that can noticeably help with both GDI and WPF is using new fonts that have been hinted for ClearType rendering."

Can you explain what it means to be "hinted for Cleartype rendering"?

"External developers are already starting to take advantage of the platform."

Do you know if any developers are working on either bringing integer spacing to an app that uses OT, or working to bring OT to an integer spacing app, or does this already exist somewhere?

Cheers!

David,
by that I meant that a font designer made an effort from the start to make glyphs look sharp, aligned and legible at screen reading sizes when ClearType is enabled. Fonts from this collection http://www.microsoft.com/typography/ClearTypeFonts.mspx were made this way. In the past, screen reading fonts were often hinted and tested only in aliased mode.

Could you please clarify your second question? I'm not quite sure how integer spacing is related to OpenType.

Thanks for your questions, and best regards,
Mikhail Leonov
WPF Text Team, Microsoft Corporation

Can you explain what it means to be “hinted for Cleartype rendering”?

I'd say that 'hinted for ClearType' can mean a number of different things. For example, Mikhail mentioned Verdana earlier, which was obviously not hinted for ClearType in an intentional sense because ClearType did not exist at the time Verdana was made, but it is hinted (and designed) in a way that happens to work very well in ClearType rendering.

Then there are fonts like those in the CT collection, which were designed around the sub-pixel rendering model used in ClearType, and hinted according to a particular model which involves very little x-direction hinting and instead allows the renderer to largely control things in that direction. [The final shipping versions of these fonts also contain some greyscale-specific hints, largely because Word 2007 turns of CT above a certain size in order to get smoother horizontal curves. WPF, on the other hand, implements the newer CT model with integrated y-direction anti-aliasing.]

Then there are fonts the like of which I have never actually seen, which have the INSTCTRL selector flag 3 set in order to have the renderer apply the full TT instruction set including x-direction deltas, allowing the hinter to control the x-direction rendering much more precisely than in the default CT setting. This could be very cool. And also a lot of very fiddly work.

Then there are fonts like the ones David is making, which conceivably wouldn't need any hinting at all, with outlines designed to produce an ideal screen rendering at specific sizes.

"Then there are fonts like the ones David is making.."
I've got some Instructed ones but the results in non-integer-spacing apps are not readable over time compared to the benchmarks, one of which John refers to.

In a week that saw the demise of both Don Imus and Don Ho, I must ask what fiddy is?

In integer spacing apps I can get the Instructed font up to nearly the quality of the benchmark as I show below. But, I'm trying to go further than the benchmark, which requires an integer-spacing app, using magic type and loving OT.

!!! CRT Users avert your eyes!!!

" I’m not quite sure how integer spacing is related to OpenType."

Then I will be delighted to answer your question with a specimen when I am able. But right now: Do you know if any developers are working on either bringing integer spacing to an app that uses OT, or working to bring OT to an integer spacing app, or does this already exist somewhere?

Cheers!

hello david,

can you please give some information about the sample above - what's the difference between left and right columns?

thanks,
- gustavo.

David,
I'm still not clear on your question. By "integer spacing", do you mean pixel dependent line layout, where glyphs are laid out according to their resolution specific metrics (as opposed to device independent layout used by WPF, GDI+ and Microsoft Word)? If yes, I would think an application that uses OTLS and Uniscribe (https://www.microsoft.com/typography/otfntdev/intro.htm) should be able to support OpenType features while retaining control over precise glyph positioning, but I'm not aware of any specific examples.

May I ask why you would like to know this? Is your goal to make sure newly created fonts have good OpenType support in both classes of applications, scalable and non-scalable?

Best regards,
Mikhail

This video is probably not going to teach anyone here new things about ClearType, and it is a bit old, but it's still interesting to hear Bill Hill discuss developments and history of ClearType. He mentions at one point that they have ClearType version 7, but alas it is only supported in WPF apps.

I've come to realize that I'll need a higher dpi display to get the best results from ClearType. I got my 15" LCD (85ppi) when they were quite new, a top-dollar MVA (30ms!) model which was "state of the art" at the time. The articles I was reading then suggested that "Longhorn", which was expected by 2005 [!], would be resolution independent, encouraging the development of 200dpi+ monitors. But there has been no development in this area since IBM developed that 200dpi display back in '98 or so. (The only one I could find outside of laptops and PDAs is Eizo's R31) I'm beginning to wonder how the transition will work from 100dpi to higher—since the OS and most apps still rely on bitmapped interfaces which won't be usable at those ppis—and whether we'll begin to see high ppi screens in five or even ten years!

"I’ve come to realize that I’ll need a higher dpi display to get the best results from ClearType"
That is best, if you can afford it, a simple climb up the resolution latter is what I'd do too, if I was not committed to the whole market.

"what’s the difference between left and right columns?"
That's what you're supposed to tell me!

"I’m not aware of any specific examples."
Bummer. I would be nice if both reader and explorer used OT and integer spacing just about NOW! Oh well. Time to make the browser, ;)

"May I ask why you would like to know this?"
It is my pleasure to answer thus:
Human readers are accustomed old style. Old Style has serifs. Spacing serif fonts (at low res), is easily disturbed by even a 1/3 of a pixel in the "wrong place"

So integer spacing is best, but not required for type to superficially look readable, I guess.

So, back to my font: It is serif, it is cleanly drawn and carefully hinted to produce precise spacing only. Thus, I know at every size where every "1/2" pixel is missing or extra. E.G. I know that the single-serif-on-the-left-side of the letter letters j p and u, can be treated when they meet single-serif-on-the-right-side of the letter letters like u. There are near 100 combinations like this in the specimen, that if treated with contextual subsitution will bring us as close as we'll get to print, without the timber or universal resolution upgrades. Then, and only then, there are ligatures to add. ;)

So if someone says, "Let's make explorer subpixel position CT", please kiss their ass goodbye. But if someone says, let's add OT to Explorer, or make a integer spacing mode for the Reader app, kiss their ass for me.

Cheers!

I just found this blog entry which compares to screen captures, one taken with WPF ClearType and the other with GDI Cleartype. The GDI version is clearly sharper and has better contrast. I did a screen grab of my own, comparing a menu from IE and one from Expression Blend (a WPF app). I guess I don't need to worry about "upgrading" after all—the new version looks awful with Segoe UI! (Unless Expression is using some strange almost-Segoe font, in which case the comparison isn't fair.)

Also another interesting link: WPF Text Blog.

That's weird, WPF-rendered text is supposed to look fantastic, like this and this. Mikhail, does the quality of rendering—not just the speed—depend on the video card?

Hi,
WPF uses different rendering logic for older video cards, but in general the quality should be comparable to the newer video cards.

How does the PI newsreader application look on your machine?

You can download it from http://seattlepi.nwsource.com/newsreader, registration is free.

In case WPF V1 text looks blurrier than GDI for you, this excerpt from a post I made on the subject in MSDN Forums (http://forums.microsoft.com/msdn/showpost.aspx?postid=1376773&siteid=1&s...) may be helpful:
"The fundamentally complex problem of linearly scalable layout and rendering of small text on low resolution devices is well known in the industry. Various software products have tried different approaches to solve this. Since hinting and rounding involved in rendering small characters necessarily affects letter spacing, all approaches I'm aware of involve compromising between vertical text stem sharpness and character spacing. The first released version of WPF uses a subpixel positioning algorithm that places characters very close to their lineraly scaled positions at the expense of varying the vertical stroke sharpness.

Other software products use their own unique techniques - a good exercise is to compare how the same text snippet is rendered in Notepad, Word, Visio, WinForms, Adobe Reader, Apple Mac OS X, Adobe Flash, etc.

While I cannot elaborate on the future changes in WPF at this point, I can list some simple things that help the appearance of text in WPF today:
1. Use modern Vista fonts hinted for ClearType rendering.
2. Use font sizes larger than 8pt for Latin text, and larger than 11pt for East Asian text.
3. Use higher contrast text foreground/background combinations.
4. Use displays at their highest native resolution that possibly allows enabling the high DPI Windows setting. This especially helps with latest laptops, where 120dpi is quickly becoming a norm.
5. Make sure text rendering settings are tuned with the ClearType tuner."

Please let me know how it goes, and best regards,
Mikhail

"How does the PI newsreader application look on your machine?
You can download it from http://seattlepi.nwsource.com/newsreader"

It looks pretty good really, but my point is "How does it Read?"

First, there are 5 choices for size:
1 is too small for me.
2 is okay
3 is a little big
4 is way too big
5 I can't tell, I must be too close or something.
A denser granularty of size availability would help both this issue, and the next one I show you.
!!!CRT FOLK DON'T LOOK!!!

Despite the fact that you can barely "see" this at actual size, it is there when you read it. All letters should repeat. All stems that were the same color in the type should be the same color(s) pattern in the font. Zoom up my benchmark if you need to see what that looks like, hinted fonts should do this.

This application, should it get better in the lower resolutions, will need integer spacing and more selection of sizes for the user. I read a reader for over two months before going back to the hideousness of the web version of the same paper, where I could control the font style (to mine). Columns, logos, nice headline fonts! and hyphenation are great!, but it is called a "Reader."

Cheers.

David: Despite the fact that you can barely “see” this at actual size, it is there when you read it. All letters should repeat. All stems that were the same color in the type should be the same color(s) pattern in the font.

I'm not convinced that this is universally true, although there is obviously a threshold at which differences in rendering become differences in density (as happens much more obviously in Adobe and Apple subpixel rendering), which I do think is a problem. I've read a lot of books printed using a lot of different type and press technologies from the past 250 years -- and I have lots of earlier ones too, but tend not to read them because my Latin and Greek aren't that good -- and one thing I can say about pretty much all of them is that it is very, very rare for letters to repeat, i.e. for the 'rendering' of the same letter to be identical more than once. The range of factors affecting how letters differ in print -- worn sorts, inking, impression, press speed -- is much greater than anything affecting the variation in sub-pixel positioning.

The image below shows a sampling of the letter a on one page of John Baskerville's edition of 1760 edition of Milton. The range of variation across multiple pages is much greater, due to differences in inking and impression, even considering just how good a printer Baskerville way.

I think what is important is not repetition of form, per se, but specifically repetition of density. If what you are saying is that at low resolutions the variation in rendering in ClearType is producing unacceptable variation in density, then I'd be inclined to agree with you if I were not using a 145 ppi screen. I find CT rendering problematic at less than about 115 ppi, specifically because of density breakdown: the pixels at those sizes are large enough for the stroke contrast to be degraded. CT still looks better than greyscale antialiasing of small type at such resolutions, but not as good as b/w bitmaps. I find that on my little Panasonic laptop (96ppi) I turn CT on and off quite frequently, depending on what kind of work I am doing.

So I don't think the problem is non-repetition per se.

By the way, David, what application did you use for the left-hand specimen of the Cambria rendering in your last illustration but one?

“what’s the difference between left and right columns?”
That’s what you’re supposed to tell me!

ok, i'll give it a try:

the first sample shows one of your ‘gridfitted-by-design' fonts.

left column shows it with instructions (for spacing only?), right column without...
...or is it left == text in an integer-spacing-app, right == text in a non-integer-spacing app?

(the left sample looks better to me: stems and serifs look darker, the overall appearance is slightly heavier and softer [but 'x' is a bit too heavy]. text on the right looks a bit 'broken' to my eyes.)

the second example shows cambria in a non-integer-spacing-app on the left, and in a integer-spacing-app on the right. (right sample looks much more pleasant to read to me.)

So, back to my font: It is serif, it is cleanly drawn and carefully hinted to produce precise spacing only. Thus, I know at every size where every “1/2” pixel is missing or extra.

"at every size?" so the font is supposed to be scalable? i thought your method was about making masters for each ppem size...

There are near 100 combinations like this in the specimen, that if treated with contextual subsitution will bring us as close as we’ll get to print, ...

i don't get it... contextual substitution?! are you saying you want to have different versions of the same glyph, instructed/spaced differently, selected according to the context? this sounds crazy. if the goal is to adjust a pair of characters, why not use kerning pairs? (because the font is scalable and the adjustment is ppem-specific?) i must be missing something... (your sense of humour?) :-)

i really want to understand this, any clue would be appreciated... thanks.

For anyone who didn't realize it (e.g. me) here is a related conversation from 2006 on the topic of ClearType:

CT Design Guide (Thread on Typophile Forum 6)

John, what monitor do you have that is 145 ppi? I thought only PDAs go that high? Dell's laptops only seem to go to about 133ppi.

Let me add my two bits in hopes that it sheds more light than it adds to the confusion.

Most of what we do with text is in some way or other integer-based. TrueType fonts start out from advance widths designed in integers, and end up on devices made up of an integer number of pixels. The problem is that, once these advance widths are scaled down to a targeted type size and device resolution, they are non-integer. What to do with this intermediate state?

Method A: Round the intermediate advance widths to the nearest integer and lay down one rounded character after the other. Since some characters may round down, while others may round up, one would think that, on average, things will work out by the end of the line. In reality, sometimes it does, but sometimes it doesn’t.

But why does this matter? For short, whenever an exact translation of the length of a piece of text from the designed world to the device world is important.

Take, for instance, a short caption of an icon or a window title. Translate the designed length of the caption into pixels, separately add up the rounded advance widths, and compare the two numbers. Maybe, by separately adding up the rounded advance widths (i.e. by laying down one rounded character after another) you end up with a few more pixels, or a few less, due to all the intermediate rounding, but hopefully you can still fit the text into the window title or somehow arrange it underneath the icon.

Dialog boxes and menus are a slightly different story. You’ve probably all seen a dialog box that was jam-packed with items, but that just about fit the smallest acceptable form factor (“designed for 640 x 480” or such-like), because at that particular type size and device resolution, it happened to “add up to a few pixels less.” Now display that same dialog box at 120 dpi, instead of 96 dpi, and be ready for an unusable or at least unaesthetic dialog box, because at 120 dpi it happens to “add up to a few pixels more,” and dialog elements get truncated (assuming the jam-packed control panel was aesthetic, in the first place, but that would be another thread).

Browsers, word processors, and presentation software are another story. Imagine you’ve just spent the whole day working on your résumé and push the print button to send that résumé to a potential employer. Most likely your printer has a different dpi than your screen, and hence your printed résumé may reflow using Method A—probably not to your liking. Similarly, imagine you have spent days on an important presentation for a potential customer and are about to present using your customer’s projection device. Another candidate for reflow. Browsers seem to more or less “naturally” reflow, yet most web-sites are designed like dialog boxes—in pixels—with results well known to anyone who has ever tried to use the www at a dpi in excess of 96.

Enter Method B: Round the intermediate advance widths to the nearest integer, but separately add up the designed advance widths, and translate the designed partial text lengths into pixels after each character. As discussed in Method A, these two numbers may or may not be the same, but here is where method B differs. If the difference between the two “adding methods” exceeds a set threshold, then adjust the positioning of the characters to what you got from translating the designed partial text length into pixels. Like so, you can easily take your document, presentation, dialog box, web-site, whatever, from one device to another, from your 96 dpi desktop to your 120 dpi laptop or 1200 dpi printer, and it will always look the same. No reflow, no truncated dialog box elements, it “just” works.

But it comes at an enormous price, typographically speaking. You have lost control over inter-character spacing. Now, one might think that, in a piece of text that consists of more than one word, it should be possible to “absorb” the difference between the two “adding methods” in the inter-word spacing. In other words, use Method A for the length of the word, switch to Method B for the blank between two consecutive words, and we’re “re-sync’d” to Method A at the start of the next word. In reality, sometimes this works out just fine, but sometimes it doesn’t: one word runs into the next, all but obliterating the blank, or even partially overwriting the next word, hence Method B. Depending on your luck, or absence thereof, text looks like the “Goosefoote Bridge” described by David Berlow (or even worse—by the time I notice it myself it’s usually a typographic disaster).

Enter Method C: This method assumes that we have a rendering method other than strict bi-level (black or white), such as ClearType. In ClearType, we imagine we can break up a pixel into an integer number of “virtual pixels,” we render characters as if we actually had that many virtual pixels, and we finally translate a set number of virtual pixels into an RGB value. Along with that comes the opportunity to use Method B applied to virtual pixels, instead of physical pixels. We still make “adjustments” every so often, but each time we adjust only by a “virtual pixel.” This method is often referred to as “sub-pixel positioning.” Notice that the word “sub-pixel” may be ambiguous, since on an LCD the physical pixels are (physically) partitioned into three sub-pixels, having the colors red, green, and blue, but we can readily imagine (and implement) a virtual pixel size that is a fraction of the physical sub-pixel.

Again, this comes at a price. In Method A, we can optimize each vertical stroke to look its best (“sharpest”) in black-or-white, standard font smoothing (a.k.a. grey-scaling), ClearType, etc. We’ll simply forward any rounding errors incurred in the process to the right side-bearing point. Let the advance width adjust to the sum of the positioning errors, since we’re going to place the next character strictly adjacent to where the previous character ended. In Method B, we could do these optimizations, but at the risk of exacerbating the “Goosefoote Bridge” problem. In Method C, we simply cannot do any of these optimizations (and hence cannot use black-or-white) because we don’t know upfront at which “virtual pixel” within a physical pixel a glyph will start, once laid down to the device. In other words, at small type sizes and low resolutions, it may look blurry (or whatever your preferred taxonomy may yield as adjective here).

It’s a case of can’t-have-your-cake-and-eat-it-too, and a whole palette of cases in-between and beyond. Use Method A in hopes that the application handles reflow and dynamic layout gracefully or intelligently. Use Method B in hopes that the font’s hinting hasn’t made it deviate too much from its designed advance widths. Use Method C in hopes that the device resolution is high enough that it doesn’t look too blurry.

In hopes that this helps to disambiguate, Methods A and B could be understood as integer spacing methods, while Methods B and C could be understood as linear spacing methods. Consequently, in that sense, Method B could be understood as a linear integer spacing method. Methods A and B position character to full pixel boundaries, while Method C positions characters to fractional pixels. Likewise, while all three methods may be understood as scalable, Method C is the closest approximation to linear scalability.

I assume David Berlow has developed a method that could be described as a variant of Method A that goes beyond individually optimizing vertical strokes of individual characters. Optimization of a (last) stroke of one character, when placed adjacent to another character with a similarly optimized (first) stroke, may depend on the particular pair of characters involved in the optimization process. If this can be handled by contextual glyph substitutions, if the world at large would stop printing their résumés, if the web-designers at large would stop designing their web-sites to pixels, and if the software designers at large would start designing their software for intelligent layout/reflow, this could be the solution for today. After all, who wants to kill all those trees if they could be saved by software, and what’s a page, anyway, when my screen likely is not the same size as yours?

Until we’re in “Avalon” (no pun intended) there may be some transitional pains. Notepad and the browsers use Method A, but few web-designers are aware of pixel-independent layout, and probably even fewer software designers are familiar with intelligent document layout and reflow (not that I would call Notepad a document editor to begin with). Word and PowerPoint use Method B (or a variant thereof), but few customers are aware of the limitations of linearly scalable layout and rendering of small text on low resolution devices—they’d merely interpret reflow upon printing as a serious bug. WPF uses method C, but few display devices have a sufficiently high resolution to make the potential blur a moot point for everybody.

Some people are ok with the blur in Method C, some aren’t. Anecdotal evidence suggests that some people are fine with Method C when reading continuous text at 96 dpi (e.g. Times Reader, etc.) but not in UI scenarios. Many people are fine with the colors of ClearType, even at 96 dpi, but a few aren’t. John Hudson writes how he switches back and forth at 96 dpi, but not at 144 dpi. I’m experimenting with grey-scaling down to 8 pt at 96 dpi, with vertical stroke positions optimized for maximum contrast, and often find it easier on my eyes than unoptimized ClearType at the same size and resolution.

There’s no silver bullet that I could see (not that I ever liked bullets in the first place). What may be optimal for one person doesn’t work at all for another. What looks nice may not “read nicely” even to one and the same person. In that sense I can easily agree with both David Berlow and John Hudson. To my eyes and at 96 dpi, Method C doesn’t read as well as Method A. It reads “blurrily” to me. Conversely, at 144 dpi, I don’t see a problem with Method C. It looks and reads just fine to me. Comparing Method A and B, as posted by David Berlow in another thread (http://typophile.com/node/32774), I have a harder time. It may depend on the font, hinting, and ppem size. In the posted example, Method A (left) looks nice, but doesn’t read like entire words to me. Conversely, Method B (right) reads more like entire words to me, but doesn’t look as nice as A. It’s as if, in an attempt to make stems repeat and serifs space, the words are spaced out a tad too much (left). Mind you, these are the words of a physicist and the eyes of an ophthalmic anomaly.

About repetition and John Hudson’s example of John Baskerville: Reminds me of Robert Bringhurst, my MIDI drum machine, and Theophrastus Bombast von Hohenheim (a.k.a. Paracelsus). Bringhurst suggested, if I remember correctly, that rigorous or stubborn repetition may make text look lifeless. These are merely my words, mind you, with limited typophile eloquence, and with limited typographic knowledge. But it reminds me of the “music” my drum machine can make. On all but the dullest techno rhythms, I would consider it a glorified metronome, but not a drummer. On the other hand, it is way better at keeping time with the beat than a beginner drummer. Like Paracelsus said: It’s the dose that makes the poison.

Hope this helps, Beat

P.S. for J P Knox: the monitors John Hudson and myself are looking at are Dell Inspiron 8500 laptops, 15.4” diagonal, 1920 x 1200 pixels. I got mine in 2003 and love how text and photos look on this screen. Many web-sites are another story (including typophile.com—given the type size I see on screen I strongly suspect their css specifies the font size in pixels. So much for scalability).

Beat, thanks for joining us, I was feeling outnumbered ;) I will read 'n respond seperately to yours, but wanted to post my responses from above yours first...

"I’m not convinced that this is universally true"

..nor did I say it was. But whether you like it, know it, feel it, believe it understand it... or not, what many readers of Latin Script apparently expect is my type, my text, my quality.

"The image below shows a sampling of the letter on [] one page of John Baskerville’s edition of 1760 edition of Milton. The range of variation across multiple pages is much greater,"

lol. Oh? I'm interested in the relationship between letterpress and Cleartype John, but not now, because the difference 'twixt a book printed when America had a King and what we are seeing here in CT with non-integer spacing are, in Reality is not related.

None of that is even to the point, that the use of a subpixel positioning application to bring news text to users is unnecessary and inferior. I have a Constantia proof that shows this at 144 dpi 12 pt. if John's acuity rises, then I will show him.

(I'm wondering by the way, if John has decided whether he likes Cambia or Constantia more these days. A year ago you c o u l d n 't d e c I d e. Now that I've looked closely at the two in CT, I understand why. . . Cambria is for all intents and purposes the condensed of Constantia at small sizes. Duh.)

Meanwhile our friend Leonid can help proof, if he is courageous and truly wants to "know" by setting 3 ppg of Cyrillic and showing them side-by-side, integer and subpixel positioned. This will bring to the fore how lucky we are in Latin Cleartype, lol.

Google advanced search "Hate Cleartype";

"Frankly, I hate cleartype in Vista, no matter how you've tuned it. It is blurry - in fact, cleartype is nothing more than a sophisticated application of a ..."

"Not because we either love or hate cleartype (and there are definitely camps ... Lesse, we hate cleartype because we find the fonts already used to be crisp .."

"Personally, I hate ClearType since the text looks somewhat blurred IMHO. "

"I must say even with a good clear LCD monitor I still can't stand that ClearType font. Just way to blurry for my liking. I have downloaded the Windows ..."

"I don't know caffenero, I hate ClearType with a passion. It looks a bit better on LCDs than CRTs, but in both cases it's inferior to my eyes. ..."

"I hate cleartype. I've been using computers for 20 years and that one of the worse *forced* regression I ever had. I am hyperopia and I use a 24" vertical ..."

"I hate cleartype. It gives me a headache. I must be in a small minority. Vista lets me turn off cleartype but all the type still looks awful. ..."

I didn't ask for any of this. I don't agree with some of it, but I know
e x a c t l y where it is coming from, I know how to fix it and I intend to try. I think it's only because I'm not a sacred cow herd, but we'll see.

And, to be fair: "Hate Cleartype" found only 315 while "Love ClearType" found 1,210. But has this EVER had to HAPPEN BEFORE!?

Cheers!

ohn, what monitor do you have that is 145 ppi?

It's on my Inspiron 9100, which seems to be discontinued (I've had a heck of a time ordering a spare power adaptor for it). It's a 15 inch monitor that natively runs 1900 x 1200 (UXGA?)

DavidL None of that is even to the point, that the use of a subpixel positioning application to bring news text to users is unnecessary and inferior.

Basically, I agree, but I'm glad that people are experimenting with these things and maybe someday someone will actually deliver an improvement. I downloaded the Seattle PI Reader, and the nicest thing about it is the gorgeous rendering of the sans headline with x-direction CT and y-direction AA (for which we have Beat to thank). And I like how the headline browsing pages are presented and find them easier to review than e.g. a straight browser list. But I find the text type fuzzy even at 145 ppi, in ways that I don't find most XP ClearType rendering fuzzy, and I think this is in large part due to the font, which I think is too light for the purpose.

I have a Constantia proof that shows this at 144 dpi 12 pt. if John’s acuity rises, then I will show him.

I had to look up acuity in the dictionary again just to make sure that I correctly understood what you meant. Let' see it.

Beat said"
"who wants to kill all those trees if they could be saved by software, "

Exactly — I'm in a place a little further down the road now, thought trees continue to stand behind everything I say here. Microsoft Corporation has created a domestic demand for a kind of product (120dpi and up screens), not made in the US. The place where the products are made, needs the product more than "we" do, typoecologically speaking, imo. So, I'm working on solving the problem of news text with the generous resolution of 96 dpi in readers and I think it important to a couple of things that we don't encourage the US/latin market to run out and buy more resolution to solve a (typotechnically) unrelated problem. :-o Don't you!?

"it is the gorgeous rendering of the sans headline"
I agree whole fontedly. Even at 96, these look sharp but smooth, which is the trick!

"... I find the text type fuzzy...[at 145!] and I think this is in large part due to the font, which I think is too light for the purpose."
I don't think I can find better example of the problem not being in the font's contour. :-)

Do you know if any developers are working on either bringing integer spacing to an app that uses OT, or working to bring OT to an integer spacing app, does this already exist somewhere, or are "we" going keep going in a direction of increasing dept, decreasing Oxygen, while proudly showing the world how "good" autohinting can be?

Cheers!

Ah, Publisher. Which version? I presume the WYSIWYG algorithm used in Publisher is similar or identical to that used in Word. In any case, I believe they are both examples of Beat's 'Method B', and really alarming when it comes to spacing.

If you're looking for a method to apply OpenType Layout in a browser, this is the sort of thing that Michael Jansson was doing at Glyphgate. But none of their websites seem to be live anymore.

"Ah, Publisher. Which version? "
Are you saying this might not be the first version?;)

I don't find WYSIWYG type alarming unless it's being applied to a reader-like application. In such cases (i.e. some idiot has a reader to print his paper from), the application wildly reformats the page for printing anyway, so you couldn't call the situation WYSIWYG anyhow. (the user can e.g. have the window set for anywhere from 2 to four columns, and no one cares where or on what page the text ends, it's all done on the fly, there is no reflow issue because flow is always free. So, why make it WYSIWYG? I'm confuseD. But that's not quite all...the reader is too. It's printer services exhibit something I have never seen in any implementation of printing in nearly 30 years...the user cannot edit the "page range" to be printed, it is an "all-or-nothing" per article choice. Not a huge deal, but the fact is, if the printer can't offer the user a choice of pages to print, it's not likely that the user cares what is on which page, and thus, WYSIWYG does not exist as an intelligent motive for screwing up the type on the screen, even if only a little bit.

Cheers!

Indeed, and this is something I've often expressed, to general derision.
Except when the user happens to be a graphic designer doing a mock-
up of a print document, WYSIWYG is anti-user.

hhp

Are you saying this might not be the first version?;)

David, what do you mean by 'Publisher'? I presumed you meant MS Publisher, part of the Office suite, which is several major releases old (and hilariously still applies manual kerning as absolute units independent of type size). There's an interesting process by which applications that largely stand still between releases can actually be said to regress, at least relative to the expectation of improvement.

Agreed, when text re-flows by concept, I don't see much need to attempt WYSIWYG. With intelligent flow, WYSIWYS and---if your conscience allows you to push the print button---WYGIWYG. This leaves methods A and C, or variants thereof, the choice of which should be by user preference much like the text size.

"choice of which should be by user preference much like the text size."
Bless you. But before the user even has a preference, I think the application should make the executive decision of whether to default to a screen purpose or a print purpose that is correct, and then let the user screw it up from there if they so desire.

"you meant MS Publisher,"
I do. I thought I had left InDesign for a younger woman?

You left out Corbel.

It isn't divining by trial and error that alarms me, it is that the kerning units are points, and they're independent of the type size. So if you reduce the space between two letters by 2pts at 24pt, and then decide to change the type size up or down, the kern adjustment becomes larger or smaller relative to the type size.

Thanks, I'll add Corbel...do you know it's magic size(s)?

"...that the kerning units are points, and they’re independent of the type size."

Do you mean one can kern independent of point size? ;) I know what you're saying, but something is better than nothing. Besides, though kerning is in points and independent of type size, type size itself is independent of points, or so I heard here once.

This, and yet another customer for a mythical scaleable outline, has got me writing and composing type on that again, so I'm not here for long.

At the core of "it" seems to be a serious series of misunderstandings e.g. what should be treated (programatically), as an absolute number, (and then: absolute to what, Must be Correct), versus what should be treated as a percentage of the EM, and always treated as such, carefully. "It" is the sprinkling dysfunctional typographic inklings hither and yon throughout Vista its apps. and fonts. I'm not sayin' this stuff doesn't exist on the Mac, in non-ms applications, or anything like that. I'm just not aware of it being unsolved in so many improvable ways, nor am I aware of so much that seems not to be solveable in so many unimproveable ways.

This kerning issue? is one of ITS milder inklings, a single kick to da proper corner of da chase, (though the paycheck of that particular coder's management comes to mind) should solve it. In the font appearence issues I've been talking about, the CT collection is the Cream-of-the-Crop, the Top-of-the-Heap, and the tip-of-the-iceberg, (and the sizes shown here are the cream of that crop). The windows font menu, unfortunately, is chock-full-o-fonts and before I can get to this all, I need to weed out all that stuff in the way.

Cheers!

Thanks, I’ll add Corbel…do you know it’s magic size(s)?

Sorry, no. And of course, since you're presenting magic sizes in terms of points rather than ppem, what are magic sizes for me might not be for you or for someone else with a different screen resolution.

"what are magic sizes for me might not be for you or for someone else with a different screen resolution."

or...in fact, you might say, unless you use 96 dpi devices, (or lower), there may be "No Magic for You!" ;) (as your device/OS/application combination might deny you the ability to point at a particularly good ppm size in particular...). But who wants to be known as a ppm killjoy.

Cheers.

Actually, David, it's 'No Magic for You'® :)

Do you mean one can kern independent of point size?

See, it's a feature. Unfortunately, most of your other complaints might be similarly 'featurised'.

"See, it’s a feature. Unfortunately, most of your other complaints might be similarly ‘featurised’."

I was afraid of that. I read a rumor that the true motive of unicode is to get everyone down to just using 1 glyph.

Bah, Legros & Grant did that ages ago!
http://www.themicrofoundry.com/ss_uniglyph1.html

hhp

ClearType, in XP and Vista
http://www.irepliquemontresluxe.com
http://www.replicaorologi4it.com

I have to do a report for our school magazine on this topic, and your blog has been beneficial. Can you please add more reference to this point, thanks. 247 Virtual Assistant

It's been 8 years. have you solved it. thnks
Mr Homestay

Here at Toronto Secure Locks we offer an unbeatable fast Professional
Locksmith service, so if you’re locked out, need your locks changing
or replacing or even need a safe opening we can help any time of day,
we also provide an Access control, CCTV

http://yorklocksmith.com/
http://0544342878.com
http://mysaite.ru

הרודס מפורסם והארווי ניקס, וברים ומסעדות בשפע כמו בודהה בר
וסן לורנצו, שם לעולם לא נהיה מחסור במקומות ללכת. ובכל מקום
שאתה הולך אתה תהיה מוקף בתזזיות וזוהר זה שם נרדף לאזור.

http://escorts4you.me
http://escorts4you.biz
http://escorts4you.info

Here at Toronto Secure Locks we offer an unbeatable fast Professional
Locksmith service, so if you’re locked out, need your locks changing
or replacing or even need a safe opening we can help any time of day,
we also provide an Access control, CCTV

http://localcalgarylocksmith.com/
http://0544342878.com
http://mysaite.ru

שירותי ליווי
זונות ליווי
נערות ליווי

Oh look, Spam Attracts Spam. Time for a clean-up.