Howdy, Stranger!

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

Adam Twardoch


Adam Twardoch
Last Active
  • 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: Hinting and OS X

    just musing, I wonder about the value of the Adobe apps using hinting, when the eventual output is to the Web or print. How much content is consumed in the Apps, InDesign for instance? or is it useful for proofreading? 
    InDesign is widely used to produce e-Books or "interactive PDF"-style magazines, so the final type is often rendered in a browser or a PDF viewer.

    Illustrator and Photoshop are widely used for prototyping and mocking up web or app user interfaces. 

    But also, designers who work in those tools often zoom out a lot (because their monitors are also filled with panels and UI elements of the app). So they often see the type in text columns much smaller than the final output will be (even if it is for print). 
  • 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 Studio and High Sierra

    There is a cross-platform app called Synergy that allowed you to work on multiple computers placed side by side as if it was one.

    When you moved the mouse pointer to the edge of one computer's screen, the pointer appeared on another computer's screen, even if one was a Mac and the other was a Windows PC.

    You could use one computer's keyboard to operate anything of the connected machines and the clipboard was also shared. But each computer displayed the content on its own monitor, so it wasn't a "remote desktop" solution, of which there are many and which all are quite slow. 

    Synergy uses the network only to transmit the mouse movements, keyboard entry and clipboard, so it was very lightweight. The illusion is quite perfect and at the time when I used both a Mac and a PC, I used Synergy for quite some time. 
  • Re: Two more cases against pirates

    In other words: standardization of the language and vocabulary in font EULAs would be welcome.

    The EULAs don't need to provide identical rights and restrictions, but the way they provide the rights and restrictions, the way they define the terms, the way they communicate exceptions — that could be based on a common subset of legal language that is specific for fonts.

    Then, the distributors could safely summarize and compare the terms and make distinctions clear to users. I don't think that would constitute any kind of cartel operation.