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.
Comments
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
https://fonts.adobe.com
https://www.hellofonts.cn
@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?
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.
- 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.
http://w3c.github.io/smufl/gitbook/
There’s a section on the metadata/files under the “Specification” section.
https://vimeo.com/331003901
And a more recent video of Type.World 0.1.6:
https://www.youtube.com/watch?v=cCrzKEL4CfA
And it probably completely torpedoes server-side on-the-fly generation of fonts to be loaded into the OS.