Nothing?

hhp

I pinged the ClearType team, some of them are on vacation this week.

Si

Does anyone else have a link to good documentation on CT hinting? I feel like it should be somewhere with the MS typography area. Would it be with the documentation for the VTT tool?

[Edit] Carl, In general the CT team has said that in most cases special CT hinting is not required, but ’light’ y direction hinting is appropriate, with some x direction hints to help in print and certain other scenarios.

There are some advanced techniques but these are really only appropriate in very specialized places (for example in a UI font), but in these cases they’ve often been able to give more specific advice and pointers to those that need it.

[edit] David, the CT team are discussing your question - expect a post here within the next day or two.

Cheers, Si

Hi David, I am not sure I fully understand your spec, but I think I get the general gist of it. It actually sounds like you are describing a spec to design for low resolution which is the case with ClearType, and so generally makes sense. Up until this point we have made no fonts targeted to work “only” with ClearType onscreen. The fonts we made were primarily made for that purpose, but also intended to work for high res print, so we did not take the approach of Quantizing everything. It seems like a good idea to do this, and may help the individual glyph(s) render better onscreen in a more uniform way, but it also may push the design in a direction of slight uniformity. As with any “spec” for designing a typeface, it’s a pointer in the right direction, but the real task to getting it right is in the proofing. And so like any other type design project, it’s not that different. The glyphs you mention as having to be designed to be different, seem more like general rules for any typeface design. In a spec for CT, I would be more inclined to give “rules” for the design of parts of glyphs, i.e. serifs, horizontal features, diagonals. Let’s take the CT font collection. One of the things we noticed as we proofed existing fonts in ClearType was that certain glyphs did not render well and produced more “jaggies” than we liked at the lower screen sizes. As you know CT works in the direction of the stripes, so in general for LCD screens, that would be the horizontal direction. For Western fonts at least this is fortunate, as this is where most of the main info is, stems, symmetry, spacing, all of the things we had problems with in bi level rendering. So with CT turned on most of these problems go away, and actually with your approach to Quantize, this may give great results straight away. However we are still using the old full pixel method in the y direction. So, in the design of glyphs like the lowercase “g” particularly the spectacle type of “g” the horizontal part is better designed as horizontal as possible, to reduce the effect of “jaggies”. Take a look at Perpertua on screen with CT, it works pretty well, but the “g” really does not render well, as it has a very vertical and lengthy part to the glyph. By making the design features as horizontal as possible, you can get great looking results, without making too many compromises, and it also helps the rasterizer naturally render the glyphs more cleanly. I think lightening the diagonals is a good idea, but not too much, and once again this can be best viewed when proofing. Same goes for the Bold weights. Actually as I mentioned to you before, it may be better to design the Bold font a little bolder then normal, as it now needs to stand out from the Roman a little more. In the bi level rendering, the regular font was usually 1 pixel while the bold was 2. This was way too much, and CT makes this situation much closer to print.

As far as hinting for CT, there really is no big mystery. Of course as Si mentioned there are some advanced techniques, but in general, all that is needed is a good solid set of ydirection hints, to control alignments, x-heights, cap heights, all the usual suspects, remember that the y-direction does not get the extra resolution, so actually it becomes more critical to get this right. I will have a chat with Simon and see if I can get something posted on the Web about this.

let me know if any of this helps

mike

It does thanks. I have some questions on what you said, but the biggest is about the Roman/Italic weights. If horizontal hints are abandoned, but vertical are not, then horizontal weights can only increase relative to verticals, they cannot decrease. Diagonal strokes, likewise, can only increase in weight if un-hinted. Since Italic increases in weight faster than the Roman, as the resolution goes down, then one must expect, and John Hudson indicated that it was the case in the CT fonts, that Italic styles needed to be lightened from their nominal weight for print. I should be obvious in either the print samples or the screen samples.

Also, I’m confused by the conflicting guide to hinting from You and Si...

> conflicting guide to hinting from You and Si

Please ignore me, Mike is the expert. I may well have mistyped when transcribing Mike, Tom and Beats advice to this forum.

Mike, if you spot where I’ve contradicted your advice let me know - fortunately unlike real life typophile lets me correct my mistakes.

I think David was referring to the y-direction hinting for print advice. Actually its mostly the other way around. For the purposes of this discussion we are talking about CT onscreen, but if you also care about print, then adding x-direction hints to main stems, will help maintain good output at higher resolutions such as printers. If you do not care about print output, or you do not care about black and white screen output, then you can mostly do away with x-hints. There are some cases where some might be needed, as you cannot always do x and y hints totally independant of each other, but for the most part I have found generally good looking results without x hints for CT. The y alignments, x-height, caps height, decender control, and accent control, as well as contolr of certain glyphs like lowercase “e” and anything with a crossbar, need careful attention. The goal in all of this is to cause as little distortion to the original outline as possible.

as far as italic weights go, it would seem to me that once again proofing some key characters in the regurlar v the italic, from the outset will give you the idea on weight. I will have to go read Johns theory on italics again, but either way its all pretty subtle, and making these decisions by eye are what type design is al about.

mike

Not directly concerning CT, but arising from some of Mike’s comments:
Doesn’t TT allow hints to depend on output PPEM? If so, shouldn’t it be
possible to avoid compromising screen display for print and vice versa?

hhp

True Type is pretty powerful and adding ppem specific hinting will increase code and time, but can be done. Other advanced methods of hinting for CT can also be done. I will try and cover some more of this in detail when I get around to posting more information on the MST website.
apologies for the typos in my last post...
mike

> will increase code and time

For diminishing returns - I understand.

One other tangential question: I remember when VTT was modified to be able to specify if a hint was for 1-bit OR grayscale rendering (the former being the old MS core font cornerstone). What I’ve since wondered (and at TypeCon’04 somebody from Ascender replied to me in the affirmative, but I’m still doubtful) is whether anybody actually ever made a font with rendering optimized for teen-PPEM grayscale (non-subpixel) rendering. Or did CT and/or too-much-effort/size kill that avenue.

hhp

with a little investigation you can find out if you are in CT.

Then with a function you could do something different such as lightening or thickening a stem in X. But you never actually know what your target device is so it’s a bit of a waste of times in many cases.

It can be done but it’s really a bit academic. I’ve done conditional CT hinting but its mainly CT Deltas (functions not true Deltas) and these were mainly to thicken up an UC stem that was a bit light compared to other stems.

>I think David was referring to the y-direction hinting for print advice.

Fixed, thanks Mike.

“Take a look at Perpertua on screen with CT, it works pretty well, but the “g” really does not render well, as it has a very vertical and lengthy part to the glyph.”

I’ve migrated to a bilaterally symmetrical lower bowl for screen fonts.

“The goal in all of this is to cause as little distortion to the original outline as possible.”

A noble goal. But as the resolution falls the goal should change to causing as little distortion to the best outline possible.

“If you do not care about print output, or you do not care about black and white screen output, then you can mostly do away with x-hints. “

The other “if” you should add, is, “if the composition system is exclusively going to sub-pixel position the origin and advance width of each letter according to the original outline, and only the original outline, then you must! mostly do away with x-hints, because, in the lower reaches of resolution. One cannot design/hint for separate distortion of figure and ground, can they?

The other if, is: if type were just x and y, this’d be short discussion. The only reason it continues, is because type has x, y, and a. and these angled strokes are both x and y. I of course, believe that no avenue to a fully crafted solution exists unless x and y and a are all under complete control of the designer, which is TT and any number of “natural”rasterizers.

But, be that as it may be, I think everyone agrees that at the very lowerst reaches of resolution aliased type works best yes? (7-10). Agreed? So, is CT going to have a base ppm, below which aliased letters & spacing are used, or in the lower reaches, what?

“Johns theory on italics again, but either way its all pretty subtle, and making these decisions by eye are what type design is all about.”

I am certain that making decisions by eye is appropriate in many many instances of type design. But, there are other instances of type design, where the term eye is not appropriate because the decision is bigger than any eye can take in.

