V.A.>My question into this is , could a similar approach aid screen rendering of a font in any way ? Could a similar approach help in hinting of a font?

Any two identical ingoing values (in x) that are submitted hinted or unhinted to the CT rasterizer will come out as an identical number of pixels or sub-pixels. A similar but unidentical group of values will not. So, if the difference in an unidentical group of values is not important, much less beneficial, to the screen font, quantize or face quality issues.

M.D.>...is the image you posted supposed to represent some 'pinnacle' of screen font design?

You can't style a screen font to please everyone, but subjects get it relatively. You can't weight a screen font to please everyone, so I did something about it!
You can't please every pixel picker, but if I point out the quadrillions of misplaced cleartype pixels relative to a few here, I absolutely don't get it :?
Is that old illustration above the pinnacle of screen font design? relatively or absolutely my son?

>>Is that old illustration above the pinnacle of screen font design? relatively or absolutely my son?

do you mean Beats illustration? if so, then with ye olde pixel blocks, there was always room for interpretation, but not that much room.

the image you show, seems to contain a good bit of blur, almost like no hinting at all.

Beat: Even the outlines that have been quantized as above get re-quantized (rasterized, or sampled), causing raster tragedies and requiring hinting.

Right. Hence my earlier comment:

I've been working on fonts that have a prioritised ppem size, so I quantise for that size and then work outwards, watching the relationships of verticals and horizontals gradually degrade until, at some larger size, they coincidentally coalesce again.

MD>the image you show, seems to contain a good bit of blur, almost like no hinting at all.

Lol...Please, show a specimen with a higher ratio of black pixels to non-black pixels in the same size range, 8-16 ppm, of a font you "approve". Something with a solid black core in every letter and consistent x stem weights throughout. I will keep asking this time instead of letting you off as usual. Habeas proofus Mike.

Beat>Show the font makers of this world that x-instructions...

See the problem? E.g., if mike is the authority at MS, and he can't see, or produce, specify or evaluate anything close to quality screen type, how is Joe Blow type designer gonna get an education?

JH>...at some larger size, they coincidentally coalesce again.

but... Only the repeatedly weighted and located stems coalesce again. Besides the repeating 1st stem of H, e.g., H, J, M, N, T, U have stems that are rarely if ever consistent with CT, e.g. What do you do then?

DB> I will keep asking this time instead of letting you off as usual. Habeas proofus Mike.

Ask away

DB> See the problem? E.g., if mike is the authority at MS, and he can't see, or produce, specify or evaluate anything close to quality screen type

if DB is the Pope, and based on what I see as the best he can do, then God help us!

Beat - re your 'quantised' lowercase m.

I have done similar experiments. Some seem to work ok, though i did them more as a way of stimulating a working brain, rather than as a design process. I did conclude though, (without any proof whatsoever!), that as this sort of process creates 'key waypoints' that fitted the grid at specific size intervals, (in your illustration those waypoints are 12, 24, 48 etc at 96dpi) then surely the points between waypoints would at least inherit 'some' of the grid fitted qualities of the waypoints. Seems like a fair backbone system for laying out a font design for digital screens. For example, i noticed that in a system where the key waypoints were 12, 24, 48, then actually the intermeadiate points (10, 18, ... ) were pretty well fitted too. Sort of makes sense?

Dave, here is an example of hinting combined with DirectWrite ClearType. This example includes y-direction antialiasing, although for greater contrast at lower sizes, this can be disabled via the GASP table. For most body text fonts, this approach of disabling y-antialiasing works well.

In my example I have not done this, to match what you have shown. If I had your fonts, I could do a closer proof. In these hinted examples, the approach is to grid-fit the y features, Cap Height, baseline, x-height, and hint in. This maintains a higher contrast at these alignment zones. in your examples, you don’t do this, but rather have greyer pixels defining the alignments. see the top of the Caps, in the first line of your example.

this example I am showing maintains more contrast. I don’t think however that at lower test reading sizes, that the y-antialiasing is beneficial.

M.D.> Ask away

Mike, do you have a specimen of what you mean by less blurry over the range of low resolution anti-aliased weights from thin to black, and from 8 to 16 ppm, that can be viewed at a single distance? Or, just one weight? ;)

Here is a closeup of Franky my way, with Calibri and MS's version of Helvetica below.

Notice the solid black cores of the letters on top, as opposed to the less solid cores you appear to be saying are less blurry? Y and then y, also show what happens when the grand theory of CT collapses, which it can on any character in the small size range, without warning to, or concern for... the word ;)

M.D.>if DB is the Pope, and based on what I see as the best he can do,

The best the I can do? practically, is much worse than that old specimen. But I think most people got, and get the idea.

M.D.> ...then God help us!

I have it on very high authority that it's we who are supposed to be helping Him.

I dont have a sample, but if I do at some point, I will post it. Trying to combine hinting and CT+Y at smaller sizes reduces the contrast. If you want to do it, then I believe that keeping the alignments as sharp as possible will help maintain a higher level or contrast in the text, than not alighing. When I view your samples, I see the blur at the cap heights and x-height.

That really really light grey stuff is quartz rendering outside the contour and as such is out of scope for this demo.

@mike_duggan

"here is an example of hinting combined with DirectWrite ClearType. This example includes y-direction antialiasing, although for greater contrast at lower sizes, this can be disabled via the GASP table. For most body text fonts, this approach of disabling y-antialiasing works well.

Please see my comment above.

There seems to be some confusion about what results various settings in the GASP table provide, so I'll ask again:

What is best practice for the GASP table?
And if there is no "best practice", what, at least, are the key result areas and basic criteria for selecting one setting or another?

There exists a rendering system that takes the idea of solid stems (not antialiased) to the extreme. Perfectly black (actually, very dark grey) and without any color fringing around stems, not only in small sizes, but anywhere:

That is pretty interesting. It looks like they are using old system fonts which have aliased hints, they are using all the hints and then they are anti-aliasing. Freetype probably.

Gasping for straws I think deserves it's own thread.

>Google fast flip

ӨMG! Has Raph seen this!?

I wonder if this is to aid compression of the pages?

Agree a separate thread would be good.

>>That really really light grey stuff is -quartz rendering- outside the contour and as such is out of scope for this demo.

so I was right about no hinting ;)

>>Gasping for straws I think deserves it's own thread.

>>Agree a separate thread would be good.

I think DB meant a new thread on GASP, not Fast Flip... but anyhow you have started it now, just not sure it deservers its own thread ;) If someone wants to start a GASP thread, go ahead.

Quoting Vernon “Sort of makes sense?”

Sort of—but I still prefer tackling font rendering issues in code, because I’m comfortable writing code. Certainly more comfortable than designing a font.

This seems ironic or ignorant how Mike laments “a good bit of blur” in David’s example, because it has a little bit of gray on top of solid black bars, and then turns around to show us an example that has some of the worst displayable contrast and blur on the stems.

First line of Mike’s example, first ‘R’ left stem:

According to the W3C’s Web Content Accessibility Guidelines (WCAG 2.0, §1.4.6), on a scale of 1 to 21, with 1 being worst (gray on gray [sic]), and 21 being best (black on white), the combination of “royal blue” against “buttercup” yields a CONTRAST RATIO OF 1.33:1, which is marginally better than what you’d get for middle gray on middle gray.

By contrast, for the same type size (9 pt at 96 DPI) in David’s example, top bar of the first ‘E’

for the combination of “black” against “gainsboro” the W3C metric yields a CONTRAST RATIO OF 15.31:1.

For reference, the WCAG 2.0 recommend a MINIMUM CONTRAST RATIO OF 7:1 for type sizes below 18 pt and AAA Rating.

I’d encourage everyone to draw their own conclusions. Mine are presented in §6.1 (end of §6.1.1 to beginning of §6.1.3). In Mike’s example, there is simply more “color fringe” than “black core.”

>> I’d encourage everyone to draw their own conclusions.

yep

Beat> I’d encourage everyone to draw their own conclusions.

Though it'd be infinitely better for readers, if we could hint to our own conclusions and not be restricted from serving our markets to the utmost of our abilities, by the opinions and technologies of a very few, as is now the case.

Exactly! That’s what I’m proposing in §6.3.6 and §6.3.7. Of course, with Quartz ignoring any and all hints, this is hopeless, and with DirectWrite only allowing fractional pixel positioning (sub-pixel positioning), this is not much better, certainly for anything below 200 DPI...

Beat.

I made the mistake of taking the screenshot from VTT, which results in extra bleed above the Cap height, and below the baseline, even though these alignments have been yanchored to the baseline and cap height grid. Why does VTT do that?

Here is a shot from a DirectWrite client, which eliminates this bleed. see top and bottom of E, above and below is white.

my point was, that if you want to hint a font to display with x+y CT, I think it is better to have these alignments fit to grid, and not have them defined by less than black pixels.

And I think my point is that I was demonstrating a broader and deeper issue, everyone knows what you are talking about exactly. I mean when I'm finished hinting for CT, there are no weeny weight gray pixels hanging out, just huge stripes of orange, burgundy or tan where I don't want em. Please Note, I do not mind the blue or grey as used in your last illustration ;)... Kind of makes me wonder if there is nothing wrong with grey in y, why not use grey in x as well! :)

>>And I think my point is that I was demonstrating a broader and deeper issue

is this your deeper issue?

displaying over the range of low resolution anti-aliased weights from thin to black, and from 8 to 16 ppm, that can be viewed at a single distance

>>everyone knows what you are talking about exactly.

everyone.. great!

>>DirectWrite only allowing fractional pixel positioning (sub-pixel positioning), this is not much better, certainly for anything below 200 DPI...

how do you come to that conclusion?

Mike, your hinting strategy has little or nothing to do with VTT. The small amount of extra bleed originates in the sinc filter proposed by MS Research at the time, which is the correct kind of anti-aliasing filter. DirectWrite may have chosen a box filter, instead, which doesn’t get you that extra bleed, at the potential expense of being less smooth in almost-horizontal glyph parts. This is the same kind of filter that is used in standard gray-scaling as well.

But that’s beside the point. Have a look at the 4th E in your size ramp (12 pt at 96 DPI). Its stem is a combination of cobalt blue and tawny orange. This combination yields a blurry mess with a WCAG 2.0 Contrast Ratio of 1.37 only. You can look at this in two ways: You have a 2-pixel wide blurry stem of vibrating colors, or you have something blueish that hardly distinguishes itself from an orangish background, like I did in §6.1.2 with the Schillerstein example. Neither way to look at it gets you anywhere near the high contrast of David’s example—not even anywhere near the minimum WCAG 2.0 recommendation of 7.0 for point sizes below 18 pt.

Speaking of hinting strategy and yanchoring, why is it that there is a 2 pixel jump in cap height between #6 and #7, but no jump between #5 and #6?

Quoting Mike: “how do you come to that conclusion?”

Simple: Below 200 DPI the stems get too thin for their black core to dominate the color fringes, and fractional pixel positioning (sub-pixel positioning) thwarts any intentions to optimize what little stem width is left for rendering contrast (cf §6.3.2).

you spend your time quoting numbers and references. Have a look at some type sometime, on a device below 200, say between 150 and 200. SPP works just fine. It also can work well at lower resolutions.

>>Speaking of hinting strategy and yanchoring, why is it that there is a 2 pixel jump in cap height between #6 and #7, but no jump between #5 and #6?

I adjusted the Cap height to round up @ 20ppem, the rest is the natural rounding based on the cvt value.

Beat> DirectWrite only allowing fractional pixel positioning (sub-pixel positioning)

I think DWrite supports other modes, I think IE 9 compatibility mode is not sub-pixely

Mike> I think DB meant a new thread on GASP,

Ha, you're probably right. Oh well, at least the new thread may keep this one on-topic.

Glad we have established that SPP (sub-pixel positioning) works just fine for looking at type between 150 and 200 (DPI).

Now let’s start reading text in real world.

>I think DWrite supports other modes, I think IE 9 compatibility mode is not sub-pixely

By definition, one would hope so, but no one can use that mode for anything useful, can they?

Mike, what do you think of my suggestion to extend the gasp table to be able to turn off/on sub-pixel positioning at specific ppem sizes/ranges? This is something I am interested in because fonts that are being designed to a full pixel grid at discreet ppem sizes are being thrown off that grid by sub-pixel positioning when used on the same line of text as other fonts not designed to the grid. This leads to some bizarre and distracting situations: I have an Arabic font spaced to a full pixel grid at 12ppem with most stems snapped to pixel edges, resulting in high stroke density and consistent glyph rendering at that size when the font is used in the first half of a line of text, but then if a different font is used to insert even a single glyph in the middle of the line, the same Arabic font in the second half of the line looks totally different because the grid has been shunted onto subpixels: dark and crisp in the first half of the line, light and fuzzy in the second. What I would like to be able to do is to say that a font designed to be spaced on full pixels at given ppem sizes should always be spaced on full pixels at those sizes.

Beat, I'm not sure that it is fair to cite the WCAG recommendations re. contrast with regard to one vertical stroke that, as the same englargement shows, is atypical. This is not to say that the rendering of that stroke is not a problem -- I'm not happy about it at all --, only that the WCAG recommendations surely refer to overall text contrast.

What interests me about David's illustration is that it manages to both have higher stroke density and yet to look fuzzier than Mike's. I presume we have Quartz to thank for this, and that Apple manage to make even quantised designs fuzz out even when they don't grey out. I'd like to see the same size range comparison as rendered in GDI and DWrite ClearType.

The other thing that interests me about David's illustration is what happens in this medial size (14ppem, yes?)...

Gasping for straws it is!
(Been feeling like the pivot man in a circle jerk. :)

rich

J.H.> Is this an example of the gradual degradation as one moves away from the optimally quantised size, to which I referred earlier?

In absolute quantizing, which this old demonstration represents, there is not much gradual degradation, to me. Now... people are very used to wysiwyg quality rendering, so, it is most difficult for people to see it perecisely, unless you show something maybe like this:

Mini-waterfall above, (and if it's not utterly clear pixel-ed, don't view it in your browser, drop it onto your desktop and use your default graphic viewer), is the font, Franky 14 Thin composed at 8-15 ppm. Mini-waterfall below that, is each size appropriate, (and absolutely quantized) font of Franky Thin, (until the weight merges with the regular), and then 9 and 8 ppm Franky Regular.

Then I changed the text slightly to show how easy it is to manipulate opinion if you want to cherry pick arguments about font rendering ;)

So, what you observe is probably not gradual degradation, it's probably an example of; 96 (glyphs) x 48 (weight/sizes) x 6 (approx. ave. params. per glyph?) / 24 days = 1,000 or so features to grid align per day by hand. Or, an example of the gradual degradation as one designer rests his face on the grindstone in motion.

J.H.> I'd like to see the same size range comparison as rendered in GDI and DWrite ClearType.

Me too, but right after the last time I tried to fight through word files not bringing the proper styles from the Mac to Windows, Windows rendering 1/3rd the fonts shown here too light to see in it's un-familized menu, 1.333 pixels per point everywhere, and word not using fractional points — that was when I stated that it was just too much, "Competition" as you put it, to try and help Windows users with fonts... this way.

After all, that demo was done for Mac, where hinting and antialiasing are never combined. On Windows, full x and y hints are the way to effect what's in this demo on Windows, (using "Standard" rendering on lots of weights).

Thanks, David. I wasn't sure if, in the original image, I was looking at absolute quantisation (size-specific fonts) or relative quantisation (range-specific fonts), and wondered if, the latter being the case, some of the things I was seeing were due to rounding off the relative quantisation in non-optimal sizes.

With regard to rendering demos, you could make a nice live demo with Franky web fonts, and then I could take a look in various browsers on Windows. :)

...nevertheless, here's a peak at this Windows font-head's head crash.

When I try to use MS Publisher despite all the "competitive" barriers mentioned in my last post, because Publisher does allow fraction points sizes, (giving me a chance to get the Franky fonts and their ppms properly composed), it's a completely different gamma (below), vs Word (above).

So does Franky have any hinting? I thought you were quantising and hinting, à la Verdana.
_____

Word and Publisher are both, ultimately, print media producers -- despite the creeping bloat of crap web export functions --, and what they're aiming for is wysisneuwygwyp (what you see is something not entirely unlike what you'll get when you print). If we're talking about fonts for screen readability, then we should be looking at HTML/CSS/webfont examples: wysiwspsigtttrohp (what you see is what some poor sucker is going to try to read on his phone).

J.H.> I thought you were quantising and hinting, à la Verdana.

True of the Reading Endge fonts which came after Franky.

Quoting John: “not sure that it is fair to cite the WCAG recommendations re. contrast with regard to one vertical stroke that, as the same englargement shows, is atypical”

Fair or not—I’ll leave that judgment to this thread’s readers. Here’s how I got there: For the sake of the example/argument, we’re trying to render nominally black text against a white background. With the combination of ClearType, sub-pixel positioning, and the actual pixel fraction on which an individual character/stem ends up, at text sizes and common display resolutions, I get all kinds of colors on these stems, but few if any black pixels.

As a dichromat these colors don’t mean all that much to me, but I do notice that some stems look sharper than others. With gray-scaling (box-filter) it seems fairly easy to see what combination of fractional stem position and width makes stems look fuzzy, and which ones render black pixels as black. With the colors it isn’t—certainly not for me—and hence the WCAG contrast ratio used in the process.

The contrast ratio is an entity I can see: in the “Schillerstein” example referenced above, the various ClearTyped and sub-pixel positioned ‘i’ and ‘l’ seem to render in some “malibu blue” against “peach orange” which means next to nothing to me, but I can see it is blurry, and the WCAG puts a number on that blur, telling me I’m looking at something that’s close to gray on gray.

The 2-pixel wide stem referenced earlier seems to render in a combination of “cobalt blue” and “tawny orange” which again means next to nothing to me, but the WCAG metric puts a number on it, telling me how little they contrast from each other. In other words, I am looking at a 2-pixel wide stem in gray where the actual/natural stem width is about 1 1/3 pixel. The colors with little contrast blur the 1 1/3 pixel to what looks like 2 pixels.

I picked a single stem as an example to avoid bothering this thread’s readers with too many numbers. Numbers seems to be discouraged—unfortunately so. If someone tells me it’s hot outside, this means little to me, because what’s hot for them may mean a furnace to me or a very pleasant Sunday afternoon, and vice-versa. Tell me it’s 25°C/77°F and I can decide on my own.

Likewise, if someone tells me this text looks blurry or works just fine, this means little, because it doesn’t put an objective number on the blur or contrast. If any of you know of a better method to determine blur or contrast, I’d love to hear. For instance, in David’s sample, I could count the number of black pixels on a stem and would find that there are about none, but it still looks more contrasty. The WCAG metric seems to give me a more useful criterion.

That’s why I don’t have a good explanation what makes “David’s illustration [...] to both have higher stroke density and yet to look fuzzier than Mike’s. What is it that makes it fuzzier to your visual system? If the Apple rasterizer executed instructions, maybe David could ‘put’ the gray at the top on the inside, instead? Or maybe your visual system picks up on black sub-pixels more easily?

There are a number of “tricks” to “boost” stroke density. Deliberate gamma under-correction comes to mind (choose the darkest sample in the ClearType tuner, or similar), along with various mathematical formulae I got to experiment with. If anyone knows what’s Apple’s “trick” and is in a position to tell, I’d love to know.

It all has to work together: Hinting (or outline quantizing in the absence of hinting), rasterizer, gamma, …, and—importantly—the end-user's visual system. If, like David, someone knows what they’re doing, “it is [easy] to manipulate opinion if you want to cherry pick arguments about font rendering.” That’s why I try to communicate objective criteria and refer to their sources, rather than looking at type and making subjective determinations. For, when it comes right down to it, I won’t accept “hand waving” or the statement that “some Y-men said so…” for a fact.

@Vernon Adams
I’m a bit late to this discussion but still wanted to point out Zuzana Licko’s contribution to quantising, which she did when she designed Base 9 and Base 12 in 1995.

Hi Mr Stamm, especially your latest comment makes me wonder who the anticipated target audience of Raster Tragedy is and, depending on the former, what the message is. Does it address type designers? Font producers? Rasterizer developers? And what would be the consequences for each of them?

Beat: “[...] a blurry mess with a WCAG 2.0 Contrast Ratio of 1.37 only.”
I agree that those CT stems are blurry & have lower contrast but I think the methodology for calculating contrast ratio is incorrect and gives much lower values than they really are.

In this thread, you used the blue and red color from the same stem to calculate the contrast ratio. So the calculated contrast is the inner contrast of the stem, which is not very useful. But what is the contrast ratio between background (white in this examples) and the stem? Something different and higher.

Using colors from the stems as a background does make sense when they are actually a background, like in “Schillerstein” example in the “ill” letters. But even here something bothers me, the images which are supposed to have the same contrast ratio look like they have much worse contrast than original.

One reason is that the contrast ratio is calculated for “ill” letters and then applied for the whole word, although some stems are on white background (which means higher contrast) and there are also perfectly black pixels for horizontal features which have a very high contrast.

Another reason is that this method completely ignores the subpixel effects heavily used by ClearType. The Schillerstein image could be viewed on a rotated LCD screen, or on B-R-G screen making the hard coded rendering a mess, yet the proposed contrast ratio is exactly the same in all circumstances.

Furthermore I think the subpixel effect is also a variable, depending on viewing distance, DPI, user settings... When looking closely I see more color fringing and less contrast but if the distance is great the colors are almost gone and contrast seems higher. So: When looking very closely (or on a magnified image) the calculated contrast ratio in “ill” is correct. With the higher DPI/distance it’s harder to perceive actual colors, subpixel rendering takes effect and the contrast ratio is not the same any more. This is also perhaps a reason why there is no definite answer for how much does CT increase resolution.

I am not sure how to properly calculate contrast for antialiased type. First thought: with grayscale antialiasing it could be that you have to calculate the average gray in the stem and then use this value as a type color. And similar with subpixel AA, only using the luminance of each subpixel instead of the whole subpixels. But the correct method is probably more complicated and includes the fact that one very bright color in the dark stem contributes only very little to the lowering of the contrast.

Also the blurriness, if we define it mathematically like some sort of filter (but exactly how?), and the contrast ratio are independent. I can imagine glyphs with two different blurry levels but with same contrast ratio, and the other way around, glyphs with two different contrast ratios but the same blurriness.

If you think that CT Schillerstein example is very bad, well, it gets even worse in terms of contrast. DirectWrite has much less prominent colors by default setting. Color fringing is reduced but on the other hand there is more blurriness and less contrast, generally speaking. Some stems, in this very sample letter “i” get rendered extremely lightly but than again, some stems have relatively high contrast (second “l”).

PS: I hope I don’t go into details to much. I learned a lot from The Raster Tragedy at Low-Resolution Revisited and really like it.

Beat, I'm going to avoid talking in terms of contrast, because I think what is really at issue is what I call stroke density. Contrast is a problematic term because it has a different common meaning in typography: stroke weight modulation, i.e. contrast between thick and thin strokes normally of the same stroke density. I also think by talking about (figure-ground) contrast we are talking about the symptom rather than the cause: if you have good stroke density, you can have whatever contrast you like, i.e. you can set light grey text on a dark grey background if that is what you want to do, and the structure of the letters will remain intact even if the contrast is not ideal for reading, which is not the case if stroke density is diminished.

The paradigm of stroke density is black ink, which is equally black on the page whether the stroke is a main stem or a hairline. This is not only the paradigm of typographic printing, but of the much longer, global manuscript tradition. I do not know of a single writing system that did not favour media that produced strong and consistent strong density. Even when such media were not available, people tried to get as close as they could with what was at hand. There is no writing system I am aware of that sought to exploit shading as a feature for quotidian text production and reading. So why are we even contemplating screen rendering mechanisms that rely of fuzzy shading to render letter shapes? Primarily, I think, to increase individual typeface verisimiltude, i.e. to make fonts on screen look more like identifiable individuated designs and less like generic bitmaps. Part of that involves something that I consider potentially beneficial to reading: filling in the corners between pixels so that curved strokes look like continuous strokes and not like disjointed sequences of straight stems and individual bricks. I say ‘potentially’ beneficial to reading because I think their value has to be measured against the overall stroke density of letters and against the definition of the figure-ground interaction (sharpness or blur).

