Howdy, Stranger!

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

Peter Constable

About

Username
Peter Constable
Joined
Visits
352
Last Active
Roles
Member
Points
99
Posts
95
  • Re: [OTVar] hidden axis flag

    What I'm concerned about is that I know in the future there will be a desire for some differentiated treatment of variation axes in user interfaces. As soon as we create new APIs exposing variation axes, there will be font-picker/text-formatting user interfaces created that expose axes. But if we don't have anything in APIs from early on to clue developers in that some differentiation of axes may be needed, then we'll face cases in UIs are created to support 'that cool new font-variations thing' and then the developers will move on and not want to revisit the area for a long time. So, what I'm most concerned about is educating developers early on to pay attention to this space that's still evolving and that may require UIs to evolve with it.
  • Re: [OTVar] hidden axis flag

    Re more detailed metadata, I think it's way to early to be guessing at what the best future UI affordances for axes may be.

    As John indicates, there is always some assumption to be made when no flags are set. If we don't explicitly say what should be assumed, then different apps will do different things. Also, note that fonts are starting to get created that don't have any flags set, and so the no-flags interpretation should keep those fonts in mind. Do we treat that as the "never show" case, or the "only advanced" (by some determination) case? I think the safest thing is to treat that as "always ok to show" on the grounds that users are less likely to be confused by a variable font that has multiple knobs/sliders than by buying a variable font advertised as supporting axes but then they can never see them in apps.
  • Re: Oblique and Italic in same family

    For certain reasons, and after some discussion, we (MS, Adobe, Apple, Google and others) ended up deciding to make slant and italic separate sub-family-variant axes in the extended-family model that OpenType Font Variations forces. So, platforms that support the full richness of OT 1.8 shouldn't have a problem with a family that has both Italic and Oblique variants -- or even an Oblique Italic variant.

    That said, Tom's warning is probably appropriate: it would likely create problems in some existing software.
  • Re: Web Font Security

    ...
    I have came across some sites that have very good protection preventing a user ripping a webfont. 

    Site examples:
    http://www.filipmatejicek.info/
    That site is embedding WOFF data directly within the @font-face rule definition, using base64 encoding --- which will expand the size of the data probably by a factor of 4.
  • Re: Which OpenType feature could I use instead of contextual alternates?

    These aren't swashes.

    It's not clear to me that "contextual" is really relevant either: you're not substituting (say) the default "m" with a different glyph when it's preceded or followed by certain glyph sequences; you're substituting ".m" in all contexts by a different glyph. These are ligature substitutions, but they're not ligatures in the most familiar sense. 

    What about ss01?