Howdy, Stranger!

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

John Hudson


John Hudson
Last Active
Member, Type Person
  • Re: Efficiency in kerning pairs

    Most kerning in Latin fonts involves diagonal or overhanging shapes., i.e. the shapes that are exceptional to the straight-straight, round-round, and straight-round relationships that determine the default spacing.

    The only times you should ever find yourself kerning a straight to a round is an uppercase straight being followed by a lowercase round, which in some designs might benefit from being slightly tightened.

    When I'm kerning, I look at everything, including straight-straight, etc. in context of words, because its a process that I find useful to confirm default spacing. But when I examine the results in the kerning, I typically see the same set of kern pairs involving diagonals and overhang shapes.

    How many "kern pairs" did some of the most famous letterpress types have? 

    None. And diagonal and overhang shapes produced big gaps within words. We can do better.
  • Re: [OTVar] Axes Proposals:

    [A bit meta:

    We have no formal process in place for registering new axes in the new OT Design-Variation Axis Tag Registry. I am wondering whether it would make sense to come up with at least a protocol for how new axes are registered?

    I am considering the OpenType Layout feature registry, which is a mess, and how we can avoid a similar situation with OTVar, i.e. features/axes that end up not supported anywhere. features/axes that end up implemented in ways that are not reflected in the registry definitions, features/axes that are redundant and whose function is better handled via other features/axes (whether existing or new).

    Something like the W3C publication process seems a good protocol, i.e. new OTVar axes can be proposed, refined by the working group in consultation with the proposers, then published as an official draft, and only formally incorporated into the registry once two independent and compatible implementations exist. As in the CSS or webfont format standardisation process, the draft stage permits and encourages real-world implementation, but it means that the specification doesn't get weighted down over time with things that are not supported, need to be redefined, or maybe even the original proposers have come to regret — as has been the case with several OTL features.]
  • Re: Any app that support OpenType "rand" feature?

    So this is what I get in AD. Feature on, feature off, feature back on.
    To clarify: reversibility is going to depend on how the rand feature is implemented in software. If cycling through the variants and always starting the cycle in the same way, or using pre-seeded pseudo-randomisation, then you will get reversible results, i.e. always the same 'randomisation' of substitutions for the same input text. But if the implementation were to actually generate random numbers to select variants, then you would expect different results every time the feature was applied.
  • Re: Which of these books should I prioritize getting?

    Not often I agree with Hrant, but yes, of the ones you list I would say Letters of Credit first.
  • Re: Pro fonts with Cyrillic support

    I've not closely examined the pre-defined sets in Glyphs, but I presume the following observations are likely to be the case:

    The basic set is probably based on 8-bit Cyrillic codepages that cover all the major Slavic languages using the script: Russian, Ukrainian, Bulgarian, Belarusian, Serbian, Macedonian. That's pretty standard coverage for a lot of Cyrillic fonts, and it makes for a nicely grouped set of languages defined by their linguistic categorisation and geography (all European).

    When he was at Adobe, Tom Phinney defined the extended set as a kind of 'low hanging fruit' selection to target some of the major non-European, non-Slavic languages using the Cyrillic script. It adds to the basic set a smallish subset of the Unicode Cyrillic characters not used for Slavic languages, mostly involving shapes that are fairly easy to derive from the basic shapes, so not constituting too much extra work for a type designer to support.

    My suggestion would be to start with the basic set, which you will need in any case, and once you have revised and refined your design for that set, then take a look at the extended set and see what will be involved in adding those characters.