Howdy, Stranger!

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

Kent Lew

About

Username
Kent Lew
Joined
Visits
1,788
Last Active
Roles
Member, Type Person
Points
511
Invited by
Admin James Puckett
Posts
488
  • Re: Slashed zero with downstroke?

    Didn’t the representation of our modern concept of zero as numeral/figure basically start out as a contrastless symbol from the beginning?

    I would think the relevant question is when in history did contrast get added to harmonize it with the rest of the written/typographic figures?

    (Which then necessitated strategies for differentiation from Oo in certain contexts.)
  • Re: OpenType labels in software

    Also, if you look at the source files for Adobe Source Sans Pro, in the family.fea file you can see this in practice. Which is where I basically cribbed together this example for you from:
    feature ss01 { # Stylistic Set 1
    featureNames {
    name "Art Deco Alternates"; # Windows English
    name 1 0 0 "Art Deco Alternates"; # Mac English
    };
    # The feature rules then follow
    } ss01;
  • Re: Merchant of Alphabets

    Most large publishers have a specific department to deal with copyrights and permissions. Don’t know what kind of response you’ll get about an older book like this, but it seems like the place to start.

    Looks like this is now handled by the current parent of Knopf (arrived at via knopfdoubleday.com/contact-us/): https://permissions.penguinrandomhouse.com/
  • Re: Replace ß by smallcap eszett or smallcap ss?

    Seems to me the whole reason this is an issue is because the small-cap mechanism in the OpenType Layout framework was conceived to operate outside of any text-level casing mechanisms, and so the type designer or font engineer is left with the task of deciding these casing rules, one way or another.

    This is why we have to worry about idiosyncrasies like Turkish dotted i and eszett in our {smcp} features.

    And that makes these small-cap casing choices font-specific, which is a bad place for them (as John has argued).

    If only a font had just the responsibility for mapping encoded uppercase forms to their corresponding small-cap variant, and any lowercase-uppercase case mapping were left to the text-processing engine to handle — according to localization or user-specifiable standards or whatever — then fluid situations like the eszett could be addressed in a much more responsive way.

    A {smcp} lookup is really a bad projectile for trying to hit a moving target like this, unfortunately.
  • Re: MS Word — non-responding ligatures switch

    That enumeration is not a canonical ordering; that is just a list of different numbered lookup types.

    If you crack a compiled font into FontLab, then generally it will list the {kern} feature first in its OpenType panel, since the GPOS table is compiled ahead of the GSUB in the font. Similarly, you will usually find it placing {cpsp} near the head of that list, since typically that feature involves GPOS rules.

    It will then list the features from the GSUB table in an order that corresponds to the  registration of the lookups as they are ordered in the LookupList.

    So, for example, if GSUB Lookup 0 is registered to {locl}, then {locl} will be listed first among the GSUB features. If Lookup 1 is registered to {sups}, then it will list {sups} next. And so on.

    This is a fair representation of the original feature order from the source, depending upon how that source was written and how straightforward it was. There are plenty of legitimate tricks in feature writing that FLS cannot represent. In which case, all bets are off for the cracked font.

    But now, I’m afraid we’ve derailed this thread away from Adam’s original problem. Which I have no ideas about, sorry.