Which brings me round to ‘Apple’s “trick”’ as you refer to it. There is a direct correlation in Apple rendering between stroke density and blur or fuzz: the stronger the stroke density you want, the greater fringe blur you have to put up with; conversely, the sharper the edge definition you want, the lower consistency in stroke density you have to put up with. For me, this is a lose-lose proposition, because I can't put up with either, and I do not believe that verisimilitude to a single unhinted set of outline across an open ended range of sizes is the right goal. TTF hinting enabled us to to tailor designs to specific device sizes, in effect implementing a form of optimised scaling from a single outline set. If hinting is taken away, we have no option but to create the individual optimised outlines for each size, as David did with Franky, because there is no other way to optimise for device sizes.

J.H.> ...because there is no other way to optimi[z]e for device sizes.

Relatively, agreed. But abolutely, there is another way, without anyone changing their rasterizer, their scaler, without leaving the dominant font format, or changing even the way type is specified by the user, (simplifying font specification by an uncalculatable order of magnitude in many cases for both print and web).

Back when Longhorn was a justborne calf, OFF was not on yet, WOFF had not yet begun to be forgotten, and this discussion was new... (and I want to render tiny big context here: Apple and MS were rightfully proud of their renderers, they didn't see need for any other options, a 'universal rise in resolution' was on the way "There are several 100 208 dpi monitors outside my office right now David", said one high ranking MS employee;), I suggested to you and this audience, (or was it the ATypI list back then?)), that the only way out + a long term right thing t.d.? — is Variation Technology on the client side, dear developers, and John.

@Karsten: I had a diverse audience in mind: font producers, interested end-users, and to some degree software or website developers. The dilemma with writing about font rendering is that it touches on a broad spectrum of topics which are not equally appealing to everyone, yet all the pieces of the puzzle have to somehow fit together for the end result.

I sense that some of this thread’s readers seem to have some kind of aversion for numbers, but I don’t know why this could be. Most of the math is mere arithmetic, adding and subtracting pixels and fractions of pixels, much like adding up sales and expenses when running a font business. Beyond that I’ve tried to accompany the math with a description in plain English (with the exception of §4.0.3)

When it comes to hinting in TrueType, the barrier may be TrueType itself. It takes a combination of computer geometry and programming in an obscure assembly language called TrueType, and a good deal of engineering to cater for the various font rendering methods and end-user preferences—assuming (and hoping!) the rest of the world doesn’t follow Apple’s example to abandon hinting altogether. Unless, of course, Apple’s example reflects your preference, in which case hinting is a non-issue.

@Miha: The reason I used the blue and red color seemingly belonging to the same stem is because that’s how stems are rendered when positioned approximately halfway between pixel boundaries. We are at the limit of what can be resolved by pixels. There is no “room” for white in-between. Put another way, if I render ‘ill’ in bi-level, with all stems positioned on pixel boundaries, using blue pixels against a red background, I get the same set of pixels as when I render ‘ill’ in sub-pixel positioned ClearType, nominally in black against a white background.

The numbers for “peach orange” (#FFD093) and “malibu blue” (#69B5E9) on white are 1.43:1 and 2.24:1. When the sub-pixel sequence is reversed (ie text rendered for a BGR screen is viewed on an RGB screen), the numbers can change, since red, green, and blue make weighted contributions. For RGB rendering, blue (#69B5E9) on orange (#FFD093) yields 1.57:1, while BGR rendering #E9B569 on #93D0FF yields 1.13:1.

Sure, the contrast isn’t all the same for the rest of the sample word; what I tried to show is what it would look like if the entire word were rendered the same way. If only part of the word is rendered with low contrast or high blur, it’s simply harder to see what this may do to the process of word recognition.

Also agree that we should separate the concepts of blur and rendering contrast (or stroke density), and that an appropriate mathematical model of blur would involve some kind of a filter. In turn, this gets us into Fourier transforms, convolutions, and what not college level math—a direction I was trying to avoid.

What we can see without math is the number of black [sub-]pixels (the black core), and the number of [sub-]pixels it takes to “ramp-up” from the white background to the black core (the fringe). For the purposely chosen Schillerstein example, there is simply much more core than fringe, avoiding to say, all fringe, smudging the distinction between contrast and blur.

How to determine this in a simple way that can be explained to a wide audience? For instance, in that 4th E I picked apart from Mike’s size ramp, the outline would have the stem 1 1/3 px wide (4 sub-pixels), it is rendered with 2 px (6 sub-pixels), yet only 2 sub-pixels are solid black. We could define an “aperture ratio” relating the 2 solid black pixels to the total of 6 sub-pixels involved. For larger type sizes or higher dpi, this aperture ratio would increase, but without filter that models the contributions of the fringe sub-pixels I’d hesitate to put a number on it.

@John: I was struggling with the terminology given the relative generality of the word “contrast.” At the time, separating rendering contrast from design contrast is the best this engineer could come up with. But if stroke density is more common and less problematic than rendering contrast, I’ll be happy to revise the text.

Also, separating figure-ground-contrast from stroke density makes sense, certainly at large enough ppem sizes where we don’t get all sorts of symptoms mixed up. In technical terms it reminds me of the difference between the alpha channel and the text/background color pair blended by the alpha channel. I’ll need some time when back from vacation to give this some deeper thought.

Giving up stroke density for verisimilitude is not my preference, either, particularly when I have to read text, as opposed to looking at a print preview. But people’s preferences vary, which is why I suggested to make hinting more adaptive and allow end-users to select their preferences in a control panel that goes way beyond the ClearType control panel. That is, if future rasterizers execute any instructions at all.

Thank you. I am not scared of numbers, I only think that numbers alone are not enough. And TT instructions are not that obscure.

Since you mention "following Apple's example" – perhaps the first thing to do is pointing out that there are two fundamentally different approaches to rasterization, i.e. two different & mutually exclusive rasterization ideals or goals:

Goal 1) Rasterizing true to the device grid. Method: pre-rasterization grid-fitted scaling. (Microsoft, Adobe.)
Goal 2) Rasterizing true to design. Method: linear scaling and modulated rasterization. (Apple, Karow.)