“is whether anybody actually ever made a font with rendering optimized for teen-PPEM grayscale (non-subpixel) rendering. Or did CT and/or too-much-effort/size kill that avenue.”

Rip Van Papazian just woke up? Can you say that again?

> I think everyone agrees that at the very lowerst reaches
> of resolution aliased type works best yes? (7-10)

1) The lowest reaches are below that, and there a-a adds a critical dimension to legibility. Not that I enjoy reading that stuff. :-)
2) Show me any bitmap font in your range, and I will improve its readability with grayscaling.

> Rip Van Papazian just woke up? Can you say that again?

Are you thinking I’m asking for something that’s been
done a million times already? Then let me try again:

Is there a font that controls its (non-CT) grayscale rendering using hinting?
For example makes the top-right of the “n” actually look nice.

Is there a font that looks like this
http://www.themicrofoundry.com/other/Mana13&11.gif _
via hinting?

(BTW, that there is nothing exotic format-wise: it’s a
TT font, and it works the same in Windows and OSX.)

hhp

So:
How hard would it be to hint a “normal” print font to rasterize the “g” below?

hhp

in Windows you are normally best to turn off grey scale when the stems are one pixel. So you would not end up with that image.

Cleartype tweak example:

image on the left, left stem of ’K’ is light, image on the right a conditional change is made.

same size and glyphs in binary and greyscale same hints. Final font used ’gasp’ table so that this size would not be greyscaled since it had only one pixel stems. (20 ppem)

> you would not end up with that image.

Hmmm, let me try this again: I want to end up with that image. Currently I do it using partial “virtual pixels” in a pixelfont; but the resultant outlines can’t be used for print. What I’m wondering is why some TT hinting guru hasn’t -as far as I know- produced a “normal” outline font with grayscaling enabled at teen PPEM sizes, solid stems and bars, and hinting to makes the curves and diagonals looks decent. Is it because it’s too much work? And the stems don’t have to be 1 or 2 or 3 pixels - they just have to be solid (and monochromatic, please).

The “K” example is intresting though.

hhp

Actually, the stems (and bars) don’t absolutely have to be solid,
they just have to be controlled, not left to the luck-of-grid-draw.

hhp

you can get close but in the outline the curve points will create percentages of grey and not full black as you have done.

but in TT you can almost anything (except randomize). this isn’t correct = You could vectorize the outline by using the lowlevel TT instruction flipon/flipoff which runs a point to/from an on curve to an off curve, put them all on curve at some sizes then back to off curve then you could align points to a grid. but you can flipon/off is for something else. I’ll have to look up how I did manipulate the outline. But yes you can manipulate any outline to do almost anything at low sizes as long as the instructions are used.

I made an example of that turning a Uppercase N into a lowercase n, at small pointsizes at RIDT back in 97 I think.

this is a random lowercase ’g’ hinted in VTT that I could get near to what you have but would have to vectorize the outline to make those extreme black to white area that are only possible when you are on a pixel boundary.

Thanks for trying your expert hand a this. I hadn’t heard of “vectorize the outline” before. Is that different than delta-hinting? Because delta-hinting can make solid pixels at whim, no? If so, why not use that?

> I made an example of that turning a Uppercase N into a lowercase n

Yes, I remember that! Even more impressive to me
was your usage/supression of traps depending on size.

—

BTW, about italics again, here’s an old -cached- thread with interesting stuff:
http://72.14.203.104/search?q=cache:a4_AVy_YddIJ:www.typophile.com/forum...

Look towards the middle of that thread at the “h”s.
Honestly, which italic is better?

hhp

OK, the hijack is over. All hostages released unharmed.
All the RSB (Revolutionary Screenfont Brigade) asks is
that they alert their network media to the following:

http://typophile.com/node/18802

hhp

Sorry to be late to the party. David, my comment about CT italics on the ATypI list was not that ’that Italic styles needed to be lightened from their nominal weight for print’. On the contrary, what I noted was that although the diagonal stems gather more pixels the colour filtering makes them appear lighter than the vertical stems (although this is in part dependent on the tuning of the CT renderer). So in order to maintain a good contrast (notan for Hrant) in the italic, you do not want to make it too light. So my recommendation is to sort out the weight of the italic first with a few test glyphs, and then derive the appropriate weight for the roman relative to the italic.

Here is the exchange from the ATypI list. Your initial quetion in italics, and my response in bold. The link is still live.

We all know that to make a non-upright style to match an upright style, you make the non-upright style lighter to compensate for the angle, and you’re done for print. But we also know you cannot trust the weights to look right on the screen, because the upright gathers fewer pixels than the non-upright, the “color” of the non-upright out darks the upright, (until it’s time to print).

Some of this depends on how one tunes the CT renderer. What I notice, with the fairly light tuning I use, is that although the oblique stems gather the same number or more subpixels than the upright, the colour filtering is such that they appear lighter. The contrast of the pixels gathered in the upright stems tends to have a higher contrast than those in the oblique.

[Note that this screenshot is of Windows XP CT rendering in Word, so does not display subpixel positioning. The usual caveats apply about looking at ClearType in screenshots, especially on different monitor resolutions.]

David, of the MS CT fonts, Jelle’s Cambria is probably closest in approach to the kind of quantizing you describe.

> Jelle’s Cambria is probably closest in approach
> to the kind of quantizing you describe.

Is it telling/worrisome that Cambria also happens to be the ugliest one?
I mean in its outlines.

hhp

hrant, i thought you were a fan of ugly. >^P

Ah, touché.

hhp

“not that ‘that Italic styles needed to be lightened from their nominal weight for print”
oh.
“my solution to the issue was to make the roman a touch darker than I would have for a purely print type,”
Yo ko...
“” So my recommendation is to sort out the weight of the italic first with a few test glyphs, and then derive the appropriate weight for the roman relative to the italic.”

Not really on any design trajectory I’m familiar with, but I can do that.

So, really, even moderately optimized CT fonts should not be used for print.

> even moderately optimized CT fonts should not be used for print.

1) Is that your opinion of the Longhorn/Vista fonts?
2) There’s always superhinting... :-)

hhp

So, really, even moderately optimized CT fonts should not be used for print.

It depends what you like type on paper to look like. It depends on what kind of printing you are talking about. It depends on what kind of paper you are talking about. There is no more a general case for print type than there is for screen type. There are probably some screen and print conditions that are actually closer to each other, in terms of what is desirable in an optimised typeface design, than to other conditions in their respective media.

I should probably add that I like dark type, and think that a lot of common types used in print are too light and grey.

“It depends what you like type on paper to look like. It depends on what kind of printing you are talking about. It depends on what kind of paper you are talking about.”

It also, apparently, depends on who you talk to. ;)

“There are probably some screen and print conditions that are actually closer to each other”

Can you give an example?

“There’s always superhinting… :-)”

No, there isn’t superhinting, as you call it, is only useful in systems where the spacing is discrete.

> superhinting, as you call it, is only useful
> in systems where the spacing is discrete.

You mean integer (because 1/3 is still discrete).

I can understand that in terms of results-for-effort*, but not technically. What’s there to stop a hinter from tweaking the outlines, per PPEM**, with 3x x-axis resolution? And why would VTT have been given the ability to distinguish between 1-bit versus gs hints? For somebody who prefers Mana’s rendering quality to the CT stuff (for more than one reason) might it not be not only doable but worthwhile?

* Which is probably a big reason why no font -except maybe Palatino
Linotype, but I suspect to a very limited extent- has done that yet.

** BTW, I got “superhinting” from the big boys. The difference between regular hinting is the addressing of PPEM. I could use “delta-hinting”, but that’s too specific to the small movement of individual vertices.

—

So John, you’re saying that CT leans designs towards a darker weight; and causes italics to be the pivot point for weight determination? Interesting. Stuff’s coming out the woodwork - gotta love Typophile. I like darkish fonts too; but I much prefer it determined by humans, as opposed to being a side-effect* of a corporation’s need to keep “improving” (as much as I like CT).

* Unforseen, and/or maybe uncared for?

