Proposal for font distribution/installation app

yanone

An idea came up about user accounts for the app that allow automatic syncing of fonts between computers, as well as restoring all settings for a new computer. (The fonts themselves would still be pulled from each individual server). 

I thought this through. I'm against it because it requires the centralized server that keeps track of everything that I was trying to avoid.
Also I thought it would be elegant if the app wouldn't require a user account. People are probably sick of them. Are they?

On the other hand, it solves a very serious issue: license allowances locking up because someone lost or crashed their computer (and foundries really only allow the exact number of seats). Then they can't deinstall the fonts, and the thing becomes a customer support issue for the foundry, who need to manually increase the allowances.
Whereas if the central server keeps a ledger of people’s installed fonts, the users themselves, aided by the software, could revoke an entire app instance’s worth of fonts, and the central server would basically tell the foundry API that these font installations are uninstalled, making way for new installations on a new computer.

Automatic syncing and backup is just a by-product of this idea.

I could require a user account for using commercial fonts, and make it optional for using free fonts.
This way I could take some load off the server. I'm really scared of this part.

So next to convenience for users, necessity for user accounts depends a bit on how strict foundries would be about the seat allowances being exceeded, given that this system is only in addition to regular font downloads from foundry’s websites.

Curious to hear your thoughts.

Dave Crossland

yanone said:

if the central server keeps a ledger

I'll buy your ICO

Thomas Phinney

Designers should be stored at the font level, not the family level. This does not come up often, but it does come up. Usually they will all be the same for all family members, but not always.

Interesting that you want to have versions at both the font level and the family level. I would just say they are at the font level.

yanone

Thomas Phinney said:

Designers should be stored at the font level, not the family level. This does not come up often, but it does come up. Usually they will all be the same for all family members, but not always.

I see. I'll do both, the font-level references overriding the family-level ones.

Interesting that you want to have versions at both the font level and the family level. I would just say they are at the font level.

Same as above, that's for saving space and traffic. My poll showed that 71% (of just 21 votes) of people issue new versions across the entire family. So in 71% of cases it is sufficient to define each version once at the family level. I don't want to see 10 different versions being defined with change descriptions and all repeated identically for 20 fonts in a family.

yanone

Hi, me again.

I need some help.

What font formats other than TTF and OTF are expected to be installable on a computer or mobile device these days?

I will accept only the new font/ MIME types, which are:

collection	font/collection	[RFC8081]
otf	font/otf	[RFC8081]
sfnt	font/sfnt	[RFC8081]
ttf	font/ttf	[RFC8081]
woff	font/woff	[RFC8081]
woff2	font/woff2	[RFC8081]

Is it basically all of the above except woff/2?
Thank you.

Dave Crossland

Graphite fonts typically have the .ttf extension, and so I think likely use the font/sfnt or font/ttf mime types. While AAT fonts are around, they are even more rare, but same same

Jack Jennings

For what its worth the specification for the schema will be more valuable than the app. There are already a million ways of syncing files and everyone has a different system that you’d compete with.

If you want to put in extra work somewhere for adoption, maybe building a client library for the format in a few different languages (or coordination a few people to help with that) would be a good idea. Python, JS, and ObjC/Swift would all be low-hanging targets

I’d also agree with Thomas that versioning at the family level feels strange, as you’re not installing a file that corresponds with a family, and any software would need to check each font style version for individual updates regardless.

Johannes Neumeier

Couldn’t license allowances be tracking usage on a per month basis, automatically discerning out of action devices with no longer accessed installations?

yanone

Jack Jennings said:

If you want to put in extra work somewhere for adoption, maybe building a client library for the format in a few different languages (or coordination a few people to help with that) would be a good idea. Python, JS, and ObjC/Swift would all be low-hanging targets

For the time being, I see myself providing Python libraries, and good documentation. I'm only doing this in my spare time. We'll see about other languages later. Since it will be open source, people are always welcome to join.

Johannes Neumeier said:

Couldn’t license allowances be tracking usage on a per month basis, automatically discerning out of action devices with no longer accessed installations?

