Proposal for font distribution/installation app
yanone
Posts: 130
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 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.
Such an API point URL could look like
https://yanone.de/installfonts/?APIkey=yqkejVUIkwoEc87s3AIR
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?
3
Comments
-
I received some feedback outside of this forum where the above proposal is perceived as being for distributing beta fonts to clients while they are being developed. And that's possible, but just to be clear, the main use case is:One-click installation of fonts after purchase.2
-
Most of my income comes from layout work and so the below is really from that perspective. It is a must that I retain the font versions used in the production of said work. (A new version can cause reflow, line spacing issues, etc.)
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.3 -
@Mike Wenzloff
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.
0 -
Automatic updates should be optional. Otherwise, available updates would be notified to the user, like Thomas Helbig said. And they could switch back to older versions, if they wanted to.
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.1 -
I can't really distill the user experience of the end user from the proposal. I click the "Buy" button on a distributor's site, pay, and instead of getting a link to download the font, what happens? The end goal of the application would be to prevent end users from having to be explained the font needs to be downloaded and installed through regular OS methods? Is that correct?0
-
I guess you’ve already had a look at Skyfonts? It seems to handle a lot of what you’re saying. It’s obviously aimed more at individual end users so I don’t know that it handles seat/license count tracking, but for ease of use it’s superb. Click on the web link and you have a new font installed.0
-
An open source app has undeniable advantages. But if you like to implement any security features (e.g.: for trial versions) it would be better to have some closed source part.0
-
@Roel NieskensBy the time I realized that the proposal upstairs is too technical, it was too late to edit
Sorry.I see the "Install through [insert app name]" button offered as a service by foundries next to traditional font download methods, not as a replacement.Otherwise, yes, users will not have to be required to understand how to install fonts.The app will look rather handsome and will of course be easy to use.I've talked to a few casual font users in my vicinity and they're surprisingly horrified from the font installation experience. They don't understand fonts, so they're also scared of their installation, never remember, where they've installed them (referring to the Adobe font folders next to the system folders), etc.@Simon CozensIndeed, Skyfonts works. But I'm more looking for a solution that everyone (independent foundries) can benefit from and not lose 50% of their value to the corporation.It will have a very low participation threshold, as all you need to do as a foundry is to set up the API on your server. (Will require general web development skills, no rocket science).And then, Skyfonts is not open for beta font distribution or workgroup distribution.2 -
I love this! @Pathum Egodawatta has been interested in this for a while.0
-
I have something called FontLoad so that anyone can try out our fonts as trial versions.
https://dtptypes.com/software/fontload
2 -
This is awesome. I've been working on a proposal and demo that address the same issues but with more focus on frequent updates to Libre fonts using GitHub as the primary infrastructure. We planned it with modules for different Git service providers. But this would eat resources when number of families increase and when the client has to check multiple sources for updates. Your approach for elegant. We
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?
yanone said:And then, Skyfonts is not open for beta font distribution or workgroup distribution.
- I think auto updating should turned on or off per font file basis.
0 -
Everybody needs to write their own server.Pathum Egodawatta said:
Maybe we could just use your app and figure out a CI system to just push fonts to a server.
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.Putting out JSON is simple enough.Pathum Egodawatta said:
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?
It could be left to the UI to install/update an entire family at once.Customers of commercial fonts tend to buy just a few fonts out of a bigger family, so that needs to be catered for.- 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?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.
0 -
I broke down the idea into parts and will really only focus on the font installation for now.
Here’s an updated JSON response.
Many of the fields will be optional, so it's not a precise reference yet.I will go on to implement a test server and a validator, and only afterwards go about implementing the UI app. Anyway I chose Kivy as a Python GUI framework, as it also support iOS and Android, just in case.{<br> ### General information about the API endpoint<br><br> "canonicalURL": "https://yanone.de/api/", # used to group fonts in case of multiple URLs from same API point<br> "adminEmail": "post@yanone.de", # Contact in case of technical problems with the API point<br> "supportedCommands":<br> [<br> "downloadableFonts",<br> "installFont",<br> "uninstallFont" # optional, only if distributor wants to track installations<br> ],<br> "name": "Yanone",<br> "public": true, # possible future use. Default: false<br> "logo": "https://yanone.de/logo.svg",<br> "website": "https://yanone.de/buy/",<br><br><br> ### Font data returned for the "downloadableFonts" command<br> "designers":<br> [<br> "yanone":<br> {<br> "name": "Yanone",<br> "website": "https://yanone.de",<br> "description":<br> {<br> "en": "..."<br> },<br> }<br> ],<br> "foundries":<br> [<br> "yanone":<br> {<br> "name": "Yanone",<br> "description":<br> {<br> "en": "..."<br> },<br> "logo": "https://yanone.de/logo.svg",<br> "website": "https://yanone.de/buy/",<br> "twitter": "...",<br> "facebook": "...",<br> "instagram": "...",<br> "telephone": "+1-555-0123456789",<br> "email": "post@yanone.de",<br> "skype": "...",<br> "hangout": "...",<br> "licenses":<br> {<br> "desktop":<br> {<br> "name": "Yanone EULA",<br> "URL": "https://yanone.de/EULA",<br> }<br> },<br> "fontFamilies": <br> [<br> [<br> "name": "Noname Sans",<br> "description": <br> {<br> "en": "Sans serif linear antiqua with classicist character"<br> },<br> "billboards": [<br> "https://yanone.de/fontimages/NonameSans_1.svg",<br> "https://yanone.de/fontimages/NonameSans_2.svg"<br> ]<br> "designers":<br> [<br> "yanone"<br> ],<br> "versions":<br> [<br> {<br> "number": 1.0,<br> "information":<br> {<br> "en": "Initial Release"<br> },<br> "releaseTime": 1510748002<br> },<br> {<br> "number": 1.1,<br> "information":<br> {<br> "en": "Updated spacing and kerning"<br> },<br> "releaseTime": 1510748144<br> }<br> ],<br> "fonts":<br> [<br> "de.yanone.desktop.otf.NonameSans-Regular": # font ID unique to one publisher<br> {<br> "type": "desktop", # predefined list, like webfonts, app fonts etc. Will be used for seat tracking in case of desktop font, and installability (only desktop fonts can be installed), all other font types can be downloaded and made available to the user easily, but not installed<br> "styleName": "Regular",<br> "postScriptName": "NonameSans-Regular",<br> "image": "https://yanone.de/fontimages/NonameSans-Regular.png",<br> "productName": # optional, thinking office fonts and such here, also see font's unique ID. Used for UI.<br> {<br> "en": "Desktop"<br> },<br> "license": "desktop", # foundry's license key (of "license" attribute at tree root)<br> "free": false, # UI signalling of freeware font<br> "beta": false, # UI signalling of BETA font<br> "public": false, # If false, signals restricted access to a commercial font only available to certain users. Download and installation may be restricted by the API point depending on the API point URL that needs to include the private key to identify the user. Default: true<br> "seatsAllowed": 2, # number of installations permitted by the license<br> "seatsInUse": 5, # used in UI to signal users to upgrade their licenses, if seatsInUse exceeds seatsAllowed. Can be tracked through "installationID" parameter in "installFont" and "uninstallFont" commands<br> "licenseAllowanceDescription": # custom string for web fonts or app fonts reminding the user of the license's limits, in case font is not a desktop font<br> {<br> "en": "100.000 page views/month"<br> },<br> "upgradeLicenseURL": "https://yanone.de/upgradelicense/?APIkey=yqkejVUIkwoEc87s3AIR&id=de.yanone.standard.otf.NonameSans-Regular", # button where users can easily reach an upgrade website<br> "purchasedTime": 1510748144, # UI signalling of fonts purchased less than one week (?) ago<br><br><br><br><br> # Future use, requires closed-source compiled software component<br> "trialAvailable": false, # future use. Publisher offers trial of this font, will be removed after certain time<br> "trialTimeAllowance": "60m", # future use. Duration of trial period<br> "trialTimeReset": "30d", # future use. Time after which trial allowance will reset,<br> }<br> ]<br> ]<br> ]<br> }<br> ]<br>}0 -
Hello yanone,
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.
0 -
Professionals know their craft. Amateurs don't. They could greatly benefit from one-click solutions, and participating foundries would benefit from that in turn.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.
Win-win is definitely part of the idea.I wonder, what are the benefits of using an installed App, versus a web-App?
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.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.
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.Also a website can be used universally and updated live, while updates for Apps must be downloaded and installed again.
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.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.
Very interesting indeed. Thank you.0 -
I guess I thought it would be possible to install fonts through a web-app as well, but you're probably right
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.
0 -
Exactly. After purchase you would place a "Install through [insert app name]" button on your website (next to your traditional download methods), with a download link to the app close by. And of course customers need to install the app only once, even for other foundries. So if the thing catches on and users already have it, it's really just a one-click thing (two clicks in reality).ybaggar said:
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.1 -
And the app only displays a list of fonts purchased? No list of foundries or whatever?
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.
0 -
And the app only displays a list of fonts purchased? No list of foundries or whatever?The options are plentiful. The amount of data the app can work with relies directly on how much data foundries want to make available. An API can be a powerful tool.Let's start with purchased fonts and make them installable, because that’s an immediately useful assignment, then see where the journey takes us.Would it be possible to notify for updates on variants of the purchased fonts (that would not replace the original font), things like thatThis sounds interesting, but I don't understand what you mean by "variants of the purchased fonts".0
-
The options are plentiful. The amount of data the app can work with relies directly on how much data foundries want to make available. An API can be a powerful tool. Let's start with purchased fonts and make them installable, because that’s an immediately useful assignment, then see where the journey takes us.
I guess my "worry" is that a one-click font installation/management app, could easily turn into a font promotion/distribution app. I'd argue there is a fondamental difference.This sounds interesting, but I don't understand what you mean by "variants of the purchased fonts".
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.
0 -
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.The user can download and install whatever you provide for him/her. So if you feed him multiple variations of your fonts, that's entirely up to you. The tool just provides the channel.
I know this is not the original goal, just thinking ahead.0 -
Thanks for the answers. I'm starting to get a better understanding. More (quite some) programming needed from the foundry, but quite some possibilities too. Interesting!
0 -
I wonder if Monotype Skyfonts client will consume this API 0
-
(Sorry this is somewhat stale, I am posting stuff I drafted earlier... Also this is all my personal opinion, not the views of anyone associated with me including my employer
This is a great idea - and since you need to supply metadata along with font files, it is approaching a general area from the opposite side of a project I have long pondered, which is to not supply font files, but only that font metadata, by itself - like musicbrainz.orgyanone said: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.
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 would program it in Python using a cross-platform GUI library such as pyGUI (recommendations welcome)
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 and host it on Github
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 seamlessEach 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)
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)The API point would accept a customer-specific API key parameter that would limit the available fonts to the purchases of that customer.
Its always important to consider the user when specifying featuresAnyway, 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?)
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 FontsThis 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.
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.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?
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 ERRORWill the downloaded fonts need to be validated in a certain way to protect users? If yes, who knows how?
I think generic is good: "Font Sync" or "One Click Fonts" etcDo we have naming ideas for the app? It should be catchy, shouldn't it?
Same as what happens with you have SkyFonts installed and browse https://www.fonts.com/web-fonts/google and click "install"Roel Nieskens said:I can't really distill the user experience of the end user from the proposal. I click the "Buy" button on a distributor's site, pay, and instead of getting a link to download the font, what happens?
Its not just the initial installation that is inconvenient, but the constant need to check for and re-install updates.The end goal of the application would be to prevent end users from having to be explained the font needs to be downloaded and installed through regular OS methods? Is that correct?
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?Georg Seifert said:An open source app has undeniable advantages. But if you like to implement any security features (e.g.: for trial versions) it would be better to have some closed source part.
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.yanone said:
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 capitalAnd then, Skyfonts is not open for beta font distribution or workgroup distribution
1 -
Great! Android now has a “downloadablefonts API”yanone said:
I will go on to implement a test server and a validator, and only afterwards go about implementing the UI app. Anyway I chose Kivy as a Python GUI framework, as it also support iOS and Android, just in case.
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 1 -
@Dave CrosslandThanks for all the remarks. Need some time to dig through them.I already have "support email". What do you mean by "source URL"?Regarding framework, I'm currently eyeing wxPython. Kivy is massive, but I couldn't even get the simplest things running like a dock icon badge for available new fonts. And it can't display SVG, wtf. I have to take another look at Qt, though, as it also supports mobile platforms.1
-
As has Windows 10 had.Dave Crossland said:Great! Android now has a “downloadablefonts API”
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.
1 -
Eg, for Montserrat it is https://github.com/JulietaUla/Montserratyanone said:What do you mean by "source URL"?
Sorry to hear Kivy sucks, I'd heard good thingsRegarding framework, I'm currently eyeing wxPython. Kivy is massive, but I couldn't even get the simplest things running like a dock icon badge for available new fonts. And it can't display SVG, wtf. I have to take another look at Qt, though, as it also supports mobile platforms. 0 -
I have a functionality question to everyone:When specifying versions of fonts in the API resonses, what would be the better approach:1)Specifying versions at the root of the font family data, and also specifying fonts (the members of the font family) at the root of the font family data.Here, fonts and versions are siblings.Then, it is expected that all fonts are available in all versions, so the total amount of available fonts is a multiplication of the fonts and the versions.2)Specifying fonts, and versions as children to the fonts. This way, out of a family, only some fonts could receive an update and others not.
3)Specify versions and fonts as siblings at the family root, then allow inconsistent referencing of versions in the individual fonts.
4)A wild mixture of the former three, allowing for possible erroneous duplicate version specifications at the font as well as at the family level.
I lean towards 1), as it is cleaner to implement in the API and also in the GUI app.In 2), when versions of fonts are inconsistent within a family, how do you update an entire family at once in the GUI, or go back in versions conveniently?In 1), when all fonts are expected to be present, API endpoints could still decide to return older versions for newer version number requests, but that's equally messy.The problem is that this will inevitably influence how type publishers go about their releases, and I don't want to do that. Another option would be 3), which would allow for both consistent as well as inconsistent releases, while saving data in the API response.But then, if you bump just a few fonts of the family to a new version, and then later bump the entire family at once, this means that some fonts will need to skip a version. And while that's technically possible, this is exactly how the system would influence publisher's work and versioning habits, and it should cater to all approaches.So it all depends on how you people go about your families.Are fonts usually consistently updated across the whole family?
Next to your reply here, please also vote in this tweet, thank you:1 -
Here’s the object model that I’m currently implementing.Maybe someone has an opinion about it.The designers are implemented at the root of the response, not at the foundry level, because one designer can be involved in several typefaces across several foundries. I think this reflects the most commonly used data models.After rethinking the versioning and collecting the votes, 25% of which currently voted for inconsistent versioning, I can only imagine to attach versions to both the font families as well as the fonts to allow for maximum flexibility, and then calculating the versions for each font from whatever data is available. However, some version information will have to present at either location, and the validator will complain when it isn’t.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports