Hi everyone.
For an upcoming project I thought of creating a GUI font installer app that would automatically install the latest version of a typeface that my client can start using at an early stage and then receive and immediately use updates as they become available.
Instead of making it available to use just for myself/my own fonts, I thought it could be an interesting piece of software to have publicly available.
I would program it in Python using a cross-platform GUI library such as pyGUI (recommendations welcome), and host it on Github. I would take responsibility for distributing a signed app for MacOS, and other people can make distros for Windows and Linux later. I really don't want to be bothered with the other platforms, except maybe quality control.
I'm looking for the simple-most design for both customers and distributors, and myself of course. I don't have much time
This is how I think it should work:
Each participating distributor sets up an API point on their website (https only).
After purchasing fonts, customers can then click on a link (can be nicely implemented using custom URL protocols) or copy/paste a URL into the app to show the available fonts.
The API point would accept a customer-specific API key parameter that would limit the available fonts to the purchases of that customer. The API point would then return a list of fonts and the customer can choose to install those fonts on his system with the option to keep them up-to-date automatically.
The distributor could choose to limit the number of installations of a font to the number of seats covered by the purchased license at his responsibility using the anonymous "uniqueAppID" parameter of the download URL (see below). He could then reject the inquiry with a predefined response such as "toomanyseats", together with a URL for the user to upgrade the license. Then, a font would first need to be removed from another installation.
The "seatsAllowed" and "upgradeSeatsURL" parameter in the JSON response below is merely for display in the app and would not be enforced in any way by the app. The rejection of the font download is in the distributor's responsibility.
(I'm not sure if this whole part is even necessary, because fonts would always be available to download from the distributor's web sites. Maybe just displaying the licensing information in the app is enough. The API point could return the "seatsInUse" attribute together with "seatsAllowed" to bully, sorry, convince the customer to upgrade their license. The GUI would display an information about that.
Anyway, rejecting a download and requiring a de-installation from another app instance opens up the gates for trouble and frustration and customer support, because how do you find which computers the fonts are installed on?)
Also, removal of fonts from a customer's system would be lazy, as customers can make copies of the fonts, and also re-download them from the distributor's web sites anyway.
and return such information (I wrote this JSON by hand, just for illustration purposes):
{
"designers":
[
"yanone":
{
"name": "Yanone",
"website": "https://yanone.de"
}
],
"foundries":
[
"yanone":
{
"name": "Yanone",
"logo": "https://yanone.de/logo.png",
"website": "https://yanone.de/buy/",
"supportHotline": "+1-555-0123456789",
"supportEmail": "post@yanone.de",
"availablefonts":
[
"de.yanone.desktop.otf.NonameSans-Regular":
{
"familyName": "Noname Sans",
"styleName": "Regular",
"productName": "Desktop", # optional, thinking office fonts and such here, also see font's unique ID
"designers":
[
"yanone"
],
"description": "Sans serif linear Antiqua with classicist character",
"seatsAllowed": 2,
"seatsInUse": 5,
"upgradeSeatsURL": "https://yanone.de/upgradelicense/?APIkey=yqkejVUIkwoEc87s3AIR&id=de.yanone.standard.otf.NonameSans-Regular",
"license": "Yanone EULA",
"licenseURL": "https://yanone.de/EULA",
"versions":
[
{
"versionNumber": 1.0,
"versionInformation": "Initial Release",
"releaseTime": 1510748002
},
{
"versionNumber": 1.1,
"versionInformation": "Updated spacing and kerning",
"releaseTime": 1510748144
}
],
"image": "https://yanone.de/fontimages/NonameSans-Regular.png"
}
]
}
]
}
Individual fonts would then be pulled from a URL like this:
This would open one distributor to be able to distribute fonts of several foundries.
Which fonts the distributors include is in their responsibility. Could be free fonts, too.
A few questions:
Did I miss anything?
Should a font be removed from the app/system if it was included in the available fonts earlier but then removed by the foundry later?
Will the downloaded fonts need to be validated in a certain way to protect users? If yes, who knows how?
Which other security issues am I ignoring?
Do we have naming ideas for the app? It should be catchy, shouldn't it?
I have a generic logo idea, but I'm not showing it yet. Logo always needs to come first, right?
Comments
Even if I was still doing web-work, I wouldn't want my fonts swapped out upon a new version being available & served up.
I personally would not purchase fonts from a distributor who had their hooks into me & my computers and/or servers that deeply.
that issue could be prevented if the family name contains a version indicator of some kind.
in my mind no font should automaticly be replaced.
maybe a tray icon indicates that any of my fonts has a new version available
which then can be installed while keeping or removing the old one i would imagin.
Updates is one aspect of this proposal. The other is ease of installation after purchase, which is a big issue for every non-techie I've talked to so far. They just fear the installation of fonts, even though it's not really that complicated, but they do. People today want a just-works solution to everything, and I can't blame them.
https://dtptypes.com/software/fontload
Here is a demo from almost a year ago. https://www.youtube.com/watch?v=8PkUbHyEl54.
Maybe we could just use your app and figure out a CI system to just push fonts to a server. But key difference in what we aimed for is that we thought of font families as one package that you could install, instead of a font file level handling. Dose it make sense?
- In case where there is a beta release channel how would you handle it? For Example MyFontFamily could have multiple past releases and upcoming versions? Simply naming the beta versions MyFontFamilyBeta and listing them would work?
- I think auto updating should turned on or off per font file basis.
I will provide a very simple standalone Python server example for testing and understanding, but I don't think it makes sense to provide a general server solution because everybody needs to connect it to their own workflow, database, customers etc.
It could be left to the UI to install/update an entire family at once.
The proposal JSON reply at the top already suggests versioning of fonts. It would install the latest version initially and offer the option to revert to other versions, as well as to update to newer versions as they become available.
What names and version numbers you give your fonts should be of no concern to this software. It depends solely on your taste and how you communicate it to your audience.
However, I just included a "beta" flag to the specs for UI signaling.
I'll publish updated specifications soon. My ideas for this thing are getting a bit bigger, and need good planning.
Here’s an updated JSON response.
Many of the fields will be optional, so it's not a precise reference yet.
Interesting project! In our experience, we have had very little client support about installing fonts, almost none I can recall in the last 2 years. For me, the opportunity to deliver updated versions of fonts to clients is the most interesting aspect. That sounds pretty cool.
I wonder, what are the benefits of using an installed App, versus a web-App?
I must say, as a foundry, recommending clients to install a "third-party" App is not very appealing, much less than simply creating an account or logging on a website. It feels easier, less risky, but most importantly, more integrated with the foundry, which for me is a crucial aspect when you're an "independant" type foundry. It is one of the reason other models of type distribution through Apps put me off. It feels like giving away your brand for someone elses platform.
Also a website can be used universally and updated live, while updates for Apps must be downloaded and installed again.
This is just my 2 cents, in hope it's helpful/interesting feedback for you to see what others are looking for, not to question a solution that works for your needs.
Win-win is definitely part of the idea.
I don’t see how you can install fonts on your system through a web app. What do mean?
Browsers don't allow access to a computer other than traditional downloads, that you then need to put in the right places yourself.
That’s very true. I plan to cater to that by allowing for some branding through colors, logos and such. Let’s see how foundries are willing to adopt it. I have no expectations, but I want to give it a shot.
Which brings me to the most interesting idea that the app could update itself entirely automatically. I’ll see if that’s possible. But that just a technical side story.
Very interesting indeed. Thank you.
I think it works if the app is an integrated part of the process:
Checking out fonts on a foundry's website > buying the fonts > getting the app > installing the fonts.
Would it be possible to notify for updates on variants of the purchased fonts (that would not replace the original font), things like that, or only for the exact same name?
I realize I'm a bit off regarding your purpose but I'm really curious about that, I think it's one of the aspects that's not been well explored by type design and that with current developments would make sense to try.
Still with the idea of betas in mind, I can imagine wanting to deliver alternative versions of already distributed betas; variants exploring different solutions that are not destined to replace the original, but to allow the user to test/compare different versions.
I know this is not the original goal, just thinking ahead.
And sorry for being unclear.
I know this is not the original goal, just thinking ahead.
I believe there is a strong need for metadata about fonts which is not contained in the fonts themselves; and I think trying to put such metadata inside fonts is unwise, mainly because it changes over time, and isn't the same for all users.
As I understand it, but as I hope those not yet de_epar_ted who were directly involved can correct me A while back the EPAR/EEULAA proposal did the rounds at ATypI and elsewhere, but it got stuck because Microsoft wouldn't include such an SFNT table in the OpenType specification. I made an effort to archive the proposal document and secure a libre license for it, at davelab6.github.io/epar, because I think the thinking there is valuable. I think your API specification could benefit from many of the key/values proposed there
There are a couple of other font metadata database projects already with different vectors to EPAR - fontsinuse.com is to me clearly the best, typedia.com also good, surely there are others.
A desktop syncing and installing app like yours can provide a local cache of such metadata for all fonts installed in the system, and a local API for desktop applications to access it, complementing web access both via API end-points and the commonplace browse-able websites which they will complement.
I've heard good things about Kivy, if you want to go "fancy"
I believe @Adrien Tétar is, after long experience with PyQt, now a fan of wxWidgets.
But I reckon PyGUI would be ideal for starting out as I believe it is the most simple. As below, if you frame your implementation as a 'reference implementation' and expect font managers to adopt your protocol, then any shortcomings in pyGUI can be forgiven
I think the releases feature on Github is very nice.
However, what you didn't mention so far is what license you have in mind for your work, and really that should be determined by what your end goal is... ubiquity or density
If you want to make a protocol that all font mangers and sync tools adopt, and provide them with a reference implementation, then I think a non-copyleft license makes best sense: It allows people making font managers to directly pick-up and re-use pieces of your code in their own proprietary implementations. In this case, I would recommend the Apache license over MIT/BSD because of the patent protections.
If you want to attempt what MBAs call a "dominant strategy" and become the best, where instead of splintering into 1,000 implementations (including all the existing ones) you create a single one that is the best and has gravity (like WordPress, Samba, MediaWiki, Mailman, etc), I recommend the GPLv3.
Yep a custom URL protocol is super nice, I think, as that is what makes the integration with sales-cart check-out pages seamless A simple secret key sounds good to start; users could also be authenticated via OAuth (which has many popular providers including Google, Microsoft, Facebook, Twitter and Github) or by full-on public key authentication (which is not so bad to deal with these days, like users do to use ssh:// URLs on Github itself)
Its always important to consider the user when specifying features
And some users really want this feature, and pay for it - this is what the Extensis server product does; tracking font installations for organizations who proactively comply with their per-seat font licensing.
Font removal is a desired part of this, to then add on another computer, staying within the permitted limits. Yep, the desire for this is already demonstrated by Monotype marketing SkyFonts on its ability to manage local de/installation and updates to Google Fonts
But there are other libre font collections (Open Font Library, and various oFont sites such as velvetyne.fr) which like independent foundies have their own dedicated followings. I myself would want to know that a foundry has discontinued a font for me, but I would not want the program to disobey me or do anything without my permission.
Complying with EULAs is my responsibility, and enforcing license terms is "anti feature" DRM. Smells bad
As @Mike Wenzloff said, retaining control of versions is very important; but like when a UFO-centric tool says "Your UFO was updated out from under me... what do to about it?" I think its also important to make it easy to review and say "yes to all."
I think you can rely on underlying operating systems for validation to protect against malicious fonts; you could run the validator used by Chrome and Firefox, OTS, as additional safeguard, but I know that a lot of desktop fonts don't pass OTS so this might be good as INFO or WARN rather than ERROR I think generic is good: "Font Sync" or "One Click Fonts" etc Same as what happens with you have SkyFonts installed and browse https://www.fonts.com/web-fonts/google and click "install" Its not just the initial installation that is inconvenient, but the constant need to check for and re-install updates.
I understand from @Bruno Maag 's many conference presentations that this is especially important for type designers who supply custom commissioned typefaces, where the client is closely involved in providing creative direction and feedback, and has lots of versions of "their" font floating around; these pre-release betas can be floating around customers for years afterwards, causing annoying "we already fixed that" bug reports, so restricting their availability is something he advises. Kindly I disagree. If you have a restrictive license, user trust is diminished, and it won't stop anyone from getting at the font files in their computer anyway, if they want to. Users who choose to use fonts under restrictive licenses know that they have to comply with the T&Cs, and if they are using a font on a trial basis, and they have 2 font managers to pick from, one that says when a trial expires "your trial has expired, should I uninstalling the font now? [Y/N]", and one that says "your trial has expired, I already uninstalled it," which is the user going to prefer?
Indeed, @Bruno Maag 's demo fonts don't have an expiry date; I think this is wise, because such limits are annoying, and annoying your customers is never a wise business decision.
Nor are any of the other font sync tools or font managers.... So I guess the custom type market is really underserved by them, despite that they have a lot of capital sloshing around to invest. Good luck approaching some of the people most likely to benefit from your project for some seed capital
https://developers.google.com/fonts/docs/android
https://developer.android.com/guide/topics/resources/font-resource.html
https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml.html
https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts.html
I’d also like to suggest keys for “source URL”, “issue tracker URL”, and “support Email”, since many libre fonts have these and users want to know them
https://msdn.microsoft.com/en-us/library/windows/desktop/mt492448(v=vs.85).aspx#creating_a_custom_font_set_using_known_remote_fonts_on_the_Web
Dave's links to the font-resource and fonts-in-xml pages mention use of a font within the app package. That's been supported in Windows app packages since Windows 8. The main difference is that Android allows you to designate font files as a distinct "font" resource type, whereas in Windows they are just binary file assets. (They can be embedded into the package resource index (.pri) file rather than loose.)
Downloadable font support is new in the latest Android release. We had support for downloading fonts from a Windows library in the first Windows 10 release, and added support for downloading fonts from any cloud font service in the Windows 10 Creators Update (spring 2017).
The interesting things that Android has done are (i) to be able to incorporate a downloadable font in an app by making a declaration in the app manifest, and (ii) explicit handling of certs.
3)
4)
I lean towards 1), as it is cleaner to implement in the API and also in the GUI app.
Next to your reply here, please also vote in this tweet, thank you: