I know what I’ll be reading tomorrow afternoon. Thanks, all.

Thanks, John!

ChrisL

,cite>I know what I’ll be reading tomorrow afternoon.

Make sure you have a lot of alcohol the drink and a hammer to periodically hit yourself in the head.

Believe me, from experience, it is the only way to get through these white papers.

I think you just described anything involving hinting generally. But the MS whitepapers are pretty good compared to some of the networking RFCs I’ve had to read.

Good lord, James, I thought you were sarcastic. Did you read it already?

I was very glad to see this paper and I've carefully read it. It is intended to help those who want to make their new or old hinted TT fonts to be compatible with Cleartype. So this is my case. I hoped there will be an answer to my question which I asked in this topic - http://typophile.com/node/14961 and in FontLab's forum about Cleartype hinting.

I am hinting new Devanagari font using MS VTT application. The question was - how to modify Font program to be able to make deltas for Cleartype only. Horizontal hints are mostly ignored in Cleartype and function 77 (delta instructions) is the only way to correct horizontal position of points. Cleartype is now actually the default rasterizer for LCD monitors and this makes this question very important.

In this paper it is described that this is possible. But how to make this - is clear only for software engineers. I've read the information about rasterizer selectors and return values which can be found in this paper and in TTF specification but didn't understand how to modify function 84 (getinfo) definition to make this possible.

Maybe somebody can say in simple words for a font designer - which text to change in Font Program to be able to make deltas for Cleartype, Black and Greyscale separately and in general.

In this paper it is also recommended to use
#PUSH 4,3
INSTCTRL[]
in prep program in new fonts. This makes ordinary deltas to work in Cleartype as in BW and Greyscale. Maybe this is a choice if the font is designed for Cleartype only. But this is not a solution in my case.

I hope that somebody will help me and my anusvAra sing will at least look like dot and not like line:)

Mihail,

Please contact me off-thread and we'll see what we can do to help.

Cheers, Si

I hope that this white paper stimulates discussion on this issue as Mihail says, Cleartype is now the default Windows scaler and filterer. One of the thickest bottom lines of this paper, I believe, is that Microsoft considers there is 'extra resolution' in the x axis, regardless of the color of that resolution relative to the user's specification of the color of the type.

So, in this paper, the only documented option for using Cleartype, the x instructions go into Microsoft's patented Cleartype filtering, where thinking they can round to pink pixels, or red, or dark blue, or occasionally, black pixels, is encouraged and the letters stop listening to me. With such disobedience, there is no way I can see to effectively instruct x features for the seemingly ever-present 10 to 27 pixel per em range of Latin, and get both the right quantity of periodic changes across the reading space, and the right quality in the transitions between those changes across the reading space for a wide range of widths, weights and designs.

Maybe this isn't a problem in Devanagari, though please let us know how it works out as I'm dying to tally the scripts, designs and even glyphs that can and cannot crawl far enough up in quality in this resolution spectrum, to read text as people do.

My feeling for Latin, is that the user (hundreds of millions actually), is being constrained to fonts that work with this technology, because some fonts made for older technology did not work. So, instead of simply investing in disabling the few offending instructions in a very very small number of fonts, Microsoft invested in a whole bunch of other things that practically 'disable' all of x from a typographic point of view, for the spectrum I describe. Nothing incoherent, mind you, just disabled. :)

The original ClearType recommendations are still the same as they were on release of the Cleartype Collection in 2004: hint as you normally would, but without post-interpolation deltas, and if you or the users don't like the quality, compel them to find the appearance menu and change all of their OS rendering to "Standard" so our fonts will look better. Is that still right?

Cheers!

David,
I think the conclusion of the whitepaper made it clear that the recommended solution is not to “…hint as you normally would, but without post-interpolation deltas….” The conclusion recommends that the font place the sequence

#PUSH 4,3
INSTCTRL[]

At the beginning of the CVT program. When this is done, there are no restrictions on any of the TrueType instructions. That said, the resolution is different when operating with ClearType turned on—but that is similar to other technologies that TrueType has dealt with in the past, such as non-square pixels on screens and printers. The GETINFO instruction can be used to determine if ClearType is being used.

The need of Cleartype only deltas is caused by the natural desire to control (just a little bit) x direction and there are no other means to do this then deltas and moves (horizontal cvt and cvt deltas do not work). If we simply switch on ordinary deltas (#PUSH 4,3 INSTCTRL[]) for Cleartype this not only does not resolve these problems but creates some new difficulties because these deltas have effect on other rasterizers also which do not ignore x instructions. This is a choice only in that case if one do not care about other rasterizers (if font is designed for Cleartype only). It is not convenient at all to correct x problems in Cleartype by general deltas and then again correct these effects by Black and Grey deltas.

Just one example - my greatest problem is a dot (anusvAra, nukta etc. signs). It has (and must have) a shape of rhomb. It is almost twice larger then vertical and horizontal stems. In large sizes this difference is not so clear because of the shape. But in small sizes it naturally takes 2 pixels when stems are 1 pixel. And it is square form and I have to correct this and reduce it's size in small sizes until it will take the shape of rhomb. In Cleartype this correction works only in y direction - so I have the shape of line or triangle. If I reduce the size of dot to the size of the stem - the problem will accure in large sizes and in print. If to use ordinary deltas for correction this in turn will effect the shape in BW and Grey renderings so I have to correct this in turn by BW-only and Grey-only deltas. There will be too many deltas just for one dot (and I have many others). I tried other ways and have some more or less acceptable result but this shape in Cleartype definitely looks bad in many sizes.

> I tried other ways and have some more or less acceptable result but this shape in Cleartype definitely looks bad...

I greatly appreciate you trying to communicate through the language, font and technical barriers and if you were here, I'd give your font a big hug.

>#PUSH 4,3
>INSTCTRL[]

GH>When this is done, there are no restrictions on any of the TrueType instructions.

Which is to say they can be interpreted, but wrongly. When I say mirp and round a stem bound to the grid, if your interpreter don't, that's restriction.

>That said, the resolution is different when operating with ClearType turned on

And to me, working on low res. text, there is no difference between interpreter disobedience in rounding, and no x hints whatsoever.

ClearType scaling and rendering does not work nearly as smoothly, for the resolution spectrum we are trying to deploy readable fonts in, as well as Quartz does.

John has convinced me though, that the difference between completely incoherent and annoying saccade hiccups is currently slightly smaller than the problems we face immediately. ;)

Cheers!

> GH>When this is done, there are no restrictions on any of the TrueType instructions.
DB> Which is to say they can be interpreted, but wrongly. When I say mirp and round a
DB> stem bound to the grid, if your interpreter don’t, that’s restriction.

David, that is incorrect. It does round the stem to the grid. The grid is exactly as I describe in the paper, a sixteenth of a pixel in the ClearType-direction (usually the x-axis.) This leaves you with a quarter of a grid fractional hinting left. It would make no sense to have less precision with the rounding because then you would not be able to fine tune anything.

Given the power of the TrueType interpreter, if you are unhappy with this level of precision, you can develop functions to implement different rounding methods.

svayambhu> If you wish to make deltas that are specific for ClearType, you need to conditionally apply those deltas using information from the GETINFO instruction.

GH>David, that is incorrect.
GH> It does round the stem to the grid.

Greg that is incorrect, or at the very least, misleading to the audience for which you claim the paper was published.
The grid I am talking about, and 'we designers' are concerned with, is the output grid, not what the scaler dreams.
We have 64ths of a pixel to round to in TT, without ClearType, you know... (I invented it).

>It would make no sense to have less precision with the rounding because then you would not be able to fine tune anything.

It makes less no sense to have more or less precision with the rounding than the actual output grid, but please... show me your "fine tuned" ClearType.

Cheers!

...or I will write a black paper... better hurry.

Cheers!

How about writing an RGB paper? :-)

ChrisL

David, for clarity, is the horizontal ‘output grid’ on an RGB LCD screen a pixel or a third of a pixel?

We have a divergence of the scalar grid from the output grid (I'm using these terms for ease of reference to the preceding discussion; perhaps other terms are more technically accurate?), so it seems pointless to insist that one or other application of the single phrase ‘the grid’ is correct. Better to say that the notion of ‘the grid’ as a singular phenomenon no longer pertains. From the rendering side, I can see how ‘the grid’ might always have been understood to be the scalar grid, which coincidentally was for a long time identical to the output grid. From the font making side, I can see how ‘the grid’ might always have been understood to be the output grid, which was happily for a long time identical to the scalar grid.

Realistically, Greg, how is a type designer/hinter supposed to target a 3-subpixel output grid via a 16-unit scalar grid, especially since the sampling of that scalar grid is non-uniformly applied to the different subpixel colours, and with subpixel positioning the outlines may fall relative to different subpixel boundaries? If using compatible, whole-pixel positioning, I can see how delta hints could be applied something like impressionist painting, adjusting until one gets the shape proportions and stroke density one wants -- with the caveat that due to gamma and CT tuning this may not be what other users see --, but once one shifts to subpixel positioning, all bets seem to be off.

The most obvious solution to the proportional problem affecting Mihail's anusvara and nukta is y-direction greyscaling. I know this because similar dot shapes occur in some projects on which I am working, and I am testing rendering in WPF. The hybrid CT/greyscale antialiasing in WPF should have been default in Vista CT. Will it be in Office 7?

> I can see how ‘the grid’ might always have been understood to be the output grid, which was happily for a long time identical to the scalar grid.

Uh Oh, looks we have a newly constrained definition. . . John, lol, sub pixels have been around for a very very long time. Did Matthew design Verdana to the 11 ppm grid, or 33, or was it 176 ppm... let me think.

(Verdana in Vista for Ikea)

Do you'all actually think any type designer considers this to be fit to a grid for readability? Nice I, nice, l, nice i, nice o, nice a. See, I can say nice things about CT. Problem is that we crave 26 "nice" per size, per Latin English l.c, per user, or saccade hiccups. The instructing font designer can only, regardless of whatever you might think to define as the grid, address the hints to the output grid(s).

But let's mosey around this white paper.

Microsoft claims here that because some fonts hinted for aliased rendering include exploding points as a result of diagonal instructions gone wild, the (published) cntrlinst option in ClearType needed to address an imaginary output-independent grid gone wild and ignore the x and d instructions. Simon of Microsoft showed one ancient picture of such a font, but never listed how many, or who's it was, or anything else about that font.

One thing is certain about that font — if it was hinted so strictly for aliased rendering, it should also have been hinted strictly for the glyph widths. And as it likel was strictly hinted for widths, its compatible horizontal metrics can only be reached today with Windows anti-aliasing if that font is scaled by TT's undocumented cntrlinst set to "compatible". No?

There are two diverging points to be made from this. One, is that if Microsoft needed to keep lots of documents compatible, and it needed an option to use widths either from the TT hdmx table in the font, or from the rounding results of something else rendering to the legacy metrics, i.e. other than the metrics CT would yield naturally... don't others too? Don't a lot of people outside of Microsoft need non-MS fonts to be rendered this way? Why is this not documented?

And the other point is, if these exploding points were in legacy fonts on legacy metrics that should only be scaled by the "Compatible" option, why destroy the 1:1 relationship between the truetype instruction and the output grid in the "Natural" option? Shouldn't all and any fonts that even bother a wit for SDPVTL, (the incredibly obscure exploding instruction), be treated to "Compatible" scaling in CT, and the other mode just listen to all the instructions?

P & Vinegar under the bridge. So now: where is the "Actual" option that trusts we know what we're doing with both pixels and sub-pixels all by our typographic selves? Why are we constrained to poorer quality than possible in the resolutions we need to go to the web with? Why is the public constrained to quality that ignores the output grid? Why are we, type designers, not permitted to create a standard of quality for our customers that Microsoft and Apple can envy and emulate?

I've done everything I could to help: pushing customers into "standard" Vista scaling and rendering, pulling others to FreeType, making all the suggestions I could to MS and Apple, and showing hundreds of example fonts. One can redefine the grid to anything one's heart desires, but the circle keeps on closing. The smaller that circle gets, the higher the pressure, the further up this is going to spout, (and the more obvious the 500 lb. boa constrainer in the corner).

Cheers!

David, I'm still looking for clarity as to exactly what you mean by ‘output grid’. It seems important to me that this be defined, not assumed. Obviously MS have assumed ‘grid’ to be something else, so assumptions are clearly not helpful.

I expressed, in my question to Greg, my concern that trying to deliberately affect the appearance of CT glyphs via hints to the supersampling grid seems something close to impossible, except in what I would characterise as an impressionist way, which is not the level of control I think you want.

Resolution/points per inch x point size = ppm, (the grid). It started with the Egyptians and I know this was clear though the Verdana development. I've worked 31 years on making screen fonts, this is the first time I've had to 'straighten anyone out'.... ever. People either don't know it, or they do, but they've never ever made something else up and had to be reeducated, ever.

Cheers!

But of course the Egyptians used ‘cubits’ and therefor pixels per cubit.

. . .
Bert Vanderveen BNO

Okay, David, so the output grid is ppm, i.e. whole pixels per em. Works great for aliased rendering and, as I wrote above, in the case of aliased type the output grid is identical to the scalar grid and everyone is happy (except designers who want fonts to look like typefaces and not like toddlers' building blocks). But subpixel rendering, by its nature, addresses something other than whole pixels, which means that the scalar grid isn't identical to the output grid. Throw in non-linear supersampling for subpixel colour filtering, and the scalar grid has moved so far away from the output grid that there seems to me an unbridgeable gap between them. This is the bit where I think we are agreeing, in case you missed it. The TT hinting model, no matter how we think about it in terms of output grid, is implemented via the scalar grid and ’twas ever so. As soon as the scalar grid diverges from the output grid, hinting instructions no longer apply to the output grid. This makes a whole pile of hints either ineffective or unpredictable in their result. This is the other bit where I think we are agreeing, in case you missed it.

One response to this is to say that the scalar grid should never diverge from the output grid. But I can hear that horse heading toward the horizon and the barn door is falling off its hinges.

Another response to this is to say that since a whole pile of hints no longer do what they used to do, let's ignore all hints completely and just antialias the shit out of everything. Apple call this Quartz, as if the fuzzy-bear type had anything in common with the sharpness and clarity of crystals.

Microsoft's response has been that some hints are worth preserving -- since they help retain stroke density; something that Mac rendering fails at consistently --, and Greg's white paper suggests we can have our cake and eat it: that we can turn back on the hints that are disabled for legacy fonts. But it seems to me that even if you turn those hints back on, they a) won't do what they used to do and b) trying to get them to do anything specific will be next to impossible, especially once subpixel positioning is thrown into the mix.

Greg, has anyone to your knowledge actually made any fonts that use x-direction deltas in CT?

>Works great for aliased rendering and, as I wrote above, in the case of aliased type the output grid is identical to the scalar grid and everyone is happy (except designers who want fonts to look like typefaces and not like toddlers’ building blocks).

The TT instruction set is perfectly capable of scaling letters to pixels, or pixels smaller than building blocks in anti-aliased environments.

>But sub-pixel rendering, by its nature, addresses something other than whole pixels, which means that the scalar grid isn’t identical to the output grid.

Not precisely. It means that sub-pixel rendering is finer than the hinting's grid, and the user's color specification, But assuming there is total instructional control over location of features, sub-pixels can be carefully or wontonly used to represent features better around correct counters and spaces, or make garbage.

There is nothing generally useful in between Apple's approach and letting us loose with our skills. But it doesn't look good for Windows web users or web developers, universally and for the long term. A lot of people have become interested in why.

Cheers!

But assuming there is total instructional control over location of features, sub-pixels can be carefully or wontonly used to represent features better around correct counters and spaces, or make garbage.

Here's the problem as I see it:

ClearType's crown jewels are the colour filtering, and that relies in part on non-linear supersampling. The colour filtering enables Microsoft to retain stroke density, and also to provide users with the ability to tune ClearType rendering. But in order to do the colour filtering they need to supersample in the x-direction so that they can differentially address the R G and B subpixels. Supersampling to a 16 unit scalar grid enables them to assign more units to the G subpixel than to the R, and least to the B --8, 5 and 3, respectively --, and this reflects average human colour sensitivity: presumably for evolutionary reasons, we are sensitive to more shades of green than to other colours. So the colour filtering is important, and the differential addressing of subpixels -- and hence non-linear supersampling -- is important.

So in order for a font maker to have ‘total instructional control over location of features’, that non-linear scalar grid needs to be broken down into sections that relate to actual subpixels, since the location of features is ultimately rendered in a subpixel output grid. So that's a practical difficulty for a hinter. It isn't insurmountable, but it increases the hinting brain hurt, because the distance an x-direction feature needs to be moved across the non-linear scalar grid depends on what part of the grid it is in: if it is in the G section, it needs to move further than if it is in the R or B section. Then, presuming that the hinter has wrapped his head around this, subpixel positioning is thrown into the mix, which means that you can't anticipate in which section of the scalar grid an outline will fall, because the output grid now consists of subpixels from different pixels.

This is why I am intrigued to know whether anyone, even within MS, has actually made a font that attempts to apply total instructional control in the ClearType x-direction. Greg's white paper explains what needs to be done inside a font to enable the full set of hinting controls, but it doesn't demonstrate that having those controls turned on actually helps anyone.

>The colour filtering enables Microsoft to retain stroke density,

WADR, nonsense. Their downstroke density is no better than random. The only reason for any consistency in Cleartype's x direction is from consistency in the contours.

>and also to provide users with the ability to tune ClearType rendering.

I think that little app is a placebo. Does it still employ italic to show the user what text will 'look like"?

>in order to do the colour filtering they need to to supersample...

WADR. nonsense. The hints adjust the outline to the output grid and the rendering can turn on the pixels depending on how much of the pixel is contained in the outline vs not. Supersample in the rendering, sure, but in the grid fitting, bull.

> presuming that the hinter has wrapped his head around this, subpixel positioning is thrown into the mix

Wrap? Not a problem. Hint left stem border hard, move right stem border relatively. The contour takes care of the color and you go on to the white space. You have not done this have you?

>This is why I am intrigued to know whether anyone, even within MS, has actually made a font that attempts to apply total instructional control in the ClearType x-direction

You are kidding me, right. You QA'd and managed the only CT font project of all time, five years ago (?) They never looked, and you never looked, ( I know, I asked. MS said "it's too hard").

>but it doesn’t demonstrate that having those controls turned on actually helps anyone.

And it never will. The real problem we face is that the commonwealth of reading is much bigger and stronger than any government or company. Looks like the only way "up" is a shameful paper I would really rather not write. But as you can clearly see by the intense confusion in the commonwealth of reading, I must.

Before that is published though, I want to say here that up until 2004, I was a universally peaceful and caring member of this industry with good relations all around and no reason to criticize anyone's typographic beliefs, typographic work or typographic origins. Anyone who's known me before and after 2004, knows this to be true. :)

