Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

yanone

About

Username
yanone
Joined
Visits
594
Last Active
Roles
Member, Type Person
Points
60
Posts
78
  • Re: Proposal for font distribution/installation app

    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: 
  • Re: Proposal for font distribution/installation app

    @Dave Crossland

    Thanks 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.
  • Re: Proposal for font distribution/installation app

    @Roel Nieskens
    By 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 Cozens
    Indeed, 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.
  • Re: Proposal for font distribution/installation app

    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.
  • Proposal for font distribution/installation app

    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?