And David, you’re saying that CT optimization puts too much
strain (aesthetic?) on outlines. Interesting. I can use that.

hhp

“And David, you’re saying that CT optimization puts too much
strain (aesthetic?) on outlines. “

I did not say that. What I said was that dividing the optimization among hints, outline and rasterizer, (the way CT does), puts enough strain on the outlines to make them less better for print, which John and MS are obliged to deny.

OK. So what kind of division of optimization would be better?
Isn’t the solution to have superhinted-CT, so you can warp
print-optimal outlines to whatever you’d like onscreen?
I still don’t understand why you think that’s not doable.

hhp

Can you give an example?

No.

What I said was that dividing the optimization among hints, outline and rasterizer, (the way CT does), puts enough strain on the outlines to make them less better for print, which John and MS are obliged to deny.

I don’t think I’m obliged to deny that. But I think I can say that the statement is less accurate about ClearType than it was about b/w bitmap rendering, and it is less accurate about ClearType on my Dell computer than it is about ClearType on my Panasonic computer, and it is less accurate about the way I have my ClearType tuned than the way huge swathes of Windows users have their ClearType tuned.

I certainly don’t claim that ClearType has erased the distinction between screen and print, but together with advances in screen technology it has narrowed that distinction and, in the process, created an interesting design space. Constantia was a deliberate attempt to create a hybrid screen/print typeface within that design space. If I had optimised it for screen alone, it would be different. If I had optimised it for print alone, it would be different. But I was trying to optimise a dual-media typeface, making it as good for screen as possible without making it completely inappropriate for print, and as good for print as possible without making it useless for screen.

So John, you’re saying that CT leans designs towards a darker weight; and causes italics to be the pivot point for weight determination?

The observation about italics is simply my own conclusion, arrived at while designing Constantia. It is a methodology that I found helpful in managing the relative weights in the ClearType environment. I’m quite certain that there are other methodologies.

The observation that a slightly darker weight is desirable in ClearType has been expressed numerous times by people in the ART group at MS. The Berling Antiqua fonts that shipped with the MS Reader are slightly heavier than the common version. I’m not sure about the Frutiger.

> the statement is less accurate about ClearType
> than it was about b/w bitmap rendering

Really? I don’t see that, when you consider that the 1-bit stuff was superhinted, while the CT fonts are not (and David seems to think they can’t be). But let me ask David, since I myself am actually not seeing the problem (yet): is Georgia closer to your ideal than the CT fonts?

One place where I do agree though is the Bold: even though I’ve never managed to extract a confession that the Bolds were too bold in the old MS core fonts because of the screen, there have been slips that affirm it, plus it’s really obvious anyway.

> it is less accurate about ClearType on my Dell computer than
> it is about ClearType on my Panasonic computer, and it is less
> accurate about the way I have my ClearType tuned than the way
> huge swathes of Windows users have their ClearType tuned.

You’re talking about the screen. David is talking about print,
and no matter how the CT fonts look onscreen using a given
setup the outlines are the same.

> it has narrowed that distinction

1) Again, as above, I’m not seeing that.

2) In terms of WYSIWYG, I think that’s an illusion.
When resolutions are so different, it’s just not the same design.

> Constantia was a deliberate attempt to create a hybrid screen/print typeface

But therein lies the problem, no?
(BTW, as you know, I do like Constantia.)

> I’m quite certain that there are other methodologies.

But you like yours best, no?

> The Berling Antiqua fonts that shipped with the
> MS Reader are slightly heavier than the common version.

I didn’t know that.

BTW, I’ll always remember my abrupt shift in opinion when I first saw Berling used for the Reader: I started with a “pfft”, but then it hit me how suitable the vertical proportions and details of finish were (at least for a canned, as opposed to custom, font).

hhp

But therein lies the problem, no?

No, therein lies the design brief :)

Obviously, if you are not optimising for either screen or print, then you are compromising both. But if your goal is not to optimise for either, but to create as good a hybrid as the target rendering technology on the screen side will allow, then compromise is the design solution. Now I think David is quite right to question whether the target rendering technology of ClearType is really good enough, close enought to print, to establish a design space in which such hybrids are viable. That is the sort of question that should be asked, and in many respects the CT font collection represents the efforts of several different designers to respond to that question, since the general design brief was for types designed for CT rendering which would also look good in print, and the specific brief for Constantia was for a typeface that could be used in both eletronic and print media editions.

But you like your [methodology] best, no?

There were half a dozen different designers working on the CT fonts (not including the Japanese design, but including Matthew’s Latin, Greek and Cyrillic companion), and each took a different approach to the brief and worked out a different methodology. Far from saying that I like mine best, I think the range of possible approaches is far from exhausted, and I don’t think we’re in a position to claim that there is a right way to design for ClearType that everyone should follow. It is still very much a live design problem, which should be subject to more thought and, crucially, explored in more designs.

If I were starting Constantia now, with what I’ve learned and observed, I would certainly do some things differently. Most likely, my approach would combine aspects of the methodology I developed for weight with Jelle’s approach to spacing in Cambria, which I think worked out better for screen than Constantia’s.

Certainly, I’m a big believer in the centrality of compromise.
But your/David’s question concerning the viability of these CT hybrids stands.

> Jelle’s approach ... worked out better

Could you elaborate?

hhp

I’d need to spend some time actually analysing Jelle’s spacing: at the moment I’m just responding to the overall results. In general terms, the spacing of Cambria is slightly looser than Constantia, but I’m not sure how much this accounts for.

Also, I go back and forth on this: sometimes I prefer the way Constantia reads onscreen, sometimes I prefer the way Cambria reads. This goes back to what I wrote above: it is too soon to be talking about correct methodologies or definitive design recommendations for this technology. We’re going to need to live with ClearType, hopefully with generally higher resolution screens, and with these typefaces for a while before we’ll have a good idea of what works best. I use the CT fonts in as many places as I can on my system, but when Vista ships and more people start using them, I think we’ll get some good feedback.

I like the fact that Constantia looks black like type should, and not the aenemic grey of most onscreen type, but the slightly looser spacing of Cambria is very pleasing.

The Cambria example also seems to have — or at least it feels it has — more interlinear space. When I look at the two paragraphs, the one set in Constantia feels like it was set solid, or was vertically “squooshed”.

In addition to being lighter than Constantia, one other thing making Cambria more pleasing to read might be its narrower proportions. I feel that the wider proportions of Constantia make it less faster to read too.

That sample uses subpixel positioning. If that’s not available until Vista, could you please show what Windows XP would, since that’s what people will be seeing for at least another year? But a more important adjustment I’d ask for is to make the apparent sizes closer. I can see that you’ve equated the x-heights, but Constantia has fully two pixels more height there*, plus it’s darker**, so it becomes harder to compare the two. The third thing I’d recommend changing is the leading: Constantia has less apparent leading than Cambria (which makes it look [even] darker). If you could put up a revised image that would be nice.

* Proof that there’s certainly more to apparent size than the x-height.

** Which is why it needs to be tighter, clearly.

As it stands, on my screen (pretty lo-ppi) Cambria looks better; and this makes me wonder if there isn’t something to David’s complaint after all: as I’ve said before (sorry, Jelle) Cambria is also the one I find uglier. But I’d rather wait for a revised image to be sure.

BTW, another question: At what PPEM does Constantia
acquire two full pixels of stem width? And Cambria?

hhp

Something else:
I noticed that double-el combinations in Cambria exhibit the same color pattern for each el. This is not the case for all doubles (like “ee”), although the double-el arguably has the greatest need to look consistent, seeing as how it’s just a pair of adjacent sticks. For me this a big plus, with the double-el in Constantia shows one of the three main things wrong with ClearType (that a character’s rendering varies depending on where it falls on the subpixels). What I’m wondering is, is this something Jelle did on purpose, or is it a happy coincidence? If the former, is this something he did for this PPEM only, or did he use [super]hinting to make the width of the “el” snap to the subgrid for each PPEM?