Cheers!

original hints pre-Cleartype and client said some characters like this H looked odd such as one side lighter than the other. The left image had conditional delta (function call to FDEF:77 with CVT VTT INSTCTRL 4,3 added)

So I went through the glyphs and made about 10 changes to make sure diagonals weren't light or heavy etc and then they were a happy bunch of 100,000 Swiss employees.

So yes sometimes the client moans.

A range of sizes at actual sizes, please. Clients are easy if you know them and all their hardware. ;)

Cheers!

no that is how you proof looking at the waterfall and see if something is odd. Then fix it as was done with the H making both the same colour.

So, after you've hinted it and CT has rendered it as it will, then you can go feature by feature, and size by size through the entire font, delta-ing all flaws, (except the right side bearing, I presume), and 'fix' an entire style, (one).

By fix, I mean undo the CT fairy resolution work to the positioning that would have been done right by good instructions.

I've done this kind of thing, but they want a size of two, and cross-platform, off web, that's just better done in the outline.

Or do you have a range of sizes at actual sizes, please.

Cheers!

As I understand, CT rasterizer in Windows 7 works almost like in Vista - so practically one cannot expect that this situation will change in nearest years in spite of all criticism and we will have the same CT problems with spacing and x-stems.

Ordinary TTF hinting effects both screen and print. But CT works only on screen, there are no subpixels in print. So the situation is different and it isn't reasonable to solve CT problems with ordinary means. But exactly this is proposed in MS white paper. Or maybe I mistake and INSTCTRL 4,3 have other not so obvious effects except ordinary deltas in CT mode (but cvt deltas don't work - so one cannot speak about full instruction set).

