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: Plex; IBM's new font identity model

    I’d like to commend all of the designers and developers of this font for a bunch of stuff, but raising the corporate bar to include serifs, is all that’s possible under the circumstances. Thanks!
  • Re: Specific diacritic designs depending on language

    That’s all great but the infrastructure of line layout and variables were intended to be implemented together, not Separated by 25 years and artificial barriers of the technologies that grew in between. So it’s always interesting to see what’s going wrong just because of the past politics, and how little has changed in “round two.”

    In any case, if the system cannot deal with the indescrete nature of some typography, it can hardly be considered “whole”, and even if I can only do something with JavaScript, if it is based on axes that help users to better typography, then it must be more wholesome than doing nothing.
  • Re: [OTVar] Changing tracking/HVAR

    John, "why, in fact, registering an axis may imply changes in the font format, or elsewhere in the overall tex processing and display model"

    I'm not convinced, per just this one vuid axis, why, "in fact", the implications, and just that, implications of changes to the font format from the registration of an axis, is not better than not registering an axis at all.

    At the current rate, we have enough axis to last through 440,000 years of such non-registration as we've got. No one has a gun to the head of format change. But, most importantly, if there is anything wrong with overall text processing and display model, registering an axis that allows developers to circumvent, or improve that model if they wish, hardly seems more threatening than a sleepy kitten. 
  • Re: [OTVar] Axes Proposals:


    Thanks for your comments. I will make more comments about "wght" and "wdth" on Peter's 1.8.2 thread soon. But, the two systems (TN's proposal, and the 1.8.2 spec of width and weight axes),  can only be automated one way. So, I don't believe:

    "A conversion of "wght" into a system like the TN proposal can be fully automated".

    If I understand the spec, to be brief, all of the instances of the "regular" weight, must have a weight value of 400. There are thousands of such regular instances in Amstelvar, (sizes, widths and grades of regular), and I know, as they should, those instances have different weights, so they work as a family of typefaces in typography at all those different sizes, widths and grades of regular.

    Removing all the other Amstelvar axes from consideration, I am to label all of Amstelvar's Regulars with 400 wght. This is a simple enough post-process, (as the current wght is per mille, I think), and an “easy fix" for customers who need it. But I couldn’t take a 3 axes variable font, like Amstelvar, where all those Regulars have been labeled "400", and do any more automation with them. I could be wrong but that is not an easy fix.