Also:
Why do you think Cambria is exhibiting less color fringeing than Constantia?
Is it simply a matter of luck what PPEMs each “likes” in that way?

hhp

Oh John, you and spacing, your bete noire. Please comment on the latest spanner I have to throw into the works: Cnet’s shootout of the two available 30-inch high res consumer LCD monitors reveals that Dell’s has antialiasing built into its hardware. What are the implications of this for ClearType and other rasterisers? Will hardware antialiasing become prevalent? How will it conflict with software antialiasing?

And how necessary is hinting today if Apple’s Quartz presently discards all TT and PS hints and users appear to be delighted?

Would someone - John is probably the only person with both the energy and the expertise to do so - please post some illustrations revealing the effective differences between ClearType, CT2, Cooltype, and Quartz rendering, along with some discussion points? Obviously this should include comparative representations of CT fonts, ’ordinary’ TT, and ’ordinary’ T1. A daunting task but it would be very illuminating.

What will be far more difficult is to test and illustrate how well Dell’s hardware antialiasing is working, since that would require some sort of standardised photographic setup I imagine. Who else is doing hardware antialiasing or has plans to do so? Are there any publications that refer to it? David I realise this isn’t entirely on-topic, but it’s not altogether off either, and I was so surprised to learn of hardware aa that I thought I had to mention it.

On this blog

http://www.digg.com/hardware/30-inch_Apple_Cinema_Display_vs._Dell_Ultra...

there are some interesting comments on the Cnet review, some casting doubt as to whether hardware AA is really occurring. Could the reviewer really have made such an error? There is also an interesting comment by someone who claims that Quartz-rendered text is easier to read than CT.

Hardware anti-aliasing works based on bitmaps, right?
So it’s necessarily hopelessly inferior to anti-aliasing from vectors.

The thing is, AFAIK such display systems work by taking a
double-resolution image and anti-aliasing it down to their
native resolution* (because it’s cheaper than having that
great a resolution) and this might throw off CT’s colors.
But: you could always write a special driver; and you
should be able to turn off the hardware AA.

* Not much to test, really.

BTW, anybody remember those hi-res b&w monitors (Viking, I believe) from the 80s? Not a new idea.

> how necessary is hinting today if Apple’s Quartz ...

Small stat for you: Mac market penetration: ~5%.

> users appear to be delighted?

Apple users get delighted at anything with an Apple logo on it.
Except maybe if it blows their eardrums out.

—

The global comparison you want would be revealing, but there is
the issue of gamma difference between platforms, and you would in
fact be hard-pressed to find anybody to do it for you. Why don’t
you do it? And be sure to include the rendering that outperforms
them all onscreen: handmade gs.

BTW, some combinations of such comparisons have been done,
including on Typophile. My own conclusions have been that:
1) For Roman, the quality order is: handmade, CT, Quartz, CoolType.
2) For Italic: handmade and CT are tied overall, then the rest again.

But what would blow them all away is superhinted CT.
Or handmade subpixel, which however requires color addressing.

> someone who claims that Quartz-rendered text is easier to read

Let me take a wild guess: he also happens to be the
proud owner of both the iPod and the Mini iPod,
and an Apple-branded hoodie?

hhp

The comparison above was thrown together very quickly in my CT test tool (yes, using subpixel positioning), with both fonts at a nominal 9pt. I didn’t play with the various tuning and API option settings in the tool, and Constantia actually looks heavier in that example than it does using my normal tuning.

Here is a comparison in WordPad on Windows XP SP2, i.e. without subpixel positioning, using my preferred tuning. Both fonts are nominal 9pt again, but this time on explicit 11pt leading.

_

Miguel, I generally find condensed typefaces considerably slower to read than nicely round ones: too many upright stems in close proximity and not enough well defined horizontals. Constantia aims for something close to traditional book face proportions with longer extenders and rounder proportions.

In raw legibility testing (accurately identifying individual glyphs flashed on screen), the alphabet characters in Constantia scored higher than Cambria. Unfortunately, the results for non-alphabetic characters were skewed by the fact that Constantia has default oldstyle numerals and currency symbols and Cambria has default lining forms. It’s remarkable how few people can tell the difference between an oldstyle zero and a lowercase o when they see it at 8-t on a 120dpi screen for 34 milliseconds :)

John, thanks for the new graphic.
The apparent sizes are still not matched, but OK.

In this sample Constantia has an acceptably dark color to me,
not overly dark like the previous sample. Interestingly though
Cambria doesn’t look any lighter.

Do you guys think subpixel positioning is helping? I’m assuming subpixel positioning is making overall spacing look better... but I can’t actually see it. Linebreaks probably become more predicatable too. But one bad thing subpixel positioning is definitely doing is making the rendering of a character vary. So is this a good trade-off?

> I generally find condensed typefaces considerably
> slower to read than nicely round ones

At the same point size, sure: they’re bigger. But equalize
the apparent sizes, then things become decidedly different.
(I’m talking about normal text sizes here.)

> Constantia aims for something close to traditional book face proportions

Which also means it should be used at a larger point size than
something like Cambria - and it’s cool to have such distinctions.

The thing is, if you compare two fonts that have the same set-width but different x-heights, the small x-height one only seems wider, while in fact all it’s doing is looking smaller (hence less readable, at least onscreen). The Latin x-height isn’t so over-populated with stems that I think they need to be short to make things readable.

> raw legibility testing

Cool - when did this come out?

> tell the difference between an oldstyle zero and a lowercase o when ...

Shoulda used hybrids.

hhp

Hrant, by equalise ’apparent size’ do yoy mean equalise the x-height? I guess so, because at these kind of ppem sizes, the vertical grid is too crude to allow any other kind of optical equalisation.

In order to equalise the x-height at this resolution, I have to increase both fonts to nominal 10pt, shown here on 12.5pt leading:

Cool - when did this come out?

Quite recently.

Shoulda used hybrids.

Each Constantia font contains six different numeral styles, not including superior/inferior and fraction numerator/denominator, including tabular and proportional lining numerals, so it wasn’t as if comparable numerals were not available for testing.

In typefaces with only one numeral style, e.g. Arabic Typesetting and Nyala, I do use hybrid numerals:

But note that in the legibility study, 11% of participants managed to confused the lining zeros in Cambria and Times New Roman with lowercase o!

[Thanks for the new graphic John (previous page). It looks much better.]

John, thanks again - but I think we’re confusing each other. :-)

Apparent size means just that: you look at them and you tweak the point sizes until they look the same size. At the same point size Cambria seems to be using less of the Em space. Which is strange. Maybe it’s to offset the fact that its x-height is proportionately bigger? Did the set of CT fonts have a uniform apparent size design requirement? Because if so, I don’t think it’s working; probably because x-height isn’t the only determinant of apparent size; there’s also extenders, width, color, even internal proportions (like an “e” with a big eye visibly increases a font’s apparent size). For example, Patria and Times* have pretty close vertical proportions (which was a coincidence, I swear) but the former looks bigger on the body.

* And Georgia, interestingly.

So in every sample you’ve made Constantia looks bigger (because you’ve used the same point size for both) and it’s not hard to see why: even though the x-heights are the same, its extenders are longer, it’s wider, and it’s darker! On the other hand, you’ve made me realize that -at least onscreen- what I want might not be possible: since the x-heights have to be integers (unless you want gobs of blur) just making Constantia’s x-height one pixel smaller might make it look too small instead. Wait... I just did a comparison between the Constantia in your second image and the Cambria in this third one, and yes, the former at 7 pixels of x-height looks way smaller than the latter at 8 pixels of x-height (more off than what you’ve shown). So forget about matching the apparent sizes - sorry.

But this latest image wasn’t a waste of effort, since it’s made me realize that the larger the point size: the closer the two come in color; the less the color fringeing; and the more I prefer Constantia.

Hybrid nums: very glad to see you’re a fan!
BTW, the “4” in Nyala is very nice.

hhp

Calibri, Cambria, Candara and Corbel have a uniform x-height (950/2048 units). Constantia has a slightly shorter x-height (924/2048 units). Consolas has a larger x-height (1004/2048 units).

