Howdy, Stranger!

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

Kent Lew


Kent Lew
Last Active
Member, Type Person
Invited by
Admin James Puckett
  • Re: Units per em

    I think most webfonts would work perfectly well for screen with a low UPM like 256.
    I think most (if not all) of Font Bureau’s RE fonts are on 512 upem, using similar reasoning. I believe that this approach grew out of David Berlow’s experience creating the Prelude fonts for Palm. He figured in that case that even a single glyph enlarged to the full size of the device would hardly reach a pixel resolution that benefited from more unit resolution (or file size).
  • Re: Naming font modifications

    the best solution is to ask the client, and let them decide. For me, it would be a nightmare if I had to change the font in any of the old documents that I opened because the font's name had changed.
    When working with clients on this sort of modification or customization, I always recommend a custom or modified name. And along with that, I offer to provide them with a script that will automate changes in legacy documents (assuming they are working in InDesign, which they almost always are).

    Several years ago, when Font Bureau made a major update to the Benton Sans family, there was a lot of debate about the pros and cons of having the family name change slightly (from “BentonSans” to “Benton Sans”).

    All of the familiar arguments arose — including preventing the possibility of documents that depend upon features in the new full-featured OT fonts from opening with older fonts installed and without warning of the mismatch (an argument for name change) versus causing confusion and hassle in updating existing documents (an argument for keeping the same family name).

    The decision was made to update the family name.

    As you can imagine, updating specimen documents that had contained around 128 fonts (prior to merger of SC styles) to roughly 80 fully-featured OT fonts was a daunting prospect. The Adobe Find Font… interface is very cumbersome at that scale. Which is when I developed my InDesign script.

    I then suggested to sales & customer support staff to make the offer to clients that we could provide them the script to update legacy InDesign documents, as a courtesy. I don’t know if anyone ever took advantage of the offer.
  • Re: Special dash things: softhyphen, horizontalbar

    Scribus actually just draws some predefined shapes for the few “invisible” characters it supports.

    InDesign also has its own predefined symbols for displaying invisible characters when Show Hidden Characters is activated, independent of what might be encoded in the font.

    FWIW, TextWrangler does appear to actually display the encoded outline for discretionary hyphen U+00AD. So, in Nick’s example above, pasting such a text into TextWrangler makes the discretionary hyphen point visible. As far as I can tell, if one is not encoded, it will use a fallback font. (Not a good reason to draw one, I’m just reporting . . . )

    But this is a text-processing and coding app, not a layout app. Most people don’t go around applying different fonts in TextWrangler. ;-)

  • Re: Special dash things: softhyphen, horizontalbar

    Nina — As I said, I only double-encode U+00AD in case there is a validation tool that needs the codepoint in order to permit indication of certain codepage coverages. I suspect, as John does, that it doesn’t actually matter what’s in the font or not.
  • Re: 656565656

    I've checked some fonts, and haven't found one that compensates for differences in the curvature radius by playing with the height.
    FWIW, I have on occasion placed the overshoot of an eight or a zero differently than the general overshoot value, if I felt they looked smaller (in the case of eight sometimes) or larger (in the case of lining zero sometimes).

    I’m not saying that I was right to do so, or that one should (or shouldn’t). Just that it isn’t completely unprecedented. ;-)