Vertical positioning: matching glyphs vs CCP measured alignment

Bernie Cossentino
Bernie Cossentino Posts: 19
edited January 2022 in Technique and Theory
Hello,

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?

Thanks

Comments

  • Thomas Phinney
    Thomas Phinney Posts: 2,897
    What are “CCP rules”?
    I know a fair bit about vertical positioning in fonts, but that phrase is unfamiliar to me.
  • Bernie Cossentino
    Bernie Cossentino Posts: 19
    edited January 2022
    Thomas Phinney said:
    What are “CCP rules”?
    I know a fair bit about vertical positioning in fonts, but that phrase is unfamiliar to me.

    Apologies...it may be specific to Font Creator.
    CCP: Chained Context Positioning. Thus, applied rules for (in the above case) SingleAdjustment lookups.
  • Thomas Phinney
    Thomas Phinney Posts: 2,897
    Ah, thanks for editing that in the original post. Perfectly clear now. Chained contextual positioning, I understand.  :smiley:
  • k.l.
    k.l. Posts: 109
    Looks like glyphs get intelligently rasterized first and smartly positioned second. Wrong order. Your solution seems like the only way to avoid odd effects of it.
  • Bernie Cossentino
    Bernie Cossentino Posts: 19
    k_l said:
    Looks like glyphs get intelligently rasterized first and smartly positioned second. Wrong order. Your solution seems like the only way to avoid odd effects of it.

    Thank you, appreciate your reply.

  • John Hudson
    John Hudson Posts: 3,229
    edited January 2022
    Looks like glyphs get intelligently rasterized first and smartly positioned second. Wrong order.
    But how OT is designed to work (which is why GPOS lookups can have resolution-specific adjustment deltas to bump the bitmaps, although I have only seen them in a font once in 20+ years).

    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.

  • k.l.
    k.l. Posts: 109
    Wrong order. A conceptual fail.* Even then. Indeed resolution-specific adjustment deltas only work in a context of bitmap rendering. Even then, though, it was written on the wall that there would be greyscaling. Warnock wrote about it much earlier. Karow showed me a live demo, I think, summer 1993.

    * Like a couple of other things OT, a clever idea here, a clever idea there, but lacking a overall conception.
  • John Hudson
    John Hudson Posts: 3,229
    I agree with your conclusion, but still reckon the thinking of the time was excusable.

    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:


Categories