Howdy, Stranger!

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

D. Epar ted


D. Epar ted
Last Active
Member, Type Person
Invited by
Admin James Puckett
  • Re: [OTVar] Axes Proposals:



    I will rehash a part of our conversation in Berlin regarding the use of whatever the heck values a type developer needs to record, backwards. 

    You, “Oh, I just now got it!” 

    You said that aft ei said this:

    Me, “...well, the CVT is pretty valuable, it covers many of the same values we are talking about here, and no one knows what’s what, explicitly, in that Truetype table?!”

    I will add here, that I would love to make the per mille values explicit to a script, and a glyph of that script, and to a pair of index points, and bend the world to an absolute standard. Just kidding. But, I commented as much into my CVTs for a decade, but then, I eventually converted to the wisdom of Microsoft’s unofficial standardization of the CVT values to specific unit per em measures of pretty specific representative glyphs in the font. You can check the history and effectiveness of that with Mike.

    No one who ever hinted for aliased rendering, doubted the wisdom, operability or usefulness of the CVT table, even in its original chaotic Apple form. And no one who ever standardized those CVT values, across all fonts, failed to appreciate the enhanced programmability such standardization enabled. Failing to have consistent CVTs when hinting a family would lead to unbridled hinting chaos, you can check that with Ross.

    Hinting for Cleartype rendering ultimately dulled the usefulness of the CVT down to the alignments, but to think the same values and more, are not present in variable fonts, no one would do that. Variables need a bigger list, and fewer value systems. The values I listed for you in Berlin were typographic points, degrees of rotation, per mille, pancakes per em and seconds of time. And I meant every word of it, except by pancakes, I mean pixels. You can check that with me.

    Meanwhile, the spec? I see five registered axes, and five value systems. I read your fear of too many axes that won’t be used, and am all for being against that completely. That could get ugly, which is why I responded to Peter’s request to document these After Berlin. While I was there though, I listened very carefully to you and others. So when I wrote this proposal, I added the two additional values systems, to mark Unicode and OT features on an axis. You can check that with your Berlin presentation.

    The spec of the five axes is a done deal, I assume, and it doesn’t work with our proposal, as I explained, among other things. Now, I must respond to client requests and add width and weight axes that do work with our proposal, and they will be exactly as I described them in Berlin. You can check that when I’m finished. 

    I have no desire to discuss it further, thanks for your input, mine is complete, 
  • Re: [OTVar] Axes Proposals:


    I’m going to leave the issues related to axes flags for later, after we finish making, demoing and documenting. 


    “…what negative values are supposed to mean.” a darn good question that starts us on a path to an extreme answer.;)

    In a final composition, transparent space can come and go. Users have the final say as to whether a counter, or inter-glyph space exists or not, as well as how big it is. With variable fonts, for the first time, the internal white space of the letters, the counters... alone... are variable.

    Unlike a final print or web composition, where the counter or inter glyph space that's gone, is black, or zero, so to speak, in composing variable fonts, and with overlapping contours, the underlying counter may still exist, as indicated by it's negative number, meaning that counter has flipped. 

    On operability, while xtra is intended as a hidden axis, programs, or curious users could explore it for all sorts of operability, but first, the selection of the value is an operability leverage point. Being from the same sample in all instances of the axis seems like a reasonable minimum assumption, as this is what ytuc, and ytlc are based on, and no one in their typographic mind changes what in particular they measure, once they start measuring something in particular. 

    So regardless of what value is chosen as long as it's consistently measured, the xtra axis represents a range of transparent counter values on an axis where nothing else is changing. Also, like any other variation axis, every instance in the entire design space now has an xtra value, and its xtra can be micro-adjusted without damaging the typography. What that gives the variable font is a new thing, from this axis. E.G. change to the tracking/letter spacing, at any instance being used from the variable font, can now share that additional space between the xtra axis and the space being added. 

    That's a minor interoperability that lots of applications could hook into today, and it's based on not knowing what the value system means beyond relative per mille per axes. Super-interopability is possible when the same value is chosen across variable families, or anytime the same value, like the counter of the H of a non-variable font, can be added to an interested program.

    I'll also add, that in the design phase, it was long practiced that the counters of every glyph were recorded on the drawings, and used to drive the suggested range of side bearings in the final type. We can do better with letter by letter xtra adjustments, but I think perhaps that's a generation of apps in the future. For now, this axis value is a summary, but like all the others, every glyph that has a counter, potentially has its own xtra, and every glyph that doesn't have any counter, doesn't have any xtra, which i think a lot of people have figured out, is important in and of itself.

    Hope that helps, thanks for the great questions. 

  • Re: Specific diacritic designs depending on language

    I've been thinking about it and without doing any formal research decided to add some additional parametric axes a few months ago as we start to think, and design, beyond the axes and the glyphs we've done. None of our initial variation contracts included accented characters, so this really came out of work that we did on our own fonts.

    We think that besides width, weight and size axis, and beyond into the parametric axes, (and working with composite technology already in the standard), there is separate need for interoperable accent control. So, we envisage independent "above" and "below" cluster parametrics for x and y, opaque and transparent. 8.

    This creates a separately addressable design space for accents, linked if it's so desired to other axes, but within that addition space, the font developer can create "culture-specific" instances. Here, the term culture ranges from a publication to an entire language.

    From there it's on to another proposal for axes flags, identifying them for UI and program interfaces.

  • Re: [OTVar] Spacing axis


  • Re: Why FontCreator hardly used by professionals?

    "...creates TrueType fonts, which only use quadratic Béziers. Such curves are described by three points: two endpoints on the curve and a single control point off the curve. Remember conic sections from high school? That's the sort of things you can create with these. Kinda limiting."

    ...this, I think, is bogus top to bottom. 

    Quadratics can have as many off curve points if you want, I don't remember conic sections from high school, and the limitations to conversion, and possible curvature in digital outline fonts, are all found in Cubics. :)