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: EULAs: No Modifications Clauses.

    "Our way, we can always grant permission to someone who asks and we sometimes do.  But in the EULA we say no."

    That's agreeable to us too, though with lots of experience in this, we press no others to follow. That kind of eula saved us, and I suspect a lot of other font publishers, on web fonts. If our eula permitted mods to our OT binaries, being legally convertible to auto-hinted TT fonts, WOFF-ed and web served, would likely have ruined a lot of founders in a number of ways.

    With change again, as others begin to figure out and implement what "Open Source" fonts mean, and as variable technology relieves some of the pressures for mods, who knows. I cannot say today that I want to allow everyone unauthorized mods on my variable font binaries of tomorrow, but I can imagine maybe at some point I'll see why some developers may.

  • Re: [OTVar] Changing tracking/HVAR


    I think, if you don’t want a mm de facto standard to start, then a minimum sensible set of things to put in, is different for a global standard than what is there now. What is there now does not even cover the existing parameters of an opentype font without variables. Perhaps you need to have responsibility for a broad font library that in the near future is requiring stat tables, in order to appreciate what I’m talking about?

    I also was not asking about a variable upm because I wanted a registered axes, but rather for the establishment of the best value system to propose for the axes appropriate to em parts. That answer is why we use per mille for all the appropriate axes and not percent.

    For upm variation, the glyph, delta and other quantitative data of a variable font, can be quantized via deltas to any upm while remaining on the default upm, which pretty much solves variable upm from Variations. I think people are talking about a “ppm” axis for that, where the value of an instance is the ppm to which the glyphs and data have been quantized.

    But clearly, such sensibility in the face of widespread low quality font rendering is only needed in some distant future. ;)
  • 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.