Type.World Font Installation Protocol and GUI App

yanone

In anticipation of my upcoming presentation on Robothon 2018 in a couple of days I’m pulling the discussion about the font installation proposal from http://typedrawers.com/discussion/2431/proposal-for-font-distribution-installation-app/ over here and hard-coding this link into the app and web site.

See you all on Robothon hopefully.

yanone

Earlier today I presented the Type.World project at Robothon 2018, a font installer protocol/app in development. 

Please check the website at https://type.world,

the code on GitHub at http://github.com/typeWorld 

and Twitter on @typeDotWorld.

It is aimed at small/independent font publishers (or their customers, really), as a way to easily install fonts on customers computers.

The code is currently not yet carrying a license. I'm currently looking into the matter and will publish it under one of several possible open source licenses very soon.

Dave Crossland

The code is now licensed under the Apache 2.0 license. 

yanone

I started adding issues to the GitHub repositories. For instance, two future features are listed here: https://github.com/typeWorld/guiapp/issues

I invite you review the project.

Pay special attention to whether the JSON API protocol fits all your foundry’s requirements for bundling your fonts and its metadata. Can your entire catalogue be reproduced using the available data structure?
https://github.com/typeWorld/api/tree/master/Python/Lib/typeWorld

Any issues you have, please post them here or as issues in the respective repositories at https://github.com/typeWorld

yanone

For all who missed out on Robothon or who found my explanations too technical, here’s another 10 minute read explaining the project: https://type.world/blog/what-is-type-world/

Dave Crossland

What other font syncing services are available these days?

https://fonts.adobe.com

https://www.hellofonts.cn

Marc Oxborrow

Monotype’s font holdings can be synced via MyFonts.com. 

Jens Kutilek

I'm trying to figure out the Type.World API. I missed the Robothon presentation, and in the livestream video the screens are very small so I can't read what you are typing there.

@yanone, you are giving this as an example URL:

typeworldjson://https//typeworldserver.com/api/toy6FQGX6c368JlntbxR/ (btw. the GUI app hangs when I enter this)

What is not clear to me is what the last part is. Is that a user api key? Is it just an obfuscated URL? What should the API return if this "key" is not present? (In the case of the Type.World Server it returns an internal server error.)

As URLs can't be considered private, I think the inclusion of the key there is less than optimal. Perhaps the URL in this format could only be sent once to the Type.World GUI app, which could then send this key in the request header 'Authorization' instead?

yanone

The above link should work again now with version 0.1.4.

Earlier, the subscription IDs were indeed thought to be appended to the URL, but that's obviously a bad idea. As of 0.1.4, the new security concept is in effect where subscriptionID and a secretKey get passed as hidden parameters in HTTP POST requests. Each API endpoint should now reject incoming GET requests.

But to answer your question: Since typeworldserver.com is a multi-user service, the various user accounts on it need to be distinguished, in this case by use of an anonymous publisher ID that is unique to typeworldserver.com and not a part of the Type.World protocol.

yanone

Btw, since yesterday, Type.World’s crowd funding campaign is out over at https://www.patreon.com/typeWorld

Even small contributions go a long way when many people contribute regularly.

Please help me shoulder its development by sharing some money with me for a tool that would otherwise stay undeveloped.

As independent publishers we have a collaboration and focus problem that insanely focussed corporations don't have.  

Sharing the costs of a such a development effort is an easy way for everyone to help reduce the user experience disadvantage of independent publishers over centralized market places.

Thank you

AbrahamLee

Is there a customizable way to decide where the fonts are located? What if you want to install other non-font, but font-related, files?

yanone

First, web and app fonts haven't been finalzed in the protocol yet. I'm thinking of zip files that then can obviously contain other files, and they will probably not end up in the system's fonts folders.

For desktop fonts I don't see the point. I was planning for font-related PDFs to be accessible from directly inside the app, defined in the protocol as links. I haven't gotten around to do it yet.

If maybe you could explain what exactly you have in mind? Maybe we can accommodate for it.

AbrahamLee

Thanks, @yanone ! I appreciate your willingness to consider my case.

Most of my work is dealing with fonts for music, which tends to diverge away from normal text fonts in many ways. In last number of years, a "standard" was developed to try and get past all the mish-mash that music notation software companies were doing in isolation in order to get their music fonts working. Because everything was done in isolation, you couldn't develop a font for one music notation software and expect it to work with a competitor's app because the encoding/codepoints were set up differently.

