> If you look closely at a windows desktop you'll
> see that asking windows to do A-A does *NOT* A-A all or even most text.
> We have no way to express that and in fact at almost all typical
> GUI sizes fonts say "please do NOT AA me". This is in the
> table of a TrueType/OpenType font and almost all fonts say not
> to do so for 7->14 pts which is the size range you'll see in most GUIs.
> So by turning it on on windows in a blanket fashion we'd actually
>be more divergent than we are now!
> Addressing this needs a new hint or other mechanism and additional
> supporting code etc.
Additionally our use of composite fonts makes this a bit tricky:
> We'd probably have to pick the behaviour of just one
> of those fonts, probably slot 0. To do otherwise a
> single string would be drawn with AA and non AA glyphs
> which would not only look weird but be a nightmare for
> our blitting loops.
The customer also added:
> I took a screenshot of my Windows XP desktop with zoomed-in parts of
> various text. I posted it at http://kano.net/in/desktop. When you look
> at the image you will see that there is no text on my desktop nor on any
> of the open program windows, which is not anti-aliased. I did not enable
> anything special to do this.
And Phil comments:
> I looked at the snapshot and it was immediately obvious
> that's because he's enabled ClearType anti-aliasing, not
> standard anti-aliasing.
> ClearType works differently and always
> anti-aliases. If he switches back to "standard" he will see
> the behaviour I described. Its accessed in the same place
> as the standard smoothing user option, its just a different option.
> We have an existing RFE (which you are welcome to look up
> as I don't have the bug ID handy) to implement something similar
> to cleartype.
So, there are two issues here:
1. We need a way to get whether or not we should turn on AA for the font we're using,
this will come from 2d.
2. We need to support clear type.
The 2nd issue is already filed as 4871297 which is waiting on the 2d
As there is already a bug against 2 this bug is then just against 1, which
is already logged as 4502804, closing as such.