Best Of

From http://typedrawers.com/discussion/comment/22862/#Comment_22862


Generating on-the-fly names for arbitrary instances within a variations space is difficult problem. What software needs in order to be able to unambiguously identify an instance is different from what users need if instances are exposed in font menus.

On the back end, there needs to be an identifier that can be used to instantiate on the system. That's what Adobe's new technical note on generating PostScript names for Font Variations does. This is important, because let's say you create a document using a custom, arbitrary instance, and then send that document to someone else who has the variable font installed: software needs to be able to accurately recreate the specific instance used in the document, which means the document has to store a pointer to that coordinate in the variations space, which depending on the document format might be no more than the generated PostScript font name. So there are good reasons why that name might need to be a concatenation of axis tags and axis coordinate values.

But such a name would totally suck as something to expose to users. On the other hand, generating human-friendly names for arbitrary locations in a multi-axis design space seems basically impossible. Let's say I have named instance (names for specific locations, stored in the font) for SemiBold and Bold: how can an algorithm automatically generate a unique human-friendly name for each of the possible locations in the design space between those two named instances?

This seems to me primarily a UI issue, and the solution probably has to involve allowing users to assign nicknames to instances. In CSS, this seems trivial, since basically anything in CSS can be given whatever name you like. In desktop apps, it is more complicated. An individual app or suite of apps might provide a model for assigning nicknames to instances, at the document level or in a shared library, but without any interoperability or consistency across the rest of the system or on other platforms.

I think there's room for a standard for nicknames for arbitrary instances, but am not sure where this would have to live, either in software or in terms of a 'home' for such a specification. Should it be part of the OT spec? If we want it to be as flexible as CSS naming, it isn't necessarily limited to variable font instances or even just to fonts.

Interesting subject.

Licenses are by nature legal texts, are written as such and consequently hard to read by most natural entities, aka users. Simpler licenses would at least equip users with the ability to even attempt to comply. As it stands, even "simple" and "permissive" licenses are really hard to understand.

Try even just reading the Open Font License. I try imagine, for example, my mother would read it and try understand if she is or is not allowed to email someone a font that comes with it - no way could she make an informed judgement.
And keep aside also for a moment that most licenses are in English. And let's also keep aside that most font users simply understand fonts as a digital affordance - with the file you can use it, so passing the file to someone who needs to use it is the trivial solution.

