Shown above is one of the plausible mappings from foreground, alpha to corrected alpha with average error generated by the mapping indicated by color.
Alpha correction as defined here is not necessarily the same technology as mentioned in Microsoft DirectWrite, but it undoubtedly shares similar principles with it. The technology is motivated by the fact that in many cases graphics programs ignore the nonlinearity of the popular sRGB color space when compositing glyph images, and this results in excess darkening and often color-fringing of LCD filtered text, because of how the mathematics of blending work out. See the LCD page for further writeup about this.
If we have an sRGB foreground color, and an sRGB background color, and a component-alpha mask (= alpha per component), it is possible to generate any color between the two colors just by adjusting the ca-mask for each component appropriately. Therefore it follows that it must be possible to generate the gamma-corrected result of an sRGB-aware OVER operator just by changing the alpha values appropriately and using a linearly blending OVER operator instead.
Using the LCD page's example, the correct RGB value for 50 % blend of white and black is 188 rather than 128. So if we have white text on black background, the alpha value must be set to 188 to raise a background component from 0 to 188 during blending. However, in the reverse color case, the alpha must be much smaller because the distance from background component of 255 to 188 is only 67. From this, we can observe that the alpha value depends on both of the components.
It's also often the case that the background color is not known in advance. This could happen when the text is prepared in advance as an ARGB texture in memory, and will be dumped somewhere on screen later. As an example, this could be the case for a transparent HUD over game world, or text image that may be layered over a default or pressed button background, or text that becomes painted with selection color in a text editor, and so on. If we don't know what the background color is, is the problem still solvable?
The problem of picking a good alpha value to replace the old alpha can be approached numerically. It is sufficient to define an error function and find the best possible alpha value value which minimizes the value of the error function when tested against every background value for that (foreground, alpha) pair.
I've tried various error functions, and in general I think that the following properties lead to best approximations:
I have a C routine that computes 64k elements for the table in about 0.5 seconds on a modern CPU core.
Alpha correction is totally feasible today. You can try it in a demo version, or implement it yourself.
A few screenshots of alpha correction in action: hinted text slightly hinted text unhinted text.
I am developing a library called liblcdglyph which serves as a reference implementation.