Calibri, Candara, Corbel and Constantia have the same OS/2 vertical metrics sum (i.e. harmonised default linespacing). Cambria, I’ve just noticed, has slightly smaller OS/2 metrics; not sure why. Consolas has smaller OS/2 metrics.

Calibri, Cambria, Candara and Corbel...

Are’nt those the proposed province names of the Republic of Cascadia?

With regard to the question, are hints necessary at all today, it is not just Apple that has discarded hints in font renderers. From Mitsubishi’s website,

“Technical Discussion: Saffron provides an alternative font rasterizer that can be integrated in the OS, at the application level, or in embedded systems. It takes font outline descriptions as input, converts them to an internal ADF representation and renders them in real time. Because Saffron rendering is computationally simple and does not use TrueType or Type 1 hinting required by competing technologies, fonts do not need to be special cased; Saffron can be implemented in both custom hardware or accelerated using standard graphics processing units (GPUs).”

So far I know, Saffron is being used in Flash currently, so there are two platforms where advanced font rendering takes place without reference to any hinting, and it does seem like the wave of the future if it is technically valid. I have no idea at this point.

Regarding the samples of Constantia and Cambria, John’s type and Jelle’s type (doesn’t matter what you call ’em, it’s all confusing), here are my 2 cents, based on a quick look on 1900x1200 screen.

Const looks it was spaced for 12 point, Camb for 8 point, relatively speaking, and relatively speaking, at these display sizes, Camb looks better. That’s just a simple argument for the necessity of optical scaling in screen type which should be obvious. Printed (or shall we say ’screened’) larger, Const would look better, Camb too loose. That’s one of the important mechanisms going on here.

Folks, you can do all the bloody legibility research you want, but you will never get away from the fact that type needs to be designed differently for different sizes. Until you have a mechanism in place to change the type design shapes as they scale up and down in size, you cannot provide anything near an optimal reading experience.

Apart from that, at these sizes, Const looks too square, too angular, too tightly spaced. Cambria is better optimised at this size, largely, but it has problems too: the g and f don’t scan well; the f in particular seems to glop up. I have difficulty considering these types to be screen optimised as they are represented here, although I am sure that it would be easy for John to make comparisons that would show that what we are seeing really is a technical triumph. I have no doubt that it is. What I am saying is, judged just on their own, without comparison to anything else, and judged from an entirely subjective point of view of what constitutes legibility for me, I see considerable room for improvement.

That said, many improvements that could be made would apply only to particular sizes. But that is true of all type in all display systems. Once you are looking at it this closely, optical optimisation becomes the key issue. And Microsoft isn’t addressing that, and has indeed gone a very far way to distance itself from that discussion. This represents one of the primary conceptual failures of CT2 I suspect.

> are hints necessary at all today

“Today”? What happened between yesterday and today (I mean besides
Management needing to find a Next Big Thing) that has changed what
onscreen text NEEDS to be?

> converts them to an internal ADF representation

EULA-violation-fest, anyone?

> advanced font rendering takes place

Define “advanced”...

> Printed (or shall we say ‘screened’) larger,
> Const would look better, Camb too loose.

With their vertical proportions actually matching that well.

Optical scaling: I’m as big a fan as anybody; but even without it there’s room
for better and worse type; and the CT fonts are much better than average.

That said, guess what would be the most elegant way to implement
optical scaling (well, 90%, if not fully) onscreen: superhinting! :-)

> I see considerable room for improvement.

So do I.

hhp

“That said, guess what would be the most elegant way to implement
optical scaling (well, 90%, if not fully) onscreen: superhinting! :-)”

OK, I can see where that might be possible, but I would guess it would get you to more like 20% than 90%. But suppose you have a type which changes shape as it moves up and down the optical scale — part of a nice system which talks to the screen and knows how it’s being displayed — which is the only thing that makes sense. If you had that, wouldn’t your hinting requirements be vastly simplified?

After all, the problem of hinting a font for a single master that must be displayed at various different sizes is quite related to the problems of designing the outlines for a font that must be displayed at various sizes, and they are ultimately insoluble because all font designs are (almost invariably) only maximally legible at a certain size. There is only one way to solve the problem in either case, and that is to move away from static glyph shapes, which are so ... 70s.

I have an idea which I would like to test if John can help me. My idea is that for a given display size, non-static design may be more important than superhuman hinting of static glyphs in achieving the most legible result. I have been viewing the samples John posted with Firefox on a Dell 15-inch 1920x1200 screen. I think the problem with both fonts is that they are not well-optimised for this quite small space. Might something like Sumner Stone’s new 5 point cut of Cycles, of which I happen to have two versions, look better, even without special hinting or anti-aliasing? If John could tell us exactly how to prepare such an image (preferably for both Windows and Mac), I would be glad to try and post something to see if the theory held in this particular case. It wouldn’t be a very good test in that 5 point Cycles is designed strictly for print, but it would be interesting to see if we could learn something, in a strictly limited way, from the comparison. I will see if I can get permission to use the types tomorrow, but my primary obstacle is not knowing how to create and post the images so that they are comparable as possible.

“15-inch 1920x1200 screen”
:-)

Bill, 90% is admittedly too optimistic IF you assume that a screen glyph’s width has to be a rounding* of its outline glyph; within this constraint, it does indeed seem impossible to get adequate optical scaling, because all you could comfortably do is darken the color; increasing letterspacing would entail making the black bodies narrower, the opposite of what you’d like - especially when you couple that to the desirable larger x-height since that would make the forms unusually rectangular. BUT, if you hint the widths wider, you can get anything you want; the problem of course is you totally lose the line measure correspondence with the outline font, and it probably stops making sense to even make a font that has print outlines adapted to the screen... But if you simply want screen display, and you want to have the elegance of a fool-proof, optically-scaling one-font solution, I don’t see a reason this can’t work. On the other hand, it does seem to depend on the app: note how for example WordPad uses the bitmap widths to string lines while Word uses the cumulative outline widths to place glyphs; the good news is that browsers I think use the bitmap widths.

* Or at most a less-than-one-pixel nudging.

> all font designs are (almost invariably) only maximally legible at a certain size.

Maximally, sure. But: it’s not like you can ever ensure maximal readability anyway, since it’s so contextual, and dynamic; and any improvement is still just that - there’s no reason to stop trying just because we can’t make it Perfect (as if that’s even possible).

Dynamic fonts: all fine and dandy, and it’s great to wonder
about the possibilities, but there’s also the minor issue of
trying to make current real-life users happy...

> 15-inch 1920x1200 screen

At a distance of 20 feet, I presume... :-/
Bill, don’t you realize how off that is?

> not knowing how to create and post the images

Create: Do a screen grab from your OS of choice, then save it as a GIF.

Post: Install Flash in your browser, or provide an external link.

—

BTW, one thing that somebody (like me) should really have
pointed out by now is the gamma issue: any sample of a CT
or Quartz render anybody puts up* will look pretty different
on Windows and Mac; of note here is that the more blurry a
sample is (the more it relies on grays) the more it will be
affected; going from Windows to Mac for example will cause
thinner features to become washed out; this btw is one good
reason to use handmade gs fonts, since they rely much more
on solid black, and don’t use light grays for too much form.
A further complication in the case of CT is that brightness
will affect the balance of the colors as well, so viewing John’s
Windows samples on the Mac will probably increase the
color fringeing.

* Unless it’s a PNG with gamma-correction values in there;
but is that even supported by any app, in particular FireFox?

hhp

Near as I can come with Cycles 5 point—and please consider that this font is intended for printing at five points, not for screen display at whatever. This is from a Mac, TextEdit, anti-aliasing set to ’light’. I guess the 7 point would look better—the x-height seems too large here and maybe the spacing is just a trifle too loose for this screen representation. But considering there is no hinting at all, it seems remarkably legible ... would we learn anything by seeing some versions prepared in Windows? What, if anything, does CT XP do to PostScript fonts? Would it look different with Cooltype?