Both of them are legitimate goals/ideals, yet: From a goal 1) perspective, asking for methods originating from goal 2) can only be perceived as compromising goal 1). And from a goal 2) perspective, asking for methods pertaining to goal 1), like grid-fitting, even if a little bit, can only be perceived as compromising goal 2). Now there are two things that bother me about both Raster Tragedy and this subsequent discussion. One is the obvious attempt to reduce questions of goals/ideals to questions of methods, technical questions. Dealing with the latter, however, is pointless as long as one is not clear about the former. The other is that that the goal 1) approach is presented as rasterization-as-such and ideal rasterization in one when it is but one specific approach to rasterization among others.

You and John are asking for more options. Yet, noticeable in Raster Tragedy and even more evident here, the problem is not too few options but too many and on too many levels. You mention catering "for the various font rendering methods and end-user preferences". This is the source of problems, Microsoft Windows's problems actually, which you present in Raster Tragedy. These problems are self-made problems. And the solution is not adding more options but reducing options. Allow a font to clearly express whether it expects goal 1) rasterization (b/w or Standard or ClearType smoothing) or goal 2) rasterization which then is binding – regardless of applications' or, worse, end users' preferences. (This is not about goal 1) vs goal 2) but about failed infrastructure design.)

Type designers' expectations. I am certain that most type designers with a print background design type with a goal 2) perspective in mind and (a misunderstanding) consider 'hinting' as, well, some additional data needed to please Windows's rasterizers. Most designers just want to design type, not program TT instructions. Like designers just want to design books, not program PostScript. Then, economy of input vs output. Microsoft's goal 1) approach is highly demanding as to the required input: production work, amount of data produced, bothering users with options. Apple's goal 2) approach isn't. Feeding Microsoft's goal 1) approach rasterizers with the same input as Apple's goal 2) approach rasterizers gets me rather poor results. There are other factors that render a technical solution & its methods (in turn based on one or the other goal) practicable. In the real world there are limitations on time and budget. These do not necessarily speak against goal 1) rasterization as such but against current methods to achieve it. In so far it were nice if Microsoft would acknowledge the real world and offer, as an alternative, better goal 2) rasterization too – not for all fonts, but for those that ask for it (see the preceding paragraph).

David: Variation Technology on the client side

Yes, thanks for the timely reminder.