Fast forward a few years to now, there is a well defined standard that is slowly being adopted by the major notation app makers that organizes thousands of musical symbols in the PUA range of Unicode. However, in order to keep font internals as normal as possible (i.e., tables & subtables), some data, specific to the layout of music notation, is kept in an external "metadata" file that is stored in a general, common location for this sort of thing. It's a well defined location, so I know exactly where it is on Windows, OSX, and Linux.

So, I'm wondering if this metadata file have a custom installation location specified. That would probably give me good enough motivation to use this API. I would love to be able to publish updates this way rather than sending out emails.

yanone

Interesting.

So is it one metadata file per font, or one for several fonts?

And where are they going to be located?

And why is the meta data not stored in the meta table in the fonts themselves?

AbrahamLee

One file per font, contained in a folder by the same name. This folder is located in the following common location, per platform:

- Windows: %COMMONPROGRAMFILES%/SMuFL/Fonts/fontname/fontname.json

- OS X: /Library/Application Support/SMuFL/Fonts/fontname/fontname.json

- Linux: $XDG_DATA_DIRS/SMuFL/Fonts/fontname/fontname.json

I personally have no qualms with storing unconventional sub tables in the font itself, but “the community has spoken” and therefore went with the external file to hold the data.

yanone

Is there any official documentation about it online that you could point me to?

I would like to read a bit more about it.

AbrahamLee

By the way, this is called, “Standard Music Font Layout” or SMuFL for short. This is the official online technical documentation:

http://w3c.github.io/smufl/gitbook/

There’s a section on the metadata/files under the “Specification” section.

yanone

The notation /Library/Application Support/SMuFL/Fonts/fontname/fontname.json is unclear in two ways that the specifications don't clear up:

Does fontname mean the complete and identical fontname, including file type, like font.otf?

Also, three json files are mentioned, but the path above holds the fontname variable twice, also in the actual file name. How does that go together?

So what are the complete path examples for font.otf?

But these are details. Here's the bigger picture:

An open source software development effort usually gets shouldered by different people in different ways. One such way is to share development costs. If many people chip in, the burden on the individual is small.

To give you an idea: So far I've worked half a year full time on the project, and an end is not in sight. This is half a year of my life without an income, and I need to slowly build a community if supporters.

I think Type.World is exactly the kind of software to support your issue. 

But if and when I can implement it highly depends on how much money you and your colleagues can throw behind the cause.

I'll leave that in your responsibility while I continue to develop the app.

If we can gather a few hundred to a thousand dollars over time in total, I'm all yours.

Here's the continuous crowd funding campaign:

http://patreon.com/typeWorld

yanone

By the way, we need to have a super bold security warning about installing those extra files. Just letting you know. It can't be completely automatic.

AbrahamLee

Thanks for you’re response. In this case, “fontname” is the internal font name of font.otf, since that’s what appears in the font menu. So, the font file *can* have the same name as its internal name, but that’s not required. What is required is that the metadata .json file and the folder that contains it have the exact same name. I’m not sure why there needs to be the extra folder, but that wasn’t my decision. Either way, it’s clear what is expected.

yanone

But then how can there be the three different json files that the specification points out, glyphnames.json, classes.json, ranges.json?

AbrahamLee

Those three files a not font specific. They are there simply to provide apps with what the specification currently includes. Not all fonts will include every glyph, none of mine do, but it provides a framework for apps and font developers.

Stephen Coles

Yanone’s Robofont talk:
https://vimeo.com/331003901
And a more recent video of Type.World 0.1.6:
https://www.youtube.com/watch?v=cCrzKEL4CfA

yanone

So, have we all seen the iOS dev talk about font installation?

https://developer.apple.com/videos/play/wwdc2019/227/

Obviously, Type.World will develop an iOS app (and Android) at some point. But installable fonts need to be registered with the app as an asset to undergo review before app publication.

Bummer!

Which makes it somewhat impossible to load arbitrary fonts into the system.

Today, the only way I see this possible through the Type.World protocol is that each publisher provides their list of fonts through the API, and Type.World regularly collects all those assets into the app. Which means that making newly released fonts available to the user will require regular app updates.

And it probably completely torpedoes server-side on-the-fly generation of fonts to be loaded into the OS.

Am I missing something?

Hrant Հրանդ Փափազեան Papazian

Android would be great.

https://twitter.com/hhpapazian/status/769612643220893696