Bill, thanks for putting up that sample. It looks like a charming print font*, but here it looks decidedly less crisp than John’s samples**. Also, although I don’t think it’s too loose***, I do agree that the x-height is a bit too large, and it also seems a bit too wide. Furthermore, it’s too dark, even when I compensate for the cross-platform gamma difference (which your PNG facilitates though an embedded profile, although [probably] only Photoshop can handle this).

* Except for one quite strange decision: why are the descenders longer than the ascenders?!

** Although this could hypothetically be due to Quartz versus CT (since I for one think the latter’s algorithm is a bit superior). It would be nice to see this setting done on Windows as well; let me know if I can help there.

*** Although the wordspace is slightly too narrow.

> not for screen display at whatever.

But this is moot anyway*, because the only way it could be
for the screen is if it were hinted for the screen, but of
course OSX would dump those hints anyway.

* Except hypothetically for a single PPEM, which apparently nobody does though.

One place hinting would clearly help is in the vertical direction,
to firm up the crossbars of the “t”/”f”, the serifs of the “w”, etc.

hhp

Hrant, one thing I find is that all the fonts look crisper on XP, but then my dpi count is higher on XP than Mac. What I don’t find is any marked difference in legibility, which is the major surprise for me. I would have expected the unhinted font to fall apart without special hinting. Why are the descenders longer than the ascenders? I would guess, to obtain minimal distortion of the underlying forms for maximal legibility at the target size if 4-6 points. But the underlying design isn’t shown here - there are some good samples at www.stonetypefoundry.com. Darkness relates to one of the great subjective unknowns of optical scaling: to what extent do you vary stem width as you go up and down the optical scale? And what is your purpose in doing so if it is not to gain evenness of color with other sizes that are being printed on the same page? And if it is, how do you rationally judge what constitutes even color when different sizes of an optically scaled design are being presented on the same page? These are questions which must be answered, areas in which you have to be at least be able to think, if you are trying to design a system for optimal screen or paper printing of type.

There is a notorious method for quick and dirty optical optimisation of type: you simply scale horizontally and track positively as you go down the scale in size. This achieves remarkably fine results given the minimal expenditure of effort, and was customisably built into PageMaker, which I have just given probably its last award in some magazine, along with all the modern equivalents. Something like this could feasibly have been built into ClearType, but only if the OS knows what its display system is at any given moment, and this seems to be something that Vista can’t do, if I recall an earlier discussion? Can’t do? Or won’t do?

There is also a nice compromise: if you have a weight axis, or a discrete system of weights from light to bold with small increments between them, you can combine that with scaling and tracking to get a nice, primitive optical scaling system going that is easier to design than doing it right in the first place.

But why not do it right in the first place?

Finally, I am beginning to wonder if hinting is really valuable at 1920x1200 resolution, versus brute force anti-aliasing. Once you have that resolution, it seems to me that the cost benefits of hinting are difficult to justify. Everyone is laughing at me for pretending that 1920x1200 is any kind of a standard, but my view is, if someone as chronically impecunious as me can have one, then anyone can. I think you can get a 17-inch laptop from Dell with this screen for about $1100, which is not very much money for an entire desktop replacement computer system.

I think we really are moving to a higher dpi count. But the transition can’t be gracefully made for users if the OS doesn’t know what it is displaying. If the OS has icons and text that by default look good at 1024x768, users will want to switch their high res LCDs down to 1024x768, with fatal results for legibility, because that’s the only thing they know how to do. Whereas if the OS knows what it’s displaying, it can make the appropriate scaling adjustments. Right?

> my dpi count is higher on XP than Mac

You could vary your viewing distance in proportion to the relative ppi.
(This time I’m not teasing. :-)

> What I don’t find is any marked difference in legibility

I’ll take you to mean readability, and offer the
axiom that measuring it cannot be a DIY affair.

> to obtain minimal distortion of the underlying forms for maximal legibility

But:
1) Legibility comes more from size than “minimal distortion”; readabilily comes as much from extenders as from “minimal distortion”.
2) In terms of actual frequency in real text, ascenders far outweight descenders.
3) The ascenders have less presence/character than the descenders, so they need more help.

Those three things combined seem to make the standard scheme of giving the ascenders more room than the descenders (even at the cost of making the “g” -the only glyph actually affected- look a bit cramped) far preferable to Stone’s scheme here. If the font isn’t released yet (or maybe even if it is) I hope he fixes that.

> what is your purpose in doing so if it is not to gain evenness of color with other sizes

There could be other reasons besides that. For example, our reading firmware might work better with darker (or actually lighter) relative color. Making everything have even color seems like a superficial goal. In fact I’ve come to believe that Even Color itself a sort of hobgoblin. Clearly there’s such a thing as too much of it, and that should alert us to a complexity.

> Something like this could feasibly have been built into ClearType

Could it? What about the issue of needing to match the line-measure with print. Consider that the scale (and probably the flavor) of optical compensation is different in print versus onscreen.

> I am beginning to wonder if hinting is really valuable at 1920x1200 resolution

Certainly, the higher the res, the less relevant hinting becomes. But it’s important to realize that raw resolution isn’t what counts here; ppi (resolution divided by screen size) is what you should consider; and very hi-res screens also tend to be larger - so hinting still helps. Equally important I think is to address the needs of the present, as opposed to [only] designing for some anticipated broad-based improvement.

—

BTW, one way to see how Quartz relies on subpixels less than CT is to convert the image to grayscale and observe the drop in crispness; in the case of Quartz the drop is negligible, which makes me think its use of subpixels is almost pointless. In the case of CT though the drop is pronounced.

Another interesting way to see the difference is to check a color historgram.

hhp

I am beginning to wonder if hinting is really valuable at 1920x1200 resolution, versus brute force anti-aliasing.

y-direction hinting is definitely valuable up to and, indeed, above such resolutions. The highest resolution screen display I’ve looked at was 200ppi, and even there you need to be able to manage alignment zones and consistency of horizontal stems.

Is x-direction hinting valuable in such displays, when sub-pixel rendering is active? The initial tests we did on the CT fonts, indicated that we could get away with no x-direction stem hints at all for screen: where we needed them was for 300-600 dpi printer support.

Bill, can you prepare a screenshot comparison of CT and Quartz rendering using a common TTF on both systems, e.g. Georgia? It should be a serif face, since my analysis of the Quartz rendering of Cycles 5 indicates some greying out in the serifs. If you provide such a comparison, I’ll do some subpixel enlargements so we can see what is going on.

ClearType doesn’t do anything with PS fonts. PS fonts are rendered by Windows using the Adobe-provided Type 1 or CFF rasterisers.

PS. I’m preparing a response to the discussion about spacing for screen.

John, I will try to get what you want, but it may have to wait a day or so. It’s interesting that you could dispense with x-dir hints for screen but not for 300-600 dpi print. Adobe people have stated in the past that hinting of PS is desirable even at 2400 dpi resolution. Is that partly because of the 1000 unit limit of traditional PS?

BTW, has OSX text rendering improved since
the Panther version of the OS? If not then this
http://typographi.com/000739.php _
might be potentially interesting, especially this comparison:
http://www.themicrofoundry.com/other/aa-compare2.gif _
The top is Times on OSX-Panther, the bottom on WinXP.
(Note: trying to equalize the gammas -in a somewhat brutish way, by
changing the brightness of each sample by 6%- has caused the color
fringeing to get exagerated, especially in the Windows sample.)

hhp

Adobe people have stated in the past that hinting of PS is desirable even at 2400 dpi resolution.

Did they say it was desirable, or did they just say that it was noticeable. I only heard the latter, from David Lemon and Fred Brady. Obviously this depended on the type size, but the effect of hinting would be detectable even at such high resolutions, i.e. a hinted glyph would render slightly differently from an unhinted glyph. Whether the effect was significant enough to be desirable is a different question. I can imagine situations in which it would actually be undesirable.

Remember also that we’re talking here about PS font, PS hints and PS rips, and what PS rips do with hints is a black art.