Greg >If you wish to make deltas that are specific for ClearType, you need to conditionally apply those deltas using information from the GETINFO instruction.

It is clear. But how? Can you help me and write the code of function 84 definition that will make this possible?. Or if it is some kind of MS professional secret, why to advise others to use it? Or where it is possible to find more information about this to try to solve this problem myself? I understand the logic of the function GETINFO definition but I have not enough information to modify it correctly. If this (#PUSH,2,0 #PUSH,4096,32 #PUSH,2,1) works for Greyscale what are the values for CT and for compatible width CT?

p.s. Thinking about CT hinting I suddenly remembered Baudrillard's precession of simulacra.

David, the fact that you think the reasons MS consider supersampling are ‘bull’ doesn't alter my analysis of the problem that supersampling introduces. If I agreed with you 100%, that wouldn't alter the analysis of the problem either. This is how CT works. If your argument is simply that CT shouldn't exist, or shouldn't work the way it does, then debating whether and how x-direction hints are re-enabled isn't the conversation we need to be having.

You QA’d and managed the only CT font project of all time, five years ago (?) They never looked, and you never looked, ( I know, I asked. MS said “it’s too hard”).

Right. That was five years ago, and lack of x-direction deltas was a given for that project. There was no talk at that stage, at least not shared with the CT collection designers, of mechanisms to re-enable those instructions. So this is why I am asking Greg now, now that such mechanisms are being presented, whether in the intervening time anyone has tried to make a font in this way.

JH>If your argument is simply that CT shouldn’t exist,

I did not say that. Clear type already doesn't exist much on Windows.

>...or shouldn’t work the way it does,

I said there needs to be an additional option to end this Constraint of Commerce on the Windows OS.

>...then debating whether and how x-direction hints are re-enabled isn’t the conversation we need to be having.

It is, IMHO and AFAIK, precisely the conversation to be having.

>...in the intervening time anyone has tried to make a font in this way.

No one has come forth. I reckon it would cost between 5 and 15 K dollars to prepare a style for web use, as opposed to 750 to 1000 to do a family if x-hints were not tossed into fairlyland resolution.

Light bulb?

Cheers!

DB> The grid I am talking about, and ’we designers’ are concerned with, is the output grid, not what the scaler dreams.

There are many possible “output grids.” Some are hardware related, some are perceptual related, and I suppose that some could be scaler dreams. The grid we chose, I believe, gives us reasonably fine level perceptual control of the image.
I highly recommend reading a paper by Jim Blinn: What Is a Pixel? This gives a great overview on the basics of computer graphics and the multiple definitions of a pixel.

DB> It makes less no sense to have more or less precision with the rounding than the actual output grid, but please... show me your “fine tuned” ClearType.

Again this depends on your definition of output grid, but I will make the assertion that by rounding to our grid you change both the physical and visual manifestation of the data. If you were to round up or down to the next grid location, it would be visibly detectable. (Granted it might take excellent visual acuity, but that can be the case in high-resolution bi-level rendering as well.)

JH> Better to say that the notion of ‘the grid’ as a singular phenomenon no longer pertains. From the rendering side, I can see how ‘the grid’ might always have been understood to be the scalar grid, which coincidentally was for a long time identical to the output grid.

It is not clear to me that the notion of ‘the grid’ as a singular phenomenon was ever a stable definition. The definition of a pixel is hard enough.

JH> Realistically, Greg, how is a type designer/hinter supposed to target a 3-subpixel output grid via a 16-unit scalar grid, especially since the sampling of that scalar grid is non-uniformly applied to the different subpixel colours, and with subpixel positioning the outlines may fall relative to different subpixel boundaries?

The first generation of ClearType used the non-uniform subpixel color implementation. The current implementation is uniform with two virtual subpixels in the ClearType direction for each real subpixel.

I did not elaborate on this topic in the whitepaper because it was not directly related to the topic of instruction-set compatibility. At the scaler level we apply the sixteen-unit scalar grid. During the scan-conversion process we sample at six units per pixel in the ClearType direction. At first we wondered if this sampling dichotomy would be problematic, but we’ve found no indications of problems related to that decision.

JH> If using compatible, whole-pixel positioning, I can see how delta hints could be applied something like impressionist painting, adjusting until one gets the shape proportions and stroke density one wants — with the caveat that due to gamma and CT tuning this may not be what other users see —, but once one shifts to subpixel positioning, all bets seem to be off.

You are correct, fine tuning the shape works fine in the modes we call “natural width” or “compatible width” ClearType, but with sub-pixel positioning, it is a much greater challenge for fine tuning. This is one of the reasons we provide GETINFO with information to help the hinter make the best conditional implementation necessary.

JH> The hybrid CT/greyscale antialiasing in WPF should have been default in Vista CT. Will it be in Office 7?

Windows Vista contains several different graphics rendering platforms—GDI, GDI+, and WPF. Symmetrically smoothed ClearType is only available on the WPF platform. Vista has no concept of a default rendering platform, it is up to each application to choose the rendering platform. I won’t speculate on what platform(s) the next version of Office (Office 2010) will use.

DB> Microsoft claims here that because some fonts hinted for aliased rendering include exploding points as a result of diagonal instructions gone wild, the (published) cntrlinst option in ClearType needed to address an imaginary output-independent grid gone wild and ignore the x and d instructions.

In the section of the whitepaper on ClearType Interaction with TrueType Instructions I discuss “exploding points” which are typically caused by the PV and FV becoming perpendicular. This is not a ClearType problem per se, as it can happen with any type of hints, but the problem becomes more exasperated when extreme aspect ratios are used. This is why we use super-sampling instead of over-sampling in the ClearType instructions. This issue, though, has nothing to do with the “cntrlinst” [INSTCTRL] issue—it is merely background information.

DB> And as it likel was strictly hinted for widths, its compatible horizontal metrics can only be reached today with Windows anti-aliasing if that font is scaled by TT’s undocumented cntrlinst set to “compatible”.

It’s not clear to me what you are talking about here. If you are referencing the compatible widths mode that I briefly mention in the paper, that is not changeable by the font program, that is set by the application. A different rendering method is used in the compatible width case.

DB> …if these exploding points were in legacy fonts on legacy metrics that should only be scaled by the “Compatible” option, why destroy the 1:1 relationship between the truetype instruction and the output grid in the “Natural” option?

If I understand you correctly, I don’t believe that the “Natural” option you describe would have a 1:1 relationship with the TrueType instruction. The “natural option” (natural widths) would still not use the same “output grid” as bi-level rendering.

DB> Shouldn’t all and any fonts that even bother a wit for SDPVTL, (the incredibly obscure exploding instruction), be treated to “Compatible” scaling in CT, and the other mode just listen to all the instructions?

SDPVTL is not they only instruction that can cause “exploding” points. Any setting of the PV perpendicular to the FV can cause this situation.

JH> Greg, has anyone to your knowledge actually made any fonts that use x-direction deltas in CT?

We have spent a lot of time exploring this area, and we actually make significant use of these instructions to fine tune the appearance of ClearType.

JH>> But sub-pixel rendering, by its nature, addresses something other than whole pixels, which means that the scalar grid isn’t identical to the output grid.
DB> Not precisely. It means that sub-pixel rendering is finer than the hinting’s grid, and the user’s color specification, But assuming there is total instructional control over location of features, sub-pixels can be carefully or wontonly used to represent features better around correct counters and spaces, or make garbage.

I believe that the way I’ve described the ClearType system full allows for “total instructional control over location of features.”

JH> Supersampling to a 16 unit scalar grid enables them to assign more units to the G subpixel than to the R, and least to the B —8, 5 and 3, respectively —, and this reflects average human colour sensitivity: presumably for evolutionary reasons, we are sensitive to more shades of green than to other colours. So the colour filtering is important, and the differential addressing of subpixels — and hence non-linear supersampling — is important.

I want to make sure that my earlier comment is made clear. The scaling and hinting engines use a 16 unit scalar grid. The scan conversion engine uses a 6 unit grid—two for each subpixel.

DB> I want to say here that up until 2004, I was a universally peaceful and caring member of this industry with good relations all around and no reason to criticize anyone’s typographic beliefs, typographic work or typographic origins. Anyone who’s known me before and after 2004, knows this to be true. :)

