This project aims to define a protocol for automatically downloading, installing and updating fonts from decentralized servers through a GUI App.
Instead of shipping the fonts by email and asking all recipients to install them, users will be provided with a link starting with a custom protocol such as typeworldjson:// that will fire up the GUI App and offer font installation with just one click.
Once the fonts are installed, users will be notified of available updates via the app’s icon and system notifications, and can update them easily.
Download GUI App
|Establish basic Windows and Mac app build||Done|
|Plain font installation||Done|
|Finalize URL scheme, transport and subscription security||Done|
|Finalize JSON protocol||In process|
|Finalize Github-hosted protocol||In process|
|Type.World user accounts and integration/sync with the app||Done|
|Run as background process to inform about font updates||Done|
|Display all meta data about the fonts||Open|
|Warn about overlaps with fonts already installed in the system||Open|
|Optional automatic update of fonts||Open|
|MacOS Mojave Dark Mode support||Open|
|Distribute app in Mac App Store and Windows Store||Open|
Please follow the development of the Type.World project on Github.
The main idea is that font foundries that operate their own online shop will provide data under an API endpoint that puts out JSON responses. These responses will contain all the data necessary for customers to install the fonts through the GUI App.
The app will consume links to JSON API endpoints that start with the custom protocol handler **typeworldjson://**
The subscription links that will be handed over to the app look like this:
**typeworldjson://https//subscriptionID:secretKey@server.com**, with *subscriptionID* being the identifier for which fonts to serve to who. In case of per-user subscriptions, a subscription ID needs to uniquely identify a user. It is advised to make this handle anonymous.
The *secretKey* is a key that is known only to the server and not necessarily to the user. It will be handed off to the app via a secure web site, then stored by the app in the OS keychain and later used to authenticate the app against the server.
You should write your own server using this API, and connect it to your online shop’s work flow.
You can implement your server in any language you like, as long as it follows the API protocol.
JSON-based demonstration link for GUI App:
Links starting with **typeworldgithub://** may point to arbitrary paths in GitHub repositories, whose contents are structured in a certain way.
The app will pull the fonts from there. This is in a very early stage of development and not yet documented at this point.
GitHub-based demonstration link for GUI App:
For workgroups that don’t want to set up their own server, complementary servers exist for you to use.
One such server that serves fonts under the JSON API protocol is available from Yanone as an independent service under the intelligent name typeworldserver.com.
You can hop over to create a free user account to play with the system. It comes complete with user control, but a very unoptimized backend UI. Fast prototyping.
Let me know about more services that should be added here.
The tools page consists of a set of tools that can help you develop your API endpoint. Currently, it only holds an API validator to remotely validate your API endpoint.
Type.World has its own JSON API endpoint at the url
https://type.world/jsonAPI/ serving various purposes, most notably the remote JSON API validator. Read it’s documentation here.
Today I can see three scenarios where the Type.World font distribution environment would come in handy.
A font publisher who operates their own online shop (could be a self-publishing foundry or a reseller of several foundries) wants to make all of their end user’s purchases available for the end users to easily download and install.
The suggested hosting option is a JSON API endpoint on the publisher’s server that ties in directly with the publisher’s online shop. All data to make the font downloads available is already handy in the publisher’s system, because they already offer the traditional font downloads (say, as zip files) that are custom-tailored to the user’s purchase history.
The publisher would need to reformat this data to meet the Type.World JSON protocol, assign each user an anonymous user ID in their database (if not already present) and send out the links pointing at the user’s personalized Type.World Subscription either by email or on the existing font download pages next to the established font download methods.
If desired by the publisher, font downloads through the app could be tracked on the server end using the anonymousAppID parameter that the app ships with the install request call. The publisher may chose to reject further downloads after the seat limit defined by the user’s purchases of licenses has been reached.
Each user would receive one subscription link that would contain the user’s entire purchase history. The JSON protocol already caters to defining several foundries within one subscription.
Type shops that engage in corporate branding exercises often find themselves in the situation that they have to send out regular updates of their fonts to work groups within their client’s branding companies, whose designers are already working on designs with fonts that are still being developed.
But people are lazy asses (or simply being busy) and might not pay attention to the font updates that came by email the other day that they should have (manually) installed upon arrival.
Seamless distribution of font updates is crucial to create a frictionless workflow between the type shop and the branding office.
Possible hosting options here include both a self-hosted server with a user control system, or a cloud-hosted turn-key solution like Yanone’s own complementary typeworldserver.com that would liberate a type shop from having to deal with the technicalities of hosting their own server.
Each work group would receive one subscription link that would contain the branding fonts.
Fonts can also be distributed without user access restriction.
A scenario for a free font website would be to offer one subscription for each typeface that they are offering. Here it makes sense to split one subscription like in the above two scenarios into individual ones for each typeface because that way the website doesn’t need to keep track of which user subscribes to which fonts.
Working with the Type.World project, you’ll run into three different types of licenses in three different locations. Here’s an introduction to them.
All Type.World code is licensed as open source software under the Apache 2.0 License.
This generally means that the code is free to re-use and change even for commercial purposes. So it may find its way into commercial products even without changes going back to the original code.
I ended up choosing this path because it is actually more promising that commercial operations contribute back to the original code for practical reasons. Stronger copyleft licenses (essentially: free software must remain free and accessible even within a commercial product) often prevents the adoption of code by commercial operations because of its limitations.
Much software within the type world are licensed under similar licenses. The great fontTools counts as an inspiration, which is published under the permissive MIT license, and is today flourishing with much contribution by Google and other commercial groups.
However, despite allowing commercial use and alteration, the original Type.World project itself will always remain free. Open source software is not sellable.
If you chose to implement yourself a Type.World JSON API endpoint, that endpoint will naturally be web-facing and therefore be openly accessible.
Instead of a human-readable Terms of Service Agreement, you publish the metadata about your fonts under a machine-readable copyright license identifier which is contained as a mandatory field in the JSON responses. The accepted license identifiers can be found here.
Any software that consumes your API endpoint’s metadata must decide on its own whether it’s legal for it to do so. For instance, commercial software needs to deny the user access to a subscription if it finds that the endpoint publishes under a license that forbids commercial use, such as the default license chosen by the Python API code, Creative Commons’ most restrictive Attribution Non Commercial No Derivatives 4.0, identified in the JSON response by the string CC-BY-NC-ND-4.0.
This way you retain a relatively large control over who is allowed to use your API endpoints, at least whether they can have commercial interests or not.
All of this is not to be confused with your actual products: your fonts. Nothing changes about the way you license them. You remain the distributor of these fonts and dictate their conditions. The Type.World project merely provides a way to get your fonts installed on end user’s computers.
And while your API endpoint is openly accessible as outlined above, the access to your fonts is still restricted to the actual buyers of your fonts in the same way that you currently limit font downloads based on a user’s purchase history. Technically speaking, you would append an anonymous userID parameter to each link that you send out to your end users for identification.
For general discussion please follow the Typedrawers thread.
For code-specific issues please open an issue in the respective GitHub repositories.
This project needs your financial support.
Please donate over at patreon.com/typeWorld