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: Specific diacritic designs depending on language

    Of course there are also circular fashions (think hipsters) and political climate. For example today in countries such as Poland, Hungary but also many others, there is a right-wing trend and intense talk of national heritage and so on.

    In a climate like this, typographic forms that are historicizing, that are "specifically adapted for the unique flavor of a certain language", that emphasize distinctness of a given local culture rather than convergence within a broader context, become more sought after.

    This may be unfortunate if a type designer realizes that her/his noble goals of catering for local quirkiness which stems from love and respect for typographic detail or from exploratory curiosity ultimately ends up as a tool for nationalistic and populist tendencies — but it's fact. Designers of digital revivals of blackletter types will know what I'm talking about. 
  • Re: Specific diacritic designs depending on language

    There are two kinds of variant letters. Some language- or locale-dependent forms are suitable for general use in that given locale, but there are also "idiographic" or "idiolectic" cases, where a form is adapted to match a particular local preference, but the users in that locale don't perceive that localized form as "neutral within their locale" but as one that possesses a strong local flavor of some kind. 

    For example, any roman typeface may have German umlauts that are built from base AEU or aeu letters while the accent is a small superscripted e. Contemporary Germans would recognize such umlaut vowels as such, but they would perceive those forms as historicizing, not as neutral. 

    Ever since the advent of digital type in the 1990s, we have a tend for visual convergence and globalization of Latin type. There are many readers now who were born in the 1990s and who were never exposed to pre-digital typesetting results. Their schoolbooks, the newspaper and books they read, websites and mobile phones they grew up with since they were children — they were all set using digital fonts. 

    Lots of those digital fonts were early digital fonts that did not have any localized forms. And for the younger readers, they were the ONLY ones they grew up with, so they're necessarily "right". 

    So when we introduce strongly-flavored localized forms, older readers may prove them as "finally they got it right", bit younger readers may see them as actually more odd than the globalized forms, or at best historicizing and old-fashioned. 
  • Re: FontLab Studio and High Sierra

    Microsoft has a much better record than Apple in catering for users and developers of software in professional markets, including custom-developed software or software that costs several times more than the hardware it runs on. 

    I have both native and virtualized Windows environments and they allow me to easily run apps from the last three decades, including apps from defunct vendors.

    Type design and font development tools are a good example here: I occasionally use pieces of old but still useful software on old Windows, all working fine. On the Mac, I cannot say it's possible. 

    macOS is a fine OS to work on in terms of UI and graphics, but when it comes to stability for developers, it's terrible.

    Every few years Apple changes all of its toolchain, removes things that were previously working fine and forces thousands of developers to rewrite large portions of software from scratch. 

    This does have the "nice" side-effect that developers may charge users upgrade prices because the older versions of their apps stop working on newer macOS, so users come running. On the other hand, on Windows, apps may run forever so users may not be "pressured" into upgrading so easily. 

    The additional problem with Apple is that they tend to be very secretive, so as a  developer, getting detailed information about why something is not working isn't easy. Microsoft always has been more relaxed and cooperative with software vendors. 

    As for exit strategies — I might agree that using cross-platform apps which you can run on more than one OS is indeed a decent contingency plan. Using software that is heavily tied into just one software (and hardware) platform always poses a certain risk.  
  • Re: Opentype features from variable axes?

    My test font:

    shows how a font axis can be used to gradually trigger different lookups depending on the axis value. 

    Here, it’s done in the "rvrn" feature, but it’s possible to do with any feature. This means: depending on the user-selected axis location, it’s possible to have different GSUB and GPOS realizations for any given feature. 

    For example, you might have a "LIGA" axis that controls in detail how many ligatures are enabled when the "liga" feature is active. The axis may also perform some contour modification, but that’s not required.

    But there is a big caveat: in the current VF model, each selected variable instance constitutes a new font. This means, the glyph run breaks and no features can interact across the change of the instance. The fvar axes are above features, not on the same level.

    It's not difficult to imagine typesetting a series of glyphs and applying a different axis location to each one. But variations don't apply just to glyphs but also to positioning, and different lookups can be triggered depending on the axis location. 

    If different axis locations can trigger different GSUB and GPOS lookups, and any of the lookups could change the axis locations, then quite possibly, the new axis locations would deactivate the lookups that triggered them. 

    Or what if a lookup is executed when an axis it at position 300 and the rule says "move the axis location to 200", but then the same lookup at axis location 200 would have a rule "move the axis location to 100"?

    Also, OpenType GPOS works so that it can change the x/y position of the glyph origin and the x/y position of the glyph advance width point.

    Asking for GSUB to allow mixing instances would mean e.g. if we’re at axis location 300 and if glyph "a" is followed by "b", then move the axis location of glyph "b" to 200. 

    But let’s say we have a string "abc" and there is GPOS adjustment between "b" and "c" that at axis location 300 changes the origin point and the advance width of "b" somehow, and also changes the origin point and the advance width of "c" somehow — to allow kerning, but also more complex positioning.

    Now, when, after GSUB, "b" is at axis location 200 and "c" is at axis location 300, then neiter the GPOS rules for 300 nor those for 200 apply completely. Some things would need to be interpolated — but what? The origin of "b"? The advance width of "b"? The origin of "c"? The advance width of "c"? Both x and y, or only one?

    One more example: if after some GSUB processing we end up with "abc" where "a" and "c" are at axis location 300 but "b" is at axis location 200, and we have some more lookups to process — and those lookups define different behaviors when axis locations are <250 and different if >250, and there are contextual substitutions (let's say "c" is substituted by "d" if preceded by "a" and "b" but only if axis location is >250) — what exactly should happen? Is "b" in-context or out-of-context?

    Oh, or maybe we then should define additional contextual GSUB lookup types which allow for matching contexts not just for which glyphs they are, but also for what axis locations (and then, logically, what x and y distances) they have.

    That would in principally be wonderful — if we could define not just glyph ID-based contexts but also axis location-based and x/y-position-based contexts. But it would be hard. :)

    There are many caveats associated with bidirectional axis-feature interaction. So for now, the interaction is only one way: features can detect at which axis location the font is and apply different lookups depending on that. But it doesn’t go back.

    There’s been some conversation about possibly adding a mechanism that would allow more axis-feature interaction, see:

    But it’s nowhere near drafted. I think for the time being, OpenType Font Variations will remain “font-level variations”. Introducing inter-glyph-level variations is conceptually much more complicated.

    I think many people would agree that in general, something like this is a good idea. But figuring out how to make this work reasonably, writing the spec and implementing it will take time. Positioning is particularly tricky because there is no obvious way to tell what "working reasonably" would mean here. 

    Variable fonts may have intermediate masters where positioning is very "odd". 

    Let's say some glyphs are narrow and tight in the axis location 0, then they become wide and loose in axis location 500 and then they  become narrow and tight (but in a completely different way) in axis location 1000.

    If I put one glyph at location 0 next to another glyph at location 1000, then the kerning between them might come from location 500. 

    But kerning at location 500 was only designed to work for glyphs at location 500, not between ones glyph from 0 and one from 1000. 

    This is a hypothetical example but it shows real consideration. 

    Positioning of glyphs that come from different locations may need to be different than the positioning that happens in the locations between them. 

    Two Germans will speak German to each other. Two Spanish people will speak Spanish. And two French people will speak French. 

    France lies between Germany and Spain — but this doesn't mean that the best language in which a German can communicate with a Spanish person is French. 

    In fact it's not at all clear what the best language should be. I hope my analogy makes sense :) 

    An even better example is with colors. You may dress in all things green, all things blue or all things red. But if you put on a green t-shirt and red shoes, it does not automatically mean that your trousers should be blue, even though blue is between red and green on the color spectrum. 

    Software developers must know exactly how a system will work and must implement it exactly. There is very little room for "maybies". 

    Implementing a system that will deliver sensible results between different instances of a variable font is difficult, because it's not at all obvious which results would be sensible. 

  • Re: Opentype features from variable axes?

    It's currently not possible. Also: selecting a different instance constitutes a font change, so kerning between variable small caps and the unmodified glyphs wouldn't work. The variable font model could be extended to allow feature interaction between different v instances, but it would be quite complicated.