I’ll concur :-)

Greg >If you wish to make deltas that are specific for ClearType, you need to conditionally apply those deltas using information from the GETINFO instruction.
Svayambhu> It is clear. But how? Can you help me and write the code of function 84 definition that will make this possible?. Or if it is some kind of MS professional secret, why to advise others to use it? Or where it is possible to find more information about this to try to solve this problem myself? I understand the logic of the function GETINFO definition but I have not enough information to modify it correctly.

Function 84 is specific to Visual TrueType and how it implements resolution dependent hinting. My replies are more generically targeted for how to implement resolution dependent hinting in the TrueType instruction set.

I describe the GETINFO ClearType Flag in the paper. The important parts are setting the selector and checking the return value. The selector for the ClearType flag is bit 6 and the return is in bit 13. Example code could look like this:


#PUSH, 64 /* Bit number 6 is set */
GETINFO[]
#PUSH, 8192 /* Bit number 13 is set */
IF[]
….
Do ClearType specific hints
…
EIF[] /* You could add an ELSE[] for non-ClearType instructions */


Now, since ClearType is not available on all releases of the TrueType rasterizer, it is best to also add conditional code that verifies you are using a version of TrueType that supports ClearType. Rasterizer versions 36 and greater (but not larger than 64) is OK. Usually this extra overhead is best handled as a function.