Once a central server exists that keeps track, it can aid decisions based on last access time. But I don't see automatic action based on it as a viable option. What if a computer is meant to be used offline somewhere?

Rasmus Andersson

This is a really cool idea!

I've been thinking of something similar for a while, though mainly my thoughts have been around the problem of keeping fonts up-to-date and find a good, open-source and truly distributed way for doing so.

Last week I wrote up what I think is needed:

1. Distributed, plain & simple repository model
   1. There's a default, main repository of fonts that are free (as in free to distribute) that the working group hosts and maintains.
   2. Anyone can setup a repository; e.g. host fonts internally at your company and restrict access to people who have licenses for the fonts.
   3. A repository is just a set of files served over HTTP(S) and should be serviceable from any HTTP server (no dynamic content generation required.) E.g. AWS S3, GitHub, etc.
2. A small and portable program (fontctrl) that manages fonts on a computer and serves as the client for accessing repositories.
   1. Can be configured to operate on any number of repositories via a simple JSON configuration file (~/.fontctrl.yml on Posix systems)
   2. Memorizing the user's preference of fonts and any versions limitations (e.g. "inter-ui >= 2.*")
   3. Keeps font files up to date according to the user's preference and availability in configured repositories, by

Long-term goal is to make it easy for designers to keep all their font files up to date, including updates to fonts they have purchased licenses for. Operation should be as automatic as possible, optimally operating without user intervention (e.g. via scheduled invocation or as a service.)

After having a discussion with a bunch of folks on Twitter and over email, I realized this is not a bad idea, and over the weekend I wrote a first version of what's described above, and the source code is available at https://github.com/rsms/fontctrl (where the README describes how repositories would work in more detail.) It turns out to be really fast, too, scanning & parsing about 450 font files that are currently installed in my ~/Library/Fonts directory in about 80ms.

It's a command-line client and should be easy to "orchestrate" by a GUI app. I wonder if our ideas could be combined in that way — a nice native GUI app (set of, for each popular platform) that provides speciment previews and a an easy to use interface), and under the hood is fontctrl :–)

Jeremy Dooley

Just FYI: http://po.et

yanone

I have a question about the data structure and common practices.

Currently, fonts of all kinds sit equally under a family. This could include OpenType fonts, TrueType fonts, web fonts, app fonts (only the former two are installable, the others just downloadable).

But then, the OpenType and TrueType variations of a font would be treated as different fonts.
It's of course still possible to count the installations for both variations on the server end, and treat them as though they were one font. But it's more confusing.

Or would it be better to add "variations" data points that sit under the font and cover the different formats? This is more logically structured, but also more complicated.

Is there a situation one needs to consider where a foundry ships both OpenType as well as TrueType fonts but wants them to be treated as one when it comes to license observance?

Dave Crossland

(I would use "bundles" or "sets" or "formats" – something other than "variations", because that is now closely associated with OpenType 1.8 "Variable Fonts"

Dave Crossland

https://medium.com/future-fonts/introducing-futurefonts-xyz-8c0569777db6 seems relevant to this

Johannes Neumeier

yanone said:

Or would it be better to add "variations" data points that sit under the font and cover the different formats? This is more logically structured, but also more complicated.

Relating to this, what's the imagined approach for bundles like entire family, or arbitrary combos of different styles?

yanone

Johannes Neumeier said:

yanone said:

Or would it be better to add "variations" data points that sit under the font and cover the different formats? This is more logically structured, but also more complicated.

Relating to this, what's the imagined approach for bundles like entire family, or arbitrary combos of different styles?

This question remains open for now.

I thought about it, but haven't figured out an approach yet. The first version of the app will become available in a couple of days. Then we will be able to see everything more clearly hopefully.

yanone

In anticipation of my upcoming presentation on Robothon 2018 in a couple of days I’m moving the discussion over to the new thread http://typedrawers.com/discussion/2590/type-world-font-installation-protocol-and-gui-app/, which I will hard-code into the app and web site.

See you all on Robothon hopefully.