Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Adam Twardoch

About

Username
Adam Twardoch
Joined
Visits
839
Last Active
Roles
Member
Points
635
Posts
385
  • Re: Hinting and OS X

    AFAIK, it used to be so that after gridfitting, a monochrome bitmap was always produced, and then filtering/antialiasing happened. But today, this isn't always the case because type rendering often happens in the same pipeline as other vector assets using a variety of "vector backends" like OpenGL, Vulkan, Quartz, Metal, whatever.

    So in some environments, font-specific processes stop at the "supersampled gridfitting" stage, so a font rendering module such as FreeType is used only up to the stage of getting gridfitted vectors, and then those gridfitted vectors are passed into the compositing engine which them does it's own thing dealing with the entire composition of type and graphics. Antialiasing and filtering happens there ultimately, but it's no longer font-specific.

    But there are other solutions where it is indeed a "font rasterizer" such as ClearType or FreeType that produces the final antialiased bitmaps. 

    And some environments do a combination: if the text is small size and perfectly horizontal, they use the font rasterizer fully, all the way to getting the final bitmaps, but if the text is large or rotated (e.g. on maps), they only get the vectors, sometimes even not gridfitted to any specific ppm. 
  • Re: Hinting and OS X

    There are two fundamental steps to screen type rendering:

    1. Gridfitting. 
    2. Rasterization. 

    In the first step, the glyph outline is modified (distorted). PostScript hints and TrueType instructions influence that distortion. Simply speaking, various distances between points that are similar in the original outline are actually equalized. Sometimes this means collapsing them to zero (so slightly convex or concave curves are transformed into straight lines), sometimes it's moving points so that all points along a stem or serif are aligned and the distances between points that are located at the opposite sides of a stem or serif are made equal across all glyphs. 

    20 years ago, gridfitting was done at real pixel-per-em sizes, so if type were to be rendered at 16 pixels per em, the contour points were all moved to sit exactly at the coarse grid of 16 "squares" per UPM size. And TrueType instructions would tell the renderer precisely: at 16 ppm, move this point here and that point there. 

    But now gridfitting is done differently. Whether it's Microsoft, Apple or Adobe, hints and instructions are used to gridfit the outline onto a much finer grid — often with differrent resolutions in X and Y. So if the font is rendered at 16 ppm, the gridfitting may be performed at a grid that is made of non-square rectangles of which there are 48 in the vertical and 224 in the horizontal. So the distortion still happens, but to a much smaller degree, because not the "16 ppm" instructions are executed but instead "48 ppm" instructions or "224 ppm" instructions. 

    Simply speaking, the font thinks it's being rendered in much larger size than it actually is, so the alignments and equalizations aren't as aggressive. 

    And then, once the renderer gets the gridfitted outline, it rasterizes it, i.e. projects the gridfitted outline onto a pixel map that is actually really the rectangle made of pixels that will be shown (so it may really be 16 ppm), but it uses complex antialiasing routines that colorize or grayscale the pixels differently if those pixels are near the gridfitted contour. Only pixels fully inside get the full color.

    Or sometimes, they actually produce a rasterized monochrome bitmap at something like 48 or 224 ppm, and then use bitmap downsampling techniques with different sharpening and antialiasing filters (similar to how bitmap downsizing works in Photoshop). 

    The OS and app makers have been constantly refining both the gridfitting and the rasterization steps in their own renderers. 

    So the question is never "does it use hinting" but "how does it use hinting". Most modern apps and OSes still use hinting but differently than they used to.

    The biggest difference is, in fact, in the gridfitting — the gridfitted outlines are being distorted to a much lesser degree than they used to. But also, more sophisticated ways to antialias the resulting bitmaps are being used.

    In the early days, the antialiasing techniques that were used on fonts were specific to fonts. Today, they often use the same techniques as they use with normal vectors — but they still do gridfit *a bit*, which is why you can see the difference between hinted TT or PS glyphs and, say, SVG outlines. 
  • Re: Naming the Widest Width

    To make quick recognition of styles easier, you could use "extra" for weight only (ExtraLight, ExtraBold) and for width, use "ultra" (UltraWide). Or the other way around. 
  • Re: FontLab VI now shipping

    Is there a way to get the updates without having to download a whole new install? Like an update button that does it on the side and allows you to relaunch the app for the new updates to take effect?
    This is something that is on our list, as we realize the current system is not ideal. Unfortunately, there are still no easily available cross-platform solutions for this (a bit surprising in 2017), but we're moderately optimistic. 
  • Re: I trained a neural network to kern a font (mostly)

    Presumably a layout system would only apply these autokerns at the interfont moments...


    In a directionally agnostic manner, across run boundaries.  :#

    Yes! For example between Latin and Greek letters, where kerning is possible using Type 1, TrueType or AAT but isn't possible using OpenType. I.e. generally to fix 20-years-old misguidances and design flaws in next-generation layout systems.