Howdy, Stranger!

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

Best Of

  • Re: Naming font modifications

    This may be a bit pie-in-the-sky, but I wonder if all this discussion is a symptom of a broader problem about updating and revising fonts. And a related issue is that the difficulty of updating and revising fonts leads to a situation where fonts do take ages to develop and release because this can't be done iteratively and bug fixes can't be easily fielded.

    Let's imagine a situation where, when you install a font, the OS's font manger checks to see if the font is already installed. If it isn't already installed, no problem. If it is already installed, it compares the glyph outlines, coverage and metrics with the previously installed font, and makes the following determinations:
    • Is the new font a superset of the old? Does it merely add new glyphs, without changing existing ones?
    • Does it change the metrics of existing glyphs or global font metrics? If so, warn the user that this could cause document reflow.
    • Does it change the outlines of existing glyphs? If so, warn the user that the font will be visually incompatible.
    Having determined the nature of the update, you can now offer the user a choice:
    • Cancel the install
    • Overwrite the old font
    • Rename the old font
    • Rewrite the name of the new font to add a custom suffix. ("FooFont for SomeClient Project 2017-05")
    We are far from that situation at the moment but it's technically possible; wouldn't it fix most of these issues?
  • Re: [OTVar] Changing tracking/HVAR

    Thanks, Peter and Laurence.

    I did some more tests and it seems that indeed it is enough to store one point delta per contour plus the RSB phantom point delta for each glyph. The rest of the points follows along.

    I’ll see if this could be an automatic optimisation in varLib, though it is probably a rare case. If the proposed spacing axis is widely used, it could be built into a font without preparing separate TTFs that would have to be optimized again. It would be easier to make a separate script that could apply this kind of spacing modification to any font.
  • Re: OT Sub Prioritisation (Need Help)

    Try putting the l_l substitution in a separate lookup before the i_l lookup.
  • Re: OT Sub Prioritisation (Need Help)

    set the first line of your feature to:
    sub i l' l' by l_l;
    The order of the substution rules does matter, and you need to define the longest substitutions first.
  • Re: Marking Copies of Fonts

    We tag our web fonts. The order number is included in a namerecord similar to how Font Squirrel does it.

    We've found it useful for checking to see if a website is using a properly licensed font, or for diagnosing font problems (i.e. customer made some dumb modification and now the kerning is gone). 

    We don't tag our desktop fonts, but I wish we did. I can think of several times where being able to verify the legitimacy of a license, or even knowing an approximate date when the font was issued, would have been very helpful. 

    Slightly off topic: I LOVE that FontForge and Font Squirrel include breadcrumbs in the fonts they produce. Being able to crack a font and see that it's been modified is super helpful for tech support. 
  • Re: Marking Copies of Fonts

    One cannot practically do that with a font. With fonts it is more like trying to find who removed the proverbial needle in the haystack after it has been found and moved elsewhere. Unless a license holder admits to releasing a font in the wild, it would be incredibly difficult (impossible) to identify the perpetrator.

    Again, and as I said, serialisation is not about identifying a 'perpetrator' responsible for distributing a font illegally. It is about being able to say to someone using the font 'Excuse me, but this font is not licensed to you. Please pay for a license.'
  • Re: First font license

    I think the problem of a EULA is that most EULAs are written in English which presents a problem for a majority or users. No? I agree that being as explicit as possible is good, but I also agree that erring on the side of restrictive is good for business. When you err on the side of restrictive you can always make case-by-case exceptions for clients who reach out to you with specific needs. But if you err on the side of less restrictive you will find it difficult to back track.

    Additionally make the user feel that they can reach out to you if they need questions answered. 
  • Re: First font license

    Be aware it's always best to err on the side of more restrictive EULA than less restrictive one as customers always assume with rose colored glasses, if something isn't expressly restricted it must otherwise be granted. Feel free to look at our EULA for ideas of things you may wish to consider restricting:

  • Marking Copies of Fonts

    Suppose a foundry marks each copy of the fonts it ships to clients with some unique key buried somewhere in the metadata, such that if an illegal copy is found, it's possible to trace its source.

    Have you ever heard of something like this?
    Do you think this would be a good idea?
  • Re: Too much overshoot?

    Thanks, I'll play with the width too.