Greg: Windows Vista contains several different graphics rendering platforms—GDI, GDI+, and WPF. Symmetrically smoothed ClearType is only available on the WPF platform. Vista has no concept of a default rendering platform, it is up to each application to choose the rendering platform. I won’t speculate on what platform(s) the next version of Office (Office 2010) will use.

Okay, let me rephrase my original statement:

No graphics rendering platform in Windows Vista should have shipped without symetrically smoothed ClearType, and no graphics rendering platform in Windows 7 should.

Seriously, without the y-direction antialiasing, CT is severely hampered and is getting a bad name for itself, a worse name than I think it deserves.

Is there something that actually prevents the GDI engines from being updated to support the y-direction antialiasing?

Greg: The first generation of ClearType used the non-uniform subpixel color implementation. The current implementation is uniform with two virtual subpixels in the ClearType direction for each real subpixel.

I did not elaborate on this topic in the whitepaper because it was not directly related to the topic of instruction-set compatibility. At the scaler level we apply the sixteen-unit scalar grid. During the scan-conversion process we sample at six units per pixel in the ClearType direction.

That brings your grid back to something resembling what David and I would recognise as an output grid, certainly to something to which it would be easier to hint than a 16 unit non-linear grid.

Greg: I believe that the way I’ve described the ClearType system full allows for “total instructional control over location of features.”

But in a subpixel positioning environment, location of features is understood relative to subpixel distances independent of whole pixel distances, right? So location of features no longer implies appearance of features, since the subpixel distances may be relative to either red, green or blue subpixels (ignoring for now other kinds of screens) and the colour of the particular subpixels will affect the appearance, and this is why, as you say, subpixel positioning ‘is a much greater challenge for fine tuning’. Is that a correct analysis?

Greg,

Am I correct in my recollection that Windows 7 adds "DirectWrite" as well as a rendering environment option? And that it supports ClearType, including CFF ClearType rendering?

Regards,

T

JH> But in a subpixel positioning environment, location of features is understood relative to subpixel distances independent of whole pixel distances, right? So location of features no longer implies appearance of features, since the subpixel distances may be relative to either red, green or blue subpixels (ignoring for now other kinds of screens) and the colour of the particular subpixels will affect the appearance, and this is why, as you say, subpixel positioning ‘is a much greater challenge for fine tuning’. Is that a correct analysis?

Correct

JH> Is there something that actually prevents the GDI engines from being updated to support the y-direction antialiasing?

Technically, no, but there are complexities involved with this work. I think a better solution is for GDI based applications to leverage some of the Direct Write capabilities going forward.

TP> Am I correct in my recollection that Windows 7 adds “DirectWrite” as well as a rendering environment option? And that it supports ClearType, including CFF ClearType rendering?

Correct.

gregh>
#PUSH, 64 /* Bit number 6 is set */
GETINFO[]
#PUSH, 8192 /* Bit number 13 is set */
IF[]
….
Do ClearType specific hints
…
EIF[] /* You could add an ELSE[] for non-ClearType instructions */

Greg, thanks for illustration code. Can it be used in glyph program or only in font program as function definition?
I'm trying to modify in VTT in this way function 84 definition, but I don't know how to change values #PUSH,2,0 and #PUSH,2,1 which work for Greyscale. When I'm trying to use it in glyph program and "add CT specific hints" (CALL[], 18, -64, 13, 2, 77 for example) I have error message - "end of line expected". I understand that the reason is only my ignorance in TTF hinting language. So the last my hope was INSTCTRL 4,3 - to use ordinary deltas for CT and change all previously done deltas to black-only deltas. But I was surprised again - after adding INSTCTRL 4,3 Black-only deltas begin to work in CT also. So, it is sad to recognize, but such an ordinary visual hinter as I cannot do anything to correct any problems of CT rasterization.

When I see CT anti-aliased appearance of my font in VTT - for me it looks good with hints or without hints. It would be nice to have at least an option of this rasterization in Windows CT tuner.

Thanks for all that input, it was really helpful. This apparent change of topic does not mean I'm giving up on getting the compatible option of ClearType documented. I just found a more fundamental issue to address.

GregH> The grid we chose, I believe, gives us reasonably fine level perceptual control of the image.

I'm sure it does, when imaging. But, "imaging" theories and theorists are making a fundamental error — assuming that there is only the imaging pixel down to the base of the resolution spectrum. Cleartype's one documented option of scaling is a perfectly clear example of this, where the imaging pixel takes over the grid from the typographic pixel and the typographic theories on scaling and rendering. That is not working reasonably fine for everyone, has not from the beginning, and now more fonts are needed, in abundance.

Geeze... Just because imaging works most of the time, does not mean it works all of the time. And where it doesn't work, is down here where all the pixels matter. Then, a harmony of grids' needs to be established where the imaging grid is taking orders from the typographic grid, not the other way around. Proof of this need (in Microsoft's own practice), is found in diversity: the y axis of ClearType seems to work fine in typographic pixels, not imaging pixels, and the writer of the "What's a Pixel?" most likely wrote that paper on an OS which had a perfectly good grasp of typographic pixels in both dimensions, (assuming, like most older engineering-backgrounded users, he wrote his white paper on XP with smoothing turned off in a monospaced font?).

We would like an unconstrained option to address your users with what you might consider extra-reasonable levels of perceptual control of the type, but they do not.

Cheers!

David: This apparent change of topic does not mean I’m giving up on getting the compatible option of ClearType documented.

Greg, as I understand it, full-pixel/sub-pixel positioning is an application level decision via graphics APIs. Is there any way for a font to declare itself designed specifically for full-pixel positioning, and to force/recommend use of such spacing?

John, the grid is gone and we have to apply for export/import licenses to send our fonts to China where Latin quality can be economically achieved at our new Delta Wing facility on the Wong Wai River.

Cheers!

I understand that Delta Burke is looking for some work, after all, she was a designing women :-)

ChrisL

> ... she was a designing women

Ya! But someone's put the sacred cow ahead of Descartes, which may be a good idea going up-resolution spectrum, but not going down-resolution spectrum. So it don't matter if you're a designing woman, man, or 'other.' ;-)

Cheers!

LOL! Delta was starting to look rather cow-like there towards the end of that show but her producers could still say "she could think, therefore she was ham" :-)
Regarding low rez, hyperbolic doubt certainly comes into play there when the pixel data is so minimal. René's coordinates are too few and far between to see.

ChrisL

I thought I'd show an example image of fine tuning with ClearType on. The base image is 16 contours, each encapsulating one pixel with one pixel separation between them. The top pixel contour is unchanged by TrueType instructions, but for each lower pixel contour, the left edge of the contour was shifted to the right by four pixel units. The top pixel contour is 64/64ths of a pixel wide, while the bottom pixel contour is 4/64ths of a pixel wide.
I used the SHPIX instruction for the shifting.

Thanks, Greg. That's kinda cool.

I wonder, can you show a run of repetitions of this glyph in both whole- and subpixel positioning environments, at a ppem in which the subpixel positioning results in variant representation? I'd like to get a sense of how this kind of hinting interacts with subpixel positioning.

The instruction being demonstrated is not, or I should say, was not, used in any of the fonts hinted by me, ever, because it is pixel-based, because it is closer to a delta or exception hint, and because it only uses the freedom vector and not the projection vector, meaning, literally it is not moving relative to anything. I.E. this is not one of the hints we use to make "fonts" that work at small sizes in anti-aliased environs.

It's not going to help a font through the current assault and battery of screwy sizing, scary scaling and red-faced rendering we, (or some of us) now face. It's like being up to you neck in gators, and someone tickles your foot and says, "Does that help?" (It does: they have not eaten my foot yet).

One correction that may help the reader here, is "the left edge of the contour was shifted to the right by four pixel units", should read, I believe, "the left edge of the contour was shifted to the right by 4/64ths of a pixel.

And then, there is the interesting question of why any baby yellow or baby blue is showing up at all as those pixels are entirely not within by the contour being rendered.

Cheers!