In OpenType 1.8, both slant (oblique) and italic axes are defined. It's certainly anticipated that some will use slant as a continuous-variation axis in variable fonts. It's not as obvious whether italic will be used that way, however. Even so, it was important to have some way to indicate italic in the STAT table since it's a very-common variation within families. We could have represented that as a binary flag, but we didn't want to constrain it up front like that (and also didn't want multiple mechanisms for representing different axes of style variation). So, we left flexibility for people to use it as a continuous-variation axis in variable fonts if they wish to.

I should also point out that modifying a font independent of the source files for that font is not a trivial thing, and the amount of work involved and the number of things that can get broken in the process is significant. A few years ago, I was asked to add some smallcaps to a libre font that some friends were using in an academic festschrift. Initially, I had trouble locating source files for the libre font, and when I did find them they were in Fontforge format. In the end, I decided it would be easier for me to build fresh sources from the decompiled OTFs in FontLab than to familiarise myself with enough of Fontforge to do the work in that program. Today, the likelihood of libre font sources being available in UFO format reduces some of the headache, but the fact remains that if one wants to modify a non-libre font, even if the EULA permits it one may not be able to do so easily or without risk of e.g. being unable to recompile aspects of the font such as decompiled GSUB and GPOS tables. It's one thing for a foundry to grant permission for modification; another for modification to be a practical option.

I don't have a standard policy on allowing or prohibiting modification. Unlike Hrant, I think either policy can be culturally valid, and where I am wary of allowing modification it is specifically because I am concerned about quality and about shoddy workmanship appearing in something that is, after all, primarily associated with my name and that of my foundry. If someone modifies one of my fonts, and uses it to publish a book, that modification appears in the context of my typeface, and the reader of the book has no way of knowing that I'm not responsible for the poorly positioned diacritic with no kerning that occurs frequently in that particular text. So I am wary of allowing other people to mess with my fonts. But I don't disallow modification outright, because that doesn't make any sense to me: some modification might be low risk, while other modification might be high risk (also, not only in terms of quality, but the likelihood of the modified font escaping into the wild). So I want customers to contact me about modifications, to explain what they want to do and how they propose to do it. This isn't about negotiating a price — there generally isn't one, unless I'm actually asked to do the modification myself —, but about having some measure of oversight and being able to give the customer advice.

When A2-Type's Antwerp typeface was selected for the English texts of the Murty Classical Library of India, it needed to be significantly extended and customised, with many additional diacritics for transliteration of Indic scripts and less swashy forms of a couple of italic uppercase letters. I wrote the spec for the modifications, and Harvard University Press approached A2-Type to obtain permission. I went to meet with the type's designer, Henrik Kubel, when I was in London, and we ended up collaborating on the modifications. Later, when some additional diacritics needed to be added, Henrik said he was happy for me to do that work, since he'd been reassured by the previous process that I wasn't going to mess it up or do a disservice to his typeface.

This is culture. It's not a one-man-job, but it exists in discrete instances of creation and in interaction between creators. Sometimes we interact with the dead, which means interacting through the work — e.g. as Henrik interacted with the makers of 16th Century types in the Plantin-Moretus museum —, but when we're interacting with the living, it is best to do so in person.

Of course, all this implies a timeframe that is different from the deadlines under which Katy is made to work. I say 'made to work', because things could be different organised than they are at OUP — as Brill has done, for instance. In the MCLI project, HUP had a long lead-time, and of course were planning a whole series, not suddenly realising that the font they'd selected for a given book didn't contain one of the diacritics needed for the text. But I think it is worthwhile considering under what conditions such a realisation even could be sudden and require a 48 hour turn-around. This isn't how books should be made.

If that is how books are made, then one has to adjust a lot of expectations to match, including expectations about what kind of fonts one can use.

You also have to ask yourself, what are these weights for? Are they just to make nice looking specimen sheets or to target optimum use target sizes to weights? I would rather see a jump in weight than see a weight that misses its target. The bolder weights are not the problem, it is the lighter weights that may be used at text or near text sizes.

I always choose weights by eye. And always with the desire to please the magazine art director I was earlier in my career.

@Hrant H. Papazian The only thing you achieve with such posts is eye rolls from the people you might have hoped to convert to your viewpoint.

More importantly, as far as I can tell your post and this discussion are taking the thread off-topic and do not answer any of Katy’s questions. So if you’d like to discuss your stance on modification, I’d suggest you do it in another thread.

I’ve played with linear, cube root (Stanley Hess), De Groot, and Impallari progressions. And I always come to the same conclusion: math is just a starting point. You still have to spend time looking at proofs, and tweaking relationships, and repeating until any particular font progresses through its weights without jarring jumps. 

Renaming the agreement doesn’t change the real problem—people have been trained to ignore license agreements. This isn’t the fault of font companies—the font industry generally does a good job of presenting an readable EULA (at least in a literal sense), as opposed to 5,000 words in a 80x10 character box like software companies often do.

I think it would make more sense to focus on plainly worded license agreements like Matthew Butterick’s or Jackson Cavanaugh’s. Or use an antagonistic license nobody will read, but explain it clearly like Commercial Type. We definitely need to abandon what lazy people like me do, dumping licenses full of legalese on the web site. As long as the agreements remain complex contracts full of boilerplate people will treat them as no different from all the EULAs they run into on a daily basis from Microsoft, Apple, Google, Amazon, eBay, PayPal, etc. 

I know that some of the IP lawyers who serve the industry insist that we have to use antagonistic, burt ironclad, agreements. But maybe the business of getting a nice settlement thanks to an ironclad EULA would be trumped by the business of selling more licenses because users can actually understand them,