CT Design Guide

Rob O. Font's picture

So is this right?

Alpha CT Omega Font Spec.

Take TT outline that has been made for screen use, e.g.:
a. alignments quantized to a norm of 8, 2 for descent, etc.
b. vertical stems quantized to 8, Cap round and square, etc.
c. horizontal stems quantized to 4, 2 thick, two thin for O.S* e.g.
d. all laterally and bilaterally symmetrical contours, are exactly.
e. Quantize all kerning data.
f. There are also built-in assumptions about good screen letter design including, but not exclusively, managing maximum distinctiveness-in-appearance among 1lI!ijïíî and ¡, e.g.

Additional CT specific outline manipulations:
a. for full horizontal adaptability to the rasterizer,
1. Quantize all horizontal counters.
2. Quantize all inter-character spaces.
3. Quantize all kerning data.
4. Lighten all diagonal strokes.
b. for full familial adaptability to the rasterizer,
1. Lighten all diagonal strokes in Italic.
2. Lighten all diagonal strokes in Bold Italic the same amount as
was reduced from the normal italic, (and from roman diagonals?)

Quantize, in this context, means to reduce an indiscrete group of values to a few discrete groups by averaging them together. This should be done to the values, representing features of typefaces, whenever the complexity of these features far exceeds the ability of the output to display them to the user.

Lighten in this context, means to remove areas of black (that would otherwise be controlled by TT hints).

hrant's picture

Nothing?

hhp

Si_Daniels's picture

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

Si

canderson's picture

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?

Si_Daniels's picture

[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

mike_duggan's picture

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

Rob O. Font's picture

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...

Si_Daniels's picture

> 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.

mike_duggan's picture

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

hrant's picture

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

mike_duggan's picture

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

hrant's picture

> 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

vinceconnare's picture

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.

Si_Daniels's picture

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

Fixed, thanks Mike.

Rob O. Font's picture

"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?

hrant's picture

> 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

hrant's picture

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

hhp

vinceconnare's picture

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.

vinceconnare's picture

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)

hrant's picture

> 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

hrant's picture

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

vinceconnare's picture

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.

hrant's picture

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

hrant's picture

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

John Hudson's picture

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.

When I was designing Constantia, my solution to the issue was to make the roman a touch darker than I would have for a purely print type, and this gave me more leeway with the weight of the italic: I could ensure that it didn't render darker than the roman without making it too light when printed.

See: http://www.tiro.com/John/CTroman-italic.gif

[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.]

John Hudson's picture

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

hrant's picture

> 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

paul d hunt's picture

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

hrant's picture

Ah, touché.

hhp

Rob O. Font's picture

"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.

hrant's picture

> 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

John Hudson's picture

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.

Rob O. Font's picture

"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.

hrant's picture

> 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

Rob O. Font's picture

"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.

hrant's picture

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

John Hudson's picture

Can you give an example?

No.

John Hudson's picture

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.

John Hudson's picture

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.

hrant's picture

> 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

John Hudson's picture

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.

hrant's picture

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

John Hudson's picture

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.

Miguel Sousa's picture

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.

hrant's picture

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

hrant's picture

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

billtroop's picture

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.

billtroop's picture

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.

hrant's picture

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

John Hudson's picture

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 :)

hrant's picture

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

Syndicate content Syndicate content