This may come across as Typography 101 for most of you, so I apologize in advance if this is the case.
Up until recently, I've been using CCP (Chained Context Positioning) rules to match the level of one glyph to another in order to (in this case) vertically align bottom lines. I did this in an attempt to save on having too many glyphs in my font.
As you can see from the image above, it's seemingly not properly aligned when using CCP rules. Thing is, the font rules and SingleAdj's are mathematically correct and, indeed, it does print properly. However, on screen, it will only display correctly at certain resolutions (dependant on your system, I'm assuming).
The solution (as shown above) appears to require a glyph with the bottom line designed at the correct height from the start (thus, negating the need for vertically adjusted CCP rules).
Question: Is the former CCP visual artifact the norm? i.e. Is it an issue with the computer graphic's card, the application's inability to properly display the font as designed, an OpenType limitation...or simply the way fonts work?
I know a fair bit about vertical positioning in fonts, but that phrase is unfamiliar to me.
I think this architecture choice is an artifact of the rasterisation methods in use when OpenType Layout was invented. Today, it seems obvious that it might be better to position first and then rasterise, because our rasterisation methods now tend to antialias in all directions and target higher resolutions. In the mid-1990s, rasterisation was heavily impacted by hinting, so rasterising on the 0,0 grid and then positioning the bitmap seemed to make more sense.
* Like a couple of other things OT, a clever idea here, a clever idea there, but lacking a overall conception.
OTL landed around the same time that Microsoft was already working on what became ClearType rendering, i.e. x-direction subpixel rasterisation, which initially shipped with y-direction aliasing. So even though they had already done full greyscale antialisaing, full-pixel grid rounding—at least in one direction—was still Microsoft’s default target environment for type rasterisation. [It was several years later that @Beat Stamm implemented combined x-direction subpixel and y-direction greyscale antialiasing.]
The other presumed benefit, at the time, to the rasterise first, positiong second approach was that the bitmaps could be rasterised and then moved about without regard to vertical metrics clipping zones. In the situation of the time, with GDI-based environments using OS/2 Win– metrics for both linespacing and clipping, that was an attractive concept for writing systems with tall or deep stacks of positioned elements. In fact, this only sometimes worked, and even in the same UI element it might work in some place but not in others: