Looking for some info on MM Fonts and AAT format

Baptiste Guesnon
Baptiste Guesnon Posts: 1
in Type Design Software

Hello,

I’m currently writing my final degree thesis on dynamic typefaces. I'm interesting myself in MM and some things looks really obscure to me.

I read some discussions about the subject (on MMFonts and AAT format) here : http://typedrawers.com/discussion/758/aat-in-decline-who-develops-aat-featuresAnd Here : http://typedrawers.com/discussion/631/selling-opentype-features-as-separate-fonts/p1

It seems that these formats are more or less dying (or already dead). I don’t understand if the MMFont of Adobe is still supported in the Opentype format, or if only works with Type 1. Does someone know about it?

About the AAT, the documentation talk about “gear” table and “Core Text” says it “provides support for multiple master fonts, font variations, font cascading, and font linking” but it seems that nobody ever used it, except Apple, and no program seems to generate this kind of format.
Or maybe am I wrong? Is it possible to build an MMaster AAT with two UFO master, or two TTF for example?
And, if it is possible, is there a way to use it? Or should I build an app from myself with Cocoa and Core text to do it?

Same question for MMFont. I know I can easily generate these from Fontlab, but I couldn’t find any way to test it, except to emulate an old classic Mac system with Adobe Type Manager on it.

I don’t really understand why MM Fonts (PST1 seems to be dead so AAT) are not more used. The idea of MM has an amazing potential, but for now it failed to rise up each time. The lack of tools to produce and use it seems the major obstacle to me. Maybe someone has some information about it?

Thanks,

Baptiste

Tagged:

Comments

  • James Puckett
    James Puckett Posts: 1,992
    I don’t really understand why MM Fonts (PST1 seems to be dead so AAT) are not more used

    Very few end users need MM fonts. Of those who do only a subset would actually bother to use MM fonts if they existed (just like OpenType features). So no software supports them. And type designers wouldn’t bother making MM fonts because the market is too small to deal with the extra retail, marketing, and support headaches.

    I don’t understand if the MMFont of Adobe is still supported in the Opentype format, or if only works with Type 1.

    MM fonts were a format, not part of other formats.

    Is it possible to build an MMaster AAT with two UFO master, or two TTF for example?

    I don’t think so, but I’m not an AAT specialist. But even if you could there’s no point, because no software supports them anyway.

  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited November 2015
    There are a few apps that support AAT variations, well, one that I know of, anyway: Softpress Freeway, a website design app. It dates back to a word processor from the GX era. I believe also that the Mac font Skia uses variations behind the scenes for its weights and widths. So it seems to be supported at some level, but not exposed normally.
  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    edited November 2015
    Baptiste Guesnon said:

    Hello,

    It seems that these formats are more or less dying (or already dead). I don’t understand if the MMFont of Adobe is still supported in the Opentype format, or if only works with Type 1. Does someone know about it?

    Adobe’s multiple master format was supported in some early versions of OpenType, but that was withdrawn very early on. I don’t think there is much of anything that supports it.
    Baptiste Guesnon said:

    Is it possible to build an MMaster AAT with two UFO master, or two TTF for example?
    And, if it is possible, is there a way to use it? Or should I build an app from myself with Cocoa and Core text to do it?


    Multiple Master specifically refers to the Adobe tech. “Multiple Master AAT” is pretty much a contradiction in terms. I am guessing that what you really want is an AAT Variations font, which is the AAT equivalent of MM. So, currently, the only tools I know that support building such fonts are command-line tools from Apple, that take TrueType inputs. However, you could easily create such from UFO sources, one step upstream. As for testing, I think you'll find that the fonts will work in many Mac apps that use CoreText APIs, including Apple's own Pages, etc.
    Baptiste Guesnon said:

    I don’t really understand why MM Fonts (PST1 seems to be dead so AAT) are not more used. The idea of MM has an amazing potential, but for now it failed to rise up each time. The lack of tools to produce and use it seems the major obstacle to me. Maybe someone has some information about it?


    There most definitely were adequate tools to build MM fonts. FontLab Studio supported MM fonts reasonably well, and most of the commercial fonts available in the world have been produced with FontLab Studio in part or in whole.

    The problems for MM historically were failures of user interest, marketing, and app support for direct axis access. Adobe didn't realize how hard it would be to make MM fly, and didn't take the right steps to make it successful. (This harsh, sad lesson would later serve Adobe well in promoting OpenType.)

     AAT (GX at the time) is a slightly different story, but it did have the tools problem you mention, plus it was originally a Mac-only technology when top apps were all cross-platform, so Adobe, Quark and Microsoft all failed to get behind it.

     Interestingly, axis-based fonts might actually make a comeback. Some of the talk about OpenType 2.0 leans in this direction, and support for the AAT gvar table has been increasing recently (I think we now have it in TTX, HarfBuzz and the Universal Shaping Engine).
  • Khaled Hosny
    Khaled Hosny Posts: 289
    (I think we now have it in TTX, HarfBuzz and the Universal Shaping Engine).

    TTX only, the other two wouldn’t even need to know anything about font variations. FreeType, however, improved its existing (but seldom used) gvar support.

  • Deleted Account
    Deleted Account Posts: 739
    edited November 2015
    i did not realize that shaping and variations don't need to know about each other. How did you decide that?

    ...and you don't have to build your own app if you can navigate to superpolator.com.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    What part of the shaping process needs to know about variations?
  • Adam Twardoch
    Adam Twardoch Posts: 515
    @Khaled Hosny: all of it. :) It starts with the variation of the advance width along pretty much any axis, it is followed by variation of anything that can be expressed in the GPOS table (kerning, mark positioning, and other positioning adjustments), and — if you think about more flexible applications — it would make sense to be able to perform certain glyph substitutions within a sub-range of an axis, for example to implement something like the Superpolator 3 rules ( http://new.superpolator.com/documentation/rules/ ) or the Glyphs bracket layer ( https://www.glyphsapp.com/tutorials/alternating-glyph-shapes ) via the GSUB table. There are even more useful applications that go beyond (for example using variable-width glyphs for justification, including curved kashida glyphs for Arabic). 
  • Khaled Hosny
    Khaled Hosny Posts: 289
    I’m talking in the context of already existing gvar table that Thomas was talking about, what parts of gvar table need HarfBuzz or USE to be aware of it?
  • Thomas Phinney
    Thomas Phinney Posts: 2,883
    Back to Khaled's comment: if your engine treats each instance as a distinct font, then the layout engine does not have to know anything. But this would be inefficient at best, no?
  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    @Thomas Phinney: yes, you're right, and you're making an excellent point here!

    If a variable font is considered merely as a container package for a potentially "infinite" number of "logical fonts" (static "virtual instances"), then nothing really changes (well, a layout engine still needs to be enhanced to simply access the internal font data in a different way, but it could keep using the same API). If a variable font is implemented more fully, then a layout engine would also need to add some APIs, or become more internally aware of the possibility of the mutation occurring (for example, it would have to employ a different method of caching values). 

    Even with the old Type 1 Multiple Master fonts, there were two ways of implementing their support in the OS and apps: 

    • dynamic: The font would be seen as a variable (mutable) font. This was the way that for example Adobe Illustrator 8 or 9 supported MultipleMaster fonts. You got sliders, and the selected instance was an additional parameter, similar to something like an enabled OpenType Layout feature
    • static: The font would be seen as an immutable, static font. This was the way how ATM (Adobe Type Manager) exposed MM fonts to traditional apps. The user would pick an instance and ATM would produce an in-memory "virtual instance" that behaved just like a normal Type 1 font. Traditional apps would access the virtual instance just like any other font and would not be aware of any variation possibilities. This is similar how single fonts are accessed today from within one .ttc file — one .ttc file can host a number of "virtual" fonts, where each such font manifests itself to the system or app APIs as a separatel static font. 

    GX fonts can be implemented in exactly the same two ways. This difference is already conceptually present in CSS. If you look at the CSS Fonts Module Level 3 http://www.w3.org/TR/css3-fonts/ you will see that webfonts can be accessed on two levels. First, there are CSS descriptors that are used inside the @font-face rule. Any such descriptor is applied before the font becomes available to the browser, so if a unicode-range descriptor is used, then only a subset of the fonts' characters becomes available in the browser, and the browser cannot "later" access "more" characters out of that font.

    But once the font is initialized in the @font-face rule, once can use CSS properties such as font-kerning, which can be dynamically enabled or disabled.

    It's worth noting that font-feature-settings is both a descriptor and a property. If used as a descriptor, the specified OpenType Layout features are "applied" "before" the font is initialized and made available to the browser, and if used as a property, the features can be enabled and disabled after the font is initialized, dynamically.

    If one imagines something like CSS font-variation-settings where it's possible to specify some GX variation axis values, if font-variation-settings was implemented as a descriptor, then a virtual immutable instance would be made available to the browser, and the browser would not need to bother about variation support at all. But this also means that there would be no way to dynamically change the weight or width via, say, JavaScript.

    But if font-variation-settings is implemented as a property, then the browser must be ready for "mutation", and JavaScript could be used to dynamically change width or weight.  
  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    @Khaled Hosny: If you implement any kind of variable fonts, your "font selection" mechanism has to change in some way.

    In the static method, you would need an "atm"-style intermediary library that is used before you start doing layout. That "atm" lib takes a font file and either some supplied axis positions or a supplied named instance*, and creates a static virtual font which then can be accessed via the more traditional methods. If the "atm" intermediary lib applies the variation tuples and exposes a completely virtual, dynamically constructed "glyf" table, rewrites the "name" and does all the "conversion" — then the layout engine does not need to do anything smart. 

    In the dynamic method, the selection mechanism is built into the layout library, with some kind of extended API where the user can supply the axis positions or named instance. Then, the layout engine needs to perform     the axis value translation or named-instance selection (as implemented in the "fvar" table), and then it needs to determine the correct advance width of the glyph using a combination of the "glyf" and "gvar" tables. In future, it will also need to process the not-yet-implemented extensions to "GPOS" and possibly other tables. 

    *) The GX model in the "fvar" table used in combination with the "name" table has a mechanism for named instances which to the end-user appear just like traditional separate font styles within a typographic font family. Inside, a "name" table entry is mapped in the "fvar" table to a set of positions on all axes. In GX, there is also a special translation of "external" axis positions to "internal" axis positions. It's used to normalize the external values that are used in the API but allow flexibility inside the font. It may be a bit over the top, but, well, it's there. :) Check out: 
    https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6fvar.html
    https://github.com/behdad/fonttools/blob/master/Lib/fontTools/ttLib/tables/_f_v_a_r.py
    https://github.com/behdad/fonttools/blob/master/Lib/fontTools/ttLib/tables/_f_v_a_r_test.py
  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    Conveniently, in the GX model, the axes use four-letter tags as names. Apple registered "wght" for weight, "wdth" for width, "slnt" for slant, "opsz" for optical size. This is similar to OpenType Layout feature tags, so it's quite possible that external APIs don't need to change at all. Instead, "we" could agree to treat font variations, conceptually, as advanced typographic features.

    Today, the CSS font-feature-settings descriptor and property have this syntax: 
    font-feature-settings: "smcp", "swsh" 2;
    and in general, OpenType Layout permits a feature parameter to be supplied along with a requested OpenType Layout feature tag that needs to be applied. Not many UIs currently support this, but there are fonts where the "swsh" or "salt" feature uses GSUB LookupType 3 (Alternate Substitution), and the above CSS syntax uses the integer 2 to select the 2nd alternate specified in the "swsh" feature. 

    It's easy to imagine that the GX variation selection could happen using the same mechanism, and the CSS could look like: 
    font-feature-settings: "wght" 1.8, "wdth" 0.9, "smcp", "swsh" 2;
    or something like that. In essence, GX axis tags with the requested float values would be treated by apps and layout engines in the same or very similar way as OpenType Layout feature tags with numerical parameters. 

    Additional standardized axis tags could be proposed and registered, and we could ensure that, just like today, the registered GX axis tags and the registered OTL feature tags would not conflict. 

    Or possibly even, one and the same functionality could be implemented via different methods. Already today, some features can be implemented as GSUB or GPOS. It would be possible to extend the fvar table slightly, or have a new table, and then allow implementing certain features such as "smcp" through a combination of GSUB and fvar/gvar (GSUB would substitute lowercase letters with uppercase letters, and then an appropriate variation would be applied to the uppercase glyphs to make them slightly bolder along the "wght" axis, slightly wider along the "wdth" axis, and then reduced. The same could be done for features such as "c2sc", "sups", "sinf", "numr", "dnom" or "subs" — via a selection of a variation from a combination of GX axes plus scaling and positioning via GPOS. 

    The "GPOS" table could be extended with a new LookupType that would permit simple scaling along the x and y axes. It would be potentially useful just by itself, and even more useful in combination with GX variations. 
  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    If you’re looking for a prototype of responsive typography that beautifully illustrates potential usefulness of variable fonts, Erik van Blokland has just released a project called Responsive Lettering, which uses SVG and JavaScript: 
    The Jam example
    http://letterror.com/dev/mathshapes/page_31_Jam.html
    is an SVG+JS implementation of a headline made with the Jam font which Erik van Blokland designed 24 years ago in the TrueType GX format, and which was included with an Apple/The Font Bureau demo package that was used as a promo for TrueType GX.

    The real Jam font in GX format, running in Mac OS X 10.3, can be seen here: 

    And here's a video of GX Variations using Matthew Carter’s typeface Skia, the only widely-released GX font, which is still bundled with Mac OS X. The sliders are gone from the UI in modern Mac OS X, but in Mac OS X 10.3, they can still be used: 

  • Deleted Account
    Deleted Account Posts: 739
    Just what is was going to say.
  • Deleted Account
    Deleted Account Posts: 739
    Adam,
    please augment this if you like: 
    "In the dynamic method, the selection mechanism is built into the layout library, with some kind of extended API where the user can supply the axis positions or named instance."

    the     selection mechanism in a dynamic method should be build into the query mechanisms of applications to enable typographic response to compositional and environmental requirements without runtime user intervention.

    I.E., I am sure sliders are possible, but if one targets dynamic variations just for that scope, unless I missed something, one is missing the bigger boat needed for this particular global issue.

    Khaled,
    much more specifically, examples of the gvar table/HarfBuzz or USE issue are discussed at 47:14 of  which is a presentation aimed at the general issue of variation techology's Latin intersection with the real world. The examples I used, I'm told, are much more common in non-Latin.


  • Khaled Hosny
    Khaled Hosny Posts: 289
    Also, there is no support for GX in OpenType Layout, i.e. in the tables that perform the glyph substitutions and positioning.

    Which is basically all I was saying; as things stands now there is nothing an OpenType layout engine needs to know about gvar table. Really, I neither spook about the general concept of interpolation nor the future, I only talked about what is spec’d and implemented so far.

  • John Hudson
    John Hudson Posts: 3,186
    FYI, spec'ing extensions to GSUB and GPOS to make them gvar-aware is one of the work items generated from the recent OpenType ad hoc working group meeting.
  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    @David Berlow: you're absolutely right. My thinking about "user" in this case was more like "software developer who doesn't know much about fonts", but still, I should have said something like: 

    In the dynamic method, the selection mechanism is built into the layout library, with some kind of extended API where the user can explicitly supply the axis positions or named instance to receive an appropriate dynamic instance. Then, the layout engine needs to perform the axis value translation or named-instance selection (as implemented in the "fvar" table), and then it needs to determine the correct advance width of the glyph using a combination of the "glyf" and "gvar" tables. In future, it will also need to process the not-yet-implemented extensions to "GPOS" and possibly other tables.

    There could also be an automatic method, which extends the dynamic method in so far that in addition to the explicit query of the axis positions, either an app or the layout engine could automatically return the appropriate instance based on higher-level user constraints, for example, if the font has an optical size axis, then just supplying the font size should trigger the automatic instance selection along that axis. Similarly, full justification or "fit to width" user requests could lead to the font, together with the layout engine, returning the appropriate line composition with the appropriate instances and features applied. 
  • Deleted Account
    Deleted Account Posts: 739
    edited November 2015
    Adam & John, thanks for the great comments.

    In the automated dynamic method; by composition, I mean also that the automated dynamic method could also need answers from the document's glyph content, to determine, say, proportions among scripts in the least unsympathetic of all typographic worlds, to determine which script's metrics are the best for a particular mixture, say.

    Also, when Adam says, "and possibly other tables";  where a single glyph table (GXish) contains all the instances and exceptions, I don't know a single existing table (besides the obviously pre-web, pre-internationalization-of-the-platform Apple attempts), that does not need an extension to what it needs to know, and/or do, for vars and the combinatorial explosion they bring to tags, metrics and adjacency.  I think it a nearly a full table set to bring into a parallel univars. So, rather than creeping along in disclosure, can you give me an example of a table that might stay the same? 

    And if I understand you correctly, if a future exists where the GX-ish var is interpretable by browser software or not, don't all of the effected tables need a parallel univars anyway, to be able to "speak" to OS' still chained to discrete fonts, or to OS' and/or Apps own versions of     their own parallel univars, assuming they all do the usual, as they've already started out on their own font color and font size thingies?

    Thanks!


  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    @David Berlow The big question about the “higher-level”, or “automatic” information, or “layout magic” if you will, should really be part of the SFNT containers. The possible problem, which you actually also alluded to in your ISType talk (which was great, thanks!) is that in the current world, the SFNT font containers are still very limited in terms of what they “carry”. The trend of trying to build massive pan-Unicode fonts is over, especially with webfonts. It makes sense not only to the font developer but also to the user to have a reasonable palette of font resources, and compose the layout from them. Even with GX, it still will make sense to ship separate upright Latin, separate italic Latin, separate Arabic or Hebrew fonts, and even the question of whether Greek and Cyrillic should be included within the same font as the Latin is a valid one. 

    I tend to think that — at least for the web — it might make sense to look closer at CSS and think about what improvements could be incorporated there, in addition, or alternatively to, trying to squeeze more stuff into SFNT. 

    In your ISType talk, you said that in the manual metal type composition times, a font foundry would deliver certain pieces to the printing house, and then skilled typesetters had the opportunity to tweak stuff. They could find an alternate sort or tweak the spacing or whatever they felt like, because they were closer to the actual design task at hand. And then, you said, with the introduction of machine composition, the opportunities for a skilled typesetter largely vanished: you had the keyboard input on one end, and ready-for-press lines of text on the other. There was much less opportunity for intervention. 

    To me, the SFNT table structure, i.e. OpenType fonts, are closer to the Linotype machines than they are to foundry type. Yes, as a user, you may have a chance to turn on or off some features, but overall, you are a bit limited. 

    The “automated dynamic” method has certain advantages, but it also has disadvantages. If all the automation is put into the SFNT (let’s say, size-specific axis position selection and automated tracking adjustment) then, sure, the results “out of the box” may be “good”, but just for ONE scenario, the one that the type designer or font foundry envisioned. In the current legal paradigms, most font foundries prohibit “reverse engineering” and “modification” of their fonts. So when I buy a commercial typeface, I basically get a “black box” where the type designer or foundry is fully in control, and I cannot touch the damn thing. I cannot easily add my own glyph or change a kerning pair. 

    The more monolithic a data structure is, the more danger there is that the font maker will control “everything” — and what’s left to me as a user is to press some keys on the keyboard, maybe tick some checkboxes, and get “something” at the other end. 

    But the web paradigm, in addition to many other things, made things far less monolithic. With HTML, CSS, SVG and JavaScript, the “web developer” can use the defaults, or dig down to every singular aspect and fix, touch up, override. There are limits, but conceptually, it’s very clean and attractive. Well, text typesetting is currently largely exempt from that — largely due to the fact that the SFNT (TrueType/OpenType) font containers are still largely black boxes. Yes, there are some opentype.js libraries that allow you to parse, look inside and modify bits of webfonts, but their usage is slow and complicated. 

    Simple examples: let’s say that, as a web designer, I’d like to use a particular font, and I like it all, but I don’t like the positioning of the acute accent over “a”, and I’d like to change just that. Or I’d like to make all diacritical marks slightly bigger. Or I’d like to change one kerning pair. Or I’d like to use all glyphs from the foundry-supplied font but I’d like to use my own shape for the ogonek, because I dislike the one made by the foundry. It’s still not possible. 

    On the other hand, anything that can be specified in CSS is currently very useful and great. For example, the web allows me, for the first time in a very easy way, to simply use digits or mathematical characters from one font while all other glyphs from another font. The web allows me to make my Hebrew a bit larger or smaller in comparison to Latin, or to use a completely different font as “the bold” or “the italic”. It’s still not trivial, but HTML+CSS permits that flexibility fairly reasonably. 

    For “automated dynamics”, I think the right way would be to look into creating HTML+CSS+JS+SFNT “font family modules”. Bigger pieces of coded rules that set up the inter-relations between different font resources, and behaviors that describe what should happen typographically if this or that happens (a “bigger font size” is requested or the viewport aspect ratio changes, or a different screen technology is used). 

    It could be the foundries who supply such default modules, but it could also be the “skilled typesetters”, web typographers who, for example, are charged with creating the in-house typography for a given medium. Digging down into, or modifying the foundry-supplied modules is mostly easier than modifying SFNT font files, because these modules would be less monolithic. 

    There are a few projects that I was involved in recently as a typographic advisor where I ended up recommending opensource fonts — not because of the money, but because of the freedom. Because I could mix different fonts the way I wanted, subset them the way I wanted, fix some kerning pairs, reinterpolate a new weight or harmonize the ascender/descender values so that the *set* of fonts that the client ended up using would work better *together*, out of the box. If I were to use a set of fonts from three different commercial font foundries, the permission acquisition and negotiations alone would have taken 3/4 of the time I could spend on these projects, and the cost would increase from a few hundreds of dollars to tens of thousands. 

    This is, of course, a slightly different discussion. But with the “all right reserved”, “no embedding”, “no modifications”, “no reverse engineering” trend of the commercial font vendors, and the restrictive policies they employ, I wouldn’t want all this “automated dynamics” to go into the monolithic data blocks that the foundry controls and claims “all rights” to. This is the machine-composition thinking, with the inner workings of the machine being closed under a secure lock that only the “authorized service provider” has access to — like what happens today with cars. 

    The problem with this isn’t even the “all rights reserved” thing alone. *If* the original designer or font foundry were at least able to perform the modifications I want, that would be great. But sometimes, they aren’t able, or aren’t willing, or will tell me “yes, but it’s $45K and it’ll take 6 months”. 

    I’ve yet to see a commercial foundry that would sell their fonts at sensible prices under a license that says “pay us that and that for the right to use our fonts in these environments, but once you’ve paid, you can modify whatever you want in them”. The clients I worked for would be happy to pay. But since it was hard to find suitable candidates, we ended up using OFL-licensed fonts, even though the design quality of these fonts did not make me entirely happy. But at least the client did could treat these fonts like script, and not like Scripture. :) 
  • Deleted Account
    Deleted Account Posts: 739
    Adam, 

    this is is why I don't spend too much time on this from out of cover:

    "If all the automation is put into the SFNT..."

    it isnt. What's put into the SFNT is, in your example a (1), registered axis and 1 var gpos.

    "(let’s say, size-specific axis position selection and automated tracking adjustment)"

    let' say a size-specific axis and Spacing of all kinds for all of the involved sizes, in a  gpos with varawareness. And let's just say, I'm no foo, so there is a weight axis as well.

    This is the same as you were proposing, plus weight: a range of sizes with proper spacing and kerning for all the sizes. Who tracks, when this is available.

    "...then, sure, the results “out of the box” may be “good”, but just for ONE scenario, the one that the type designer or font foundry envisioned."

    i dont get it? If that "one scenario," is the spacing of a typeface at all sizes, without the operator having to reach in and change masters, it is a big thing, compared to what users have now, with which one fake thing, with one fake spacing for all sizes, really FOR one scenario, the one that the type designer or font foundry envisioned, except at Apple. 

    From there on, you are commenting about automated variation fonts (like they can't be done yet), as being too "monolithic", and as if there 'r explosive devilscripting bolts around the product preventing users from reaching in and using whatever the font they want for whatever size they want to use it for. Select text, turn off the size awareness, change styles... this is already at work in the Mac. 

    Any one of the 1,000s of proportion, style, size or subset dependent fonts from such a variation font can be specified deployed, and employed just like any other font. So, in effect you are saying, the same thing I've always heard from many, "even though they want do that, we don't want to let them do it because then they'd have to do it that way, and the whole publishing world would come crashing down on our heads, and miss your head entirely, just hurting your pinky, Berlow, so forget it";)

    I have confidence, nonetheless, because the things that drive our effort are not us, but users like Apple, and other users who use things like opentype, and CSS and fonts, but don't want the quality of your father's postscript type anymore, or the hassle of your grandma's InDesign use either. And they are not afraid of things being taken away by substantial additions to their typographic power, because it don't work that way, (ever).

    "I’ve yet to see a commercial foundry that would sell their fonts at sensible prices under a license that says “pay us that and that for the right to use our fonts in these environments, but once you’ve paid, you can modify whatever you want in them”. "

    Well you're lookin' at 'im. We started doing it for any customer who asked in 1990. A few customers who wanted this, brought us fonts to fix, that they had gained such rights to, but most wanted to have this kind of license to the fonts we made, and we did so for dozens of companies to the .fog or vfb. They then owned the fonts outright   and could do anything they wanted with or too them. We still do this. 

    Normal users on the other hand do not like Scripture, they funk'in' love it. Who told you all that other stuff, and that type has just got to be nonolithic? 

  • Adam Twardoch
    Adam Twardoch Posts: 515
    edited November 2015
    For size-specific automatic tracking, there is the Apple-specified 'trak' table ( https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6trak.html ) which is very neat and simple. fontTools ( https://github.com/behdad/fonttools ) now supports it, and it's supported on Mac OS X (the new San Francisco fonts use it). 

    The messy thing about optical sizing is that we now have a number of different methods in the specs, and none of them really works. There is the Apple-specified "opsz" GX variation axis, but I have no clue whether OS X supports it in any way. There is the Adobe-specified "size" OpenType feature which has this font mapping for automatic switching between different fonts, and some Adobe fonts have it built it, but AFAIK, not app really supports it. Then, there is the new Microsoft "OS/2" table version 5 extension, which nobody knows how it's supposed to work, but it's implemented in the Sitka fonts. And there is the "trak" table. 

    Automatic optical sizing is of course complicated because you need to settle on some kind of measuring units, and as we know from Nick Sherman's talks, in the digital realm you aren't really sure at all what the physical size of your displayed type will be (i.e. you never know how far the screen is from the projector, so to speak). 

    OK, maybe I've gone a bit overboard with my reservations towards putting too much stuff into the SFNT font container. But still, I'm rather skeptical whether it'll ever work sensibly. I mean, the trainer can train the monkey to dance in principle, but if the trainer only trains the monkey to dance one dance, then it's not so good of a dancing monkey. I think it does make sense to put GX variation into the font and have a standardized way to ask the font to pull out a certain position on the axis, and that should be in the font. 

    But I think the recipes that tell software which axis position to use when should be outside the font. Because with type, it's not obvious to tell what exactly should happen on a digital medium. I mean, if I pinch-zoom on a document, should the type change in an optical-size aware way? Or, if the type always uses the correct optical size, how do I show an enlarged setting of a small optical size? :) You may quickly run into this problem: https://youtu.be/Z86V_ICUCD4 

    I think Adobe, Apple, Google and Microsoft will never agree on one way of doing this. But if the monkey can dance any dance, yet a designer can write his favorite choreography in CSS, and then it works on a particular website that uses that CSS, then it's fine with me. Because some people may want a different optical size to be used at the same nominal point size, e.g. because they're designing on a 15" screen but the actual final output will be a massive billboard or some gigantic screen on Times Square. Or an Apple Watch UI (i.e. tiny) :) 

    In other words: more often than not, the content creation tends to happen in different physical proportions than the intended content consumption. So all digital "point sizes" are actually fake. 
  • Dave Crossland
    Dave Crossland Posts: 1,429
    edited November 2015
    For “automated dynamics”, I think the right way would be to look into creating HTML+CSS+JS+SFNT “font family modules”. Bigger pieces of coded rules that set up the inter-relations between different font resources, and behaviors that describe what should happen typographically if this or that happens (a “bigger font size” is requested or the viewport aspect ratio changes, or a different screen technology is used). 

    I think it would be even better if the fonts were described in css, not sfnt. Thus, CPS :)
  • Deleted Account
    Deleted Account Posts: 739
    Go ahead then and make 'em, Dave, specify a concerto of standards for type across css, js, html and sfnt. 

    And this, is one amazingly popular answer;

    "Because with type, it's not obvious to tell what exactly should happen on a digital medium."

    and so, no users should get automated help for variation font use, because it's too complicated to supply the same help to all fonts, uses and users.

    Sensibly, I've discarded this argument, and the next...

    "(i.e. you never know how far the screen is from the projector, so to speak)."

    Because all uses don't include a single user looking at a screen from a recommended distance, no uses should allow optical sizing, or advanced variation technology. Or     because people go to movies and drive cars past signs, all type composition must be size-stupid.  

    Makes little sense to me, so I have discarded this too.
  • Andrew Johnson
    Andrew Johnson Posts: 14
    edited November 2015

    Thanks so much for posting this Adam! I'm nowhere near as smart or well versed on font technology/history (I'm a product/web designer) as you guys, so bear with me :)

    Adam Twardoch said:
    Conveniently, in the GX model, the axes use four-letter tags as names. Apple registered "wght" for weight, "wdth" for width, "slnt" for slant, "opsz" for optical size. This is similar to OpenType Layout feature tags, so it's quite possible that external APIs don't need to change at all. Instead, "we" could agree to treat font variations, conceptually, as advanced typographic features.

    Today, the CSS font-feature-settings descriptor and property have this syntax: 
    font-feature-settings: "smcp", "swsh" 2;
    and in general, OpenType Layout permits a feature parameter to be supplied along with a requested OpenType Layout feature tag that needs to be applied. Not many UIs currently support this, but there are fonts where the "swsh" or "salt" feature uses GSUB LookupType 3 (Alternate Substitution), and the above CSS syntax uses the integer 2 to select the 2nd alternate specified in the "swsh" feature. 

    It's easy to imagine that the GX variation selection could happen using the same mechanism, and the CSS could look like: 
    font-feature-settings: "wght" 1.8, "wdth" 0.9, "smcp", "swsh" 2;
    or something like that. In essence, GX axis tags with the requested float values would be treated by apps and layout engines in the same or very similar way as OpenType Layout feature tags with numerical parameters. 

    Additional standardized axis tags could be proposed and registered, and we could ensure that, just like today, the registered GX axis tags and the registered OTL feature tags would not conflict. 


    So if i'm understanding this right, the GX model already has specifications for axis names. How would someone specify an axis for something like the addition of serifs or stroke contrast? Is there some way to register a new axis tag on the fly or use an agnostic one? Would that limit type designers’ (maybe it makes more sense for licensing – axis a la feature) way of specifying masters? That's the primary benefit of GX over MM, right?

    Coming from a design and CSS standpoint, alterations to the text are largely based off of the context and goal of the rest of the design, whether that's compositional or interaction based. While weight and width/‘height’ (and then optical sizing, etc.) are the easiest identifiable use cases, designers (both type and web designers) don't care as much about discreet tags for properties as they do how type informs and is informed by their visual design. Which is why I agree with you here:

    Adam Twardoch said:
    But I think the recipes that tell software which axis position to use when should be outside the font. Because with type, it's not obvious to tell what exactly should happen on a digital medium. I mean, if I pinch-zoom on a document, should the type change in an optical-size aware way? Or, if the type always uses the correct optical size, how do I show an enlarged setting of a small optical size? :) You may quickly run into this problem: https://youtu.be/Z86V_ICUCD4 

    I think Adobe, Apple, Google and Microsoft will never agree on one way of doing this. But if the monkey can dance any dance, yet a designer can write his favorite choreography in CSS, and then it works on a particular website that uses that CSS, then it's fine with me. Because some people may want a different optical size to be used at the same nominal point size, e.g. because they're designing on a 15" screen but the actual final output will be a massive billboard or some gigantic screen on Times Square. Or an Apple Watch UI (i.e. tiny) :) 

    In other words: more often than not, the content creation tends to happen in different physical proportions than the intended content consumption. So all digital "point sizes" are actually fake. 

    I think that's on point (pun intended)!


    There is a good balance that has to be struck though.

    Adam Twardoch said:
    …The “automated dynamic” method has certain advantages, but it also has disadvantages. If all the automation is put into the SFNT (let’s say, size-specific axis position selection and automated tracking adjustment) then, sure, the results “out of the box” may be “good”, but just for ONE scenario, the one that the type designer or font foundry envisioned. In the current legal paradigms, most font foundries prohibit “reverse engineering” and “modification” of their fonts. So when I buy a commercial typeface, I basically get a “black box” where the type designer or foundry is fully in control, and I cannot touch the damn thing. I cannot easily add my own glyph or change a kerning pair. 


    The more monolithic a data structure is, the more danger there is that the font maker will control “everything” — and what’s left to me as a user is to press some keys on the keyboard, maybe tick some checkboxes, and get “something” at the other end. 


    But the web paradigm, in addition to many other things, made things far less monolithic. With HTML, CSS, SVG and JavaScript, the “web developer” can use the defaults, or dig down to every singular aspect and fix, touch up, override. There are limits, but conceptually, it’s very clean and attractive. Well, text typesetting is currently largely exempt from that — largely due to the fact that the SFNT (TrueType/OpenType) font containers are still largely black boxes. Yes, there are some opentype.js libraries that allow you to parse, look inside and modify bits of webfonts, but their usage is slow and complicated. 


    Simple examples: let’s say that, as a web designer, I’d like to use a particular font, and I like it all, but I don’t like the positioning of the acute accent over “a”, and I’d like to change just that. Or I’d like to make all diacritical marks slightly bigger. Or I’d like to change one kerning pair. Or I’d like to use all glyphs from the foundry-supplied font but I’d like to use my own shape for the ogonek, because I dislike the one made by the foundry. It’s still not possible. 


    On the other hand, anything that can be specified in CSS is currently very useful and great. For example, the web allows me, for the first time in a very easy way, to simply use digits or mathematical characters from one font while all other glyphs from another font. The web allows me to make my Hebrew a bit larger or smaller in comparison to Latin, or to use a completely different font as “the bold” or “the italic”. It’s still not trivial, but HTML+CSS permits that flexibility fairly reasonably. 


    For “automated dynamics”, I think the right way would be to look into creating HTML+CSS+JS+SFNT “font family modules”. Bigger pieces of coded rules that set up the inter-relations between different font resources, and behaviors that describe what should happen typographically if this or that happens (a “bigger font size” is requested or the viewport aspect ratio changes, or a different screen technology is used). 


    It could be the foundries who supply such default modules, but it could also be the “skilled typesetters”, web typographers who, for example, are charged with creating the in-house typography for a given medium. Digging down into, or modifying the foundry-supplied modules is mostly easier than modifying SFNT font files, because these modules would be less monolithic. 


    There are a few projects that I was involved in recently as a typographic advisor where I ended up recommending opensource fonts — not because of the money, but because of the freedom. Because I could mix different fonts the way I wanted, subset them the way I wanted, fix some kerning pairs, reinterpolate a new weight or harmonize the ascender/descender values so that the *set* of fonts that the client ended up using would work better *together*, out of the box. If I were to use a set of fonts from three different commercial font foundries, the permission acquisition and negotiations alone would have taken 3/4 of the time I could spend on these projects, and the cost would increase from a few hundreds of dollars to tens of thousands. 


    Maybe this will shift, but the vast majority of product and web designers don't care about diacritics and aren’t savvy enough to use something like OpenType.js. It's even less likely they'll be in a position to advocate for the development or performance cost associated with a library like that (unless maybe it's someone on an editorial design team during a certain phase/lifecycle of a project/website respectively). In the same way few designers are likely to go in and make modifications to glyphs – especially if they're a part of the typographic system like a set of marks or kerning pairs.

    The ‘blackbox’ is definitely a thing beyond a development barrier. I think part of that has led to designers keeping a mental model of a typeface being a carefully considered thing that should rarely be modified for better or worse. Most of the designers i've shown my interpolation examples to are immediately on edge because they perceived it as making modifications to the type that compromised on the design, even if they didn't know how.

    While I think the font should largely be open to designers/web developers (immediately relevant stuff like ability to subsetting through a ) I think system modifications like font’s kerning pairs or what masters and axes are available are generally best left to type foundries that know those things best.
  • Georg Seifert
    Georg Seifert Posts: 674
    While I think the font should largely be open to designers/web developers (immediately relevant stuff like ability to subsetting through a ) I think system modifications like font’s kerning pairs or what masters and axes are available are generally best left to type foundries that know those things best.
    I know some (book) designers that don't ever use a font as supplied by the foundry. Because they have different requirements on the spacing then most people and a lot fonts don't have kerning for f) or (j.


  • Louis Rémi
    Louis Rémi Posts: 3
    edited November 2015
    Hi guys, I'm a total font-format newbie too, but as a web developer I know too well how slow it can be to see change happening in a large ecosystem.

    How long can it take to get a new font format supported accros web browsers? No less than a year I'd say. But it could well be three years as well.
    How long will it take to get it supported across OS and major applications? And what about the UI to interact with it?

    On the other hand, Chrome and Firefox have added a low-level API that allows to programmatically load a font into a page with acceptable performances. This means we can now invent new intermediate font formats, embedding as much logic and complexity as we want, and render them as "static" OpenType fonts in the browser.

    My point is that it might be useful, in parallel to the development of new font formats, to advocate for OS-level APIs that would allow to replace in real-time a given font system-wise. This way, next time a font format is invented or improved, it'd be possible to use its end result immediately across applications. And the UI to interact with it could be deported to specialized applications.
  • John Hudson
    John Hudson Posts: 3,186
    How long can it take to get a new font format supported accross web browsers?
    Terrifyingly quickly when the will is there, which is why 2009 was such an alarming year.

    In the present instance, it's worth noting that it is the largest browser maker that is driving the initiative to revive gvar and marry it to OpenType.
  • Deleted Account
    Deleted Account Posts: 739
    True, but the will to build a garden fence vs. an international botanical garden (and zoo), with thriving ancient species and modern mutants, (inside that new fence), might be different enough to bring paws for concern between bride and groom.

Categories