As Bill noted a couple of days ago, spacing is properly size-specific. Constantia is spaced for true 11-12pt, since these are the sizes at which it seemed to me there was most likely to be crossover use between screen and print. [I say ’true’ because nominal type sizes on screen vary so much.] But it seems to me now that a lot of onscreen text I see is actually smaller than 11pt, although this depends very much on how, for instance, individual web pages define text size and how my browser handles them and which of my two screens I am looking at. It is because of this, that I now think I would make the default spacing for a screen font slightly looser than I did for Constantia.

Thinking about this some more, over the past few days, it struck me that ppem-specific subpixel tracking would resolve this in a tidy way, and allow for automated size-specific spacing on screen. The vertical grid resolution is practically too small for many of the refinements of size-specific type that we value in press typography (e.g. gradual weight and x-height increase), but horizontal spacing adjustment is well within the bounds of improvement made possible by ClearType. I can imagine this being controlled at the individual font level by a new ’trak’ table, that would indicate at what ppem sizes what amount of positive or negative tracking should be applied. Fonts without the new table could still benefit from algorithmic tracking at the smaller sizes.

In the examples below, I have gradually increased tracking as size decreases, using units of 64ths of a pixel. The 9pt specimen is tracked +10/64. The 8pt specimen is tracked +16/64. The 7pt specimen is tracked +24/64. These values are not necessarily optimal, but they give you an idea of the general improvement in looser spacing as the type gets smaller.

When I find some time later today or tomorrow, I’ll prepare another comparison, showing tracked and untracked spacing side-by-side.

> ppem-specific subpixel tracking

But wouldn’t that throw off line measure matching with print?
Unless it was a deliberate and disableable feature within the
typesetting app (as opposed to a behind-the-scene OS thing).

In any case, those samples are certainly convincing.

> The vertical grid resolution is practically too small

For sizes that are close, yes. But it would be possible
and good to have let’s a say a difference of 1 pixel in the
x-height between the high teen PPEMs and the low teens.

hhp

But wouldn’t that throw off line measure matching with print?

Yes, but applications attempting WYSIWYG in terms of screen preview and print already work with compatible widths. I’m thinking in terms of applications like web browsers, email clients, e-book readers, etc. in which text is primarily read onscreen and for which users do not expect linebreaks to match when printed. If someone is looking at text onscreen as a preview for print, then obviously the print condition of the text is more important than the screen condition. But if someone is reading text onscreen then I’m sure you’ll agree that optimising that experience is most important.

But it would be possible and good to have let’s a say a difference of 1 pixel in the x-height between the high teen PPEMs and the low teens.

The problem isn’t about a change in relative x-height per se, but the distortion of the letters at very small sizes if you pop up the x-height. Consider that nominal 6pt text in my example above, which is a 10ppem bitmap on my Dell screen. The x-height is 5 pixels. The cap height and ascender height are both 7 pixels. My point about the crudeness of the pixel grid at small sizes not permitting optical refinements of the kind we make for print is this: increasing the x-height by one pixel at this size is a 20% increase in the vertical to horizontal proportion of the x-height letters. At that point, are you making an optically enlarged x-height or creating a new, condensed design?

[On the left is nominal 6pt Constantia, and on the right is a manually created version with a taller x-height. I’ve deliberately avoided any letters with diagonal strokes as being too hard to fake in this way.]

An optical master for small sizes onscreen should involve horizontal as well as vertical increase in the x-height, not necessarily proportionally, but enough to preserve the character of the typeface. One way to do this, obviously, is to create a separate design for small sizes. Another way would be to employ something like the glyph width adjustment algorithm used in Hz, which increases the width of letters without increasing stem weights. The latter seems to me to have a lot of potential for small text onscreen.

Previously forgotten:
> subpixel tracking

Now this seems like an actually useful application
of subpixel positioning; for this it might actually be
worthwhile sacrificing glyph rendering consistency.

—

> I’m sure you’ll agree that optimising that experience is most important.

Totally.
(With a lesson learned here being the fallacy of WYSIWYG.)

> the distortion of the letters at very small sizes if you pop up the x-height.

Unless you go for what I described earlier in this thread*:
increase the width of the letters (I mean their black bodies,
not just their set widths) along with the x-height. If you’re
giving up the line measure correspondence with print, why
not go all the way and make things even more readable?

* Which you also mention just now.

> One way to do this ...
> Another way ...

And a third way, which avoids the inelegance of the first way and the... non-existence of the second :-) would be to simply use [super]hinting!

hhp

would be to simply use [super]hinting!

Since this is the CT Design Guide thread, I’m limiting options to those that will work with CT. The limits on x-direction instructions applied by the CT rendered discount the kind of superhinting you suggest. Ironically, these limits are there because of the existence of superhinted fonts for b/w rendering than the effect those instructions have in a CT environment. This is the problem with superhinting: it is output specific, and if you change the output device you can easily end up with something that looks really bad.

It seems to me, though, that this simply means that many elements of the existing x-direction instruction set cannot be supported in ClearType, but it should be possible to develop a ClearType-specific set of x-direction instructions, which would allow more control of x-direction rendering in future versions of ClearType. I don’t know if the MS ART folk have considered this.

> The limits on x-direction instructions

Finally, somebody spills the beans. Thank you.
What exactly are these limits? And specifically
here, do they in fact preclude simply making a
glyph at a certain PPEM wider? I mean wider than
the upper rounding of the outline at that size.
If this is possible in CT, then you can vary not
just the x-height, but the width to accomodate a
greater x-height.

> these limits are there because of the existence of superhinted fonts for b/w

I’m not sure I understand this. Are you saying that CT limits
superhinting simply to be different than what was there before?

> This is the problem with superhinting

Funny how it was Perfect the last time around...
Anyway. Are these “backfires” limited to CT, or
are there robustness problems with the old 1-bit
fonts that I’m not aware of?

> it should be possible to ...

Just like how y-direction AA was disabled at first
but will be enabled in Vista... Leaving room to grow?
Or maybe just changing one’s minds.

hhp

Finally, somebody spills the beans.

Hardly, this has been discussed numerous times in various places ever since ClearType first shipped.

specifically here, do they in fact preclude simply making a glyph at a certain PPEM wider

How are you using the word ’simply’ in this context? There are multiple strategies for making a glyph wider, but one of the easiest and most common is a mid-delta affecting the position of a stem. That won’t work in ClearType. Another approach is to hint counters and other white space areas as stems and apply distance controls. This might work. I’ll experiment. Serious hinting experts like Vincent Connare or David Berlow might be able to suggest additional strategies.

Are you saying that CT limits superhinting simply to be different than what was there before?

No. Superhinting is output-specific, so if a font has been superhinted to make highly readanle b/w bitmaps, the techniques used to do that will likely involve considerable distortion to the outline at specific ppem size. That is what ’superhinting’ is: outline distortion aimed at achieving a specific result in a specific rendering technology. So if you put those fonts in a different rendering environment, say one in which the outline is supersampled to a 16 unit grid as in the first stage of ClearType rendering, you have the question of how to interpret instructions that distort the outline for a much cruder rendering environment. In ClearType supersampling the last thing you want to deal with is an outline distorted in the x-direction for b/w rendering: you want a undistorted outline in order to obtain letterform fidelity in the supersampling, not weird bumps and tucks from b/w delta hinting.

This problem is exacerbated by the fact that different hinters use different strategies, so you can’t anticipate what instructions have been used to achieve particular b/w bitmap results. Which means you cannot algorithmically correct for them. So the only safe way to render older fonts within ClearType is to ignore the subset of x-direction instructions that would cause problems.

Just like how y-direction AA was disabled at first but will be enabled in Vista

It wasn’t disabled. Y-direction AA for ClearType wasn’t implemented, I believe, until sometime in 2003 (by Beat Stamm). The transition from greyscale to colour antialiasing along a curve, from a horizontal section to a vertical section, as in the illustration below, is not a trivial thing. Also, y-direction AA needs to be size specific: you don’t want it at text sizes because it reduces the contrast, especially on thin strokes. So implementation also required definition of a new gasp table version (which unfortunately has not be published yet, because of the freeze on OT spec changes while the MPEG standard process was being completed).

> this has been discussed numerous times

Not anywhere I’ve been (and I’m not exactly a recluse).
In fact in this thread I asked at least three times before
getting the “right” answer.

> This might work. I’ll experiment.

Great, thanks. Fingers crossed.
And David, Vincent: any other ideas?

> if you put those fonts in a different rendering environment ...
> you have the question of how to interpret instructions

But isn’t there a mechanism in place to distinguish
if a hint is for 1-bit, grayscale, or CT? I thought I read
Vincent say that, but I could have misunderstood.

If there isn’t, it seems to me that a good way to avoid
rendering the funky outlines of the old fonts while still
allowing the new fonts to push CT further would be to add
a simple binary flag that tells the rendered whether to
ignore the superhinting or not.

> Y-direction AA for ClearType wasn’t implemented, I believe, until sometime in 2003

Maybe I got the terms wrong (again). I meant the greater smoothness
in the vertical axis that we don’t have yet, but will come with Vista.
I guess you’re saying that that wasn’t put in from the get-go because
the code/standard was not ready in time?

hhp

It wasn’t a question of the code/standard not being ready in time for the first ClearType implementation: as far as I know, it wasn’t part of the spec at all at that stage. It is a refinement that was developed later.

> it wasn’t part of the spec at all at that stage.

Do you (or anybody) know why not?
I mean, even if it wasn’t an obvious thing to include, people
must have noticed the jaggies on the horizontal parts of curves.

hhp

Hrant, remember that CT was designed specifically around the goal of increasing readability onscreen, i.e. with a focus on rendering of typical text sizes. As I wrote above, one doesn’t want y-direction greyscale antialiasing at text sizes, because it reduces contrast on thin stems producing, in your terms, bad notan. Combining Y-direction AA with x-direction CT is a development for display sizes. I may well have been on someone’s radar during the development of the first version of CT, but it wasn’t within the scope of what they were trying to achieve at that point. Remember that the group that developed CT were moving, at that stage, from a research group to a product group, from developing a new technology to actually shipping something. Since their research had been focused on readability, it isn’t surprising that their first product didn’t address rendering for display sizes.

The discussion has moved on but here is part 1 of the requested screen shots - Mac, AA set to light, Georgia.ttf from XP, and I have no idea what it is going to match any longer. Next I’ll try to match this with XP. Does anybody need Mac AA set to anything other than light?

> Does anybody need Mac AA set to anything other than light?

Is there an Ultralight? :-/
That samples looks quite dark on Windows, because
of the gamma difference. For the umpteenth time.

But let me see what I can do.

hhp

Not much we can do about the gamma difference, other than documenting it.

Time now to do some serious comparison, followed by some close-up analysis of what is happening at the subpixel level. Thanks to Bill for preparing the three Mac samples. Thanks to the Punchcut folk for providing the storage and bandwidth :)

Images 1-3: Mac OS X Quartz rendering, with strong, medium and light antialiasing. The medium setting is apparently what Apple recommend for LCD screens. [Note: the top of the light sample is cropped too tight.]

Image 4: Acrobat CoolType rendering in Windows Acrobat 7.05

Image 5: ClearType rendering in Windows XP. This is as I have CT tuned on my Dell system; a more thorough test would involve different kinds of CT tuning.

Image 6: ClearType rendering with subpixel positioning.

I’ve matched ppem height and linespacing; note that there is a slight set width difference between the different renderings. You can see this in the first, side-by-side comparison graphic. Each column is 85 pixels wide; notice the variation in letter cropping on the right side of each column.

John, I’m a bit confused. Please look back to your first (in-thread) sample,
the one in your post of 1 April, 2006 - 12:39am, and correct me if I’m wrong:
1) It exhibits y-AA (like we’ll see in Vista).
2) It’s text size.
So I’m not getting this “display-only” business.

Bill, first let me ask something:
Your previous Cycles sample didn’t exhibit subpixel positioning, but this Georgia one does (look at any doubled letter to see). How could that happen? It can’t be the font. I might guess that you used different apps to render the texts, but isn’t subpixel positioning controlled by the OS?!

Anyway, I’ve prepared two collages. In each collage there are four panels: Quartz, Photoshop (“Smooth” AA), Windows-XP ClearType, and a custom one (Georgette: Georgia with AA turned on for all PPEMs) rendered in Windows-XP sans CT (the point being to try to come close to what a hand-made gs bitmap font with these specs might look like). In the first image no gamma correction was done (except for the Georgette setting, in order to prevent wash-outs). In the second image I lightened the Quartz and darkened the rest by equal proportions: using Levels, I made the midpoint of the former 1.25 and the midpoint of the latter 0.8. The CT might seem darker than the Quartz, but I checked the histograms and they’re overall average levels are very close - the effect might be due to CT having darker stems. Although this gamma correction makes each sample less-than-optimal, it does so pretty much equally and allows for a better comparison; outside of having the images in front of you on both platforms and comparing them side-by-side, there’s no other way to compare fairly.

Oh, and the vertical all-caps text is Mana-13 Bold. :-)

The way I see it, the CT is superior to the Quartz sample in two ways:
1) Hinting. Compare the tops of the x-heights (quite an important region).
2) Better/greater use of subpixels, resulting in darker bodies = crisper text.

In fact, to me, Quartz is only moderately better than the fuzzy Photoshop stuff.

hhp

Huh, I guess we were both working furiously on our samples at the same time! :-)

About the first part of my previous post: forget it. Now I see that
Vista doesn’t use y-AA for “text” sizes after all. It’s just that I clearly
remember a wonderful procession of cap “S”es you put up a while
back that showed y-AA for all sizes. And I thought they ALL looked
really nice. I simply don’t get why it has to be display-only.

> Not much we can do about the gamma difference

As I’ve tried to show, I think we actually can.
And I’ll do it right now for your Quartz-Medium
setting, since that’s the “recommended” one.

> there is a slight set width difference between the different renderings.

Yes, I had that problem too. In fact it seems to infest the
actual PPEM as well... Although only by about half a pixel.

BTW, the CoolType is a welcome addition. Let me take a closer look at it.

hhp

And some close-up analysis of the rendering. On the left, the averaged pixel tint. On the right, the actual subpixel rendering.

The key to the examples is as in the previous post:

Images 1-3: Mac OS X Quartz rendering, with strong, medium and light antialiasing. The medium setting is apparently what Apple recommend for LCD screens. [Note: the top of the light sample is cropped too tight.]

Image 4: Acrobat CoolType rendering in Windows Acrobat 7.05

Image 5: ClearType rendering in Windows XP. This is as I have CT tuned on my Dell system; a more thorough test would involve different kinds of CT tuning.

Image 6: ClearType rendering with subpixel positioning.

John, I’m a bit confused. Please look back to your first (in-thread) sample, the one in your post of 1 April, 2006 - 12:39am, and correct me if I’m wrong:
1) It exhibits y-AA (like we’ll see in Vista).
2) It’s text size.
So I’m not getting this “display-only” business.

Yes, you are confused, or maybe colour blind :)

There is no y-direction AA in that sample. Here is a blow-up:

As you can see, there is no y-direction antialiasing at all.

John, why do you think Bill’s Cycles sample didn’t exhibit subpixel positioning?
And why doesn’t Windows-XP? (Pardon me if you’ve answered this in the past.)

—

OK, here’s the 5/4-from-each-end gamma-corrected collage from John’s samples:

BTW, CoolType (which looks better than I ever remember seeing it; better than Quartz, although still not as dark/crisp as CT; and unusually narrow for some reason) seems to be using some hinting, no?

hhp

It’s just that I clearly remember a wonderful procession of cap “S”es you put up a while back that showed y-AA for all sizes. And I thought they ALL looked really nice.

I can’t remember what sizes I showed in that progression, but at the smallest sizes the y-direction AA is suppressed. Here is a broad progression (thank goodness for the new image scr