Archive for December, 2016

Deprecated vs. discontinued

Sometimes a particular app or utility we offer gets old, and we have no intention of updating it, generally because of lack of customer interest, or because we have a successot. Discontinued programs we do not promote at all, have no web page for, and do not appear in our regular store (FontFlasher, FOGlamp). Deprecated ones we have no current intention of updating, label the web page as such, but do still have a page for and store presence (ScanFont, BitFonter).

Mostly, we discontinue: just remove those product pages and discontinue the product entirely. I have done this with a number of things we have offered, such as FOGlamp (it converted Fontographer native files directly to FontLab Studio — no longer needed because newer versions of FontLab Studio just open those old FOG files). In such cases, if you desperately need it for some reason, contact our sales department and they may be able to hook you up.

But sometimes a product has a peculiar combination of attributes:

  1. It wasn’t selling enough units that it makes sense for us to update it or make a new version.
  2. Some people who want it or need it have no reasonable other alternative. Maybe any competing products don’t have the same features, or are not offered on the same operating systems. Or they just do not exist!

So, we keep web pages live for these programs and sell them, because we know a few people really need them. We also label them as deprecated. What does that mean?

  • We have no current plans to create a new version of this product. (Some or all functionality from this product might be folded into something else.)
  • Support for this app has some limitations. We still try to support it, but if there is a problem that is a known bug… well, there may never be a fix. Our expertise/ability to support it will likely be in a gradual decline.

Mac-specific issues for deprecated apps:

  • In some cases (BitFonter, ScanFont), the Mac version of this product no longer runs on any recent MacOS, and our solution for Mac users is to bundle the Windows app in a WINE wrapper. This makes a larger app that is running the Windows version under emulation, on a Mac.
  • Generally, the Mac version of the app has not been updated to be “retina savvy.” This means that on any recent Mac hardware with a double-res “retina” monitor, the app will still work, but some elements of the app will run at half that resolution and seem blurry. This can be worked around to some degree by running your Mac in a higher but non-retina screen resolution, but that is a compromise between blur and things getting smaller. If you run at full resolution but non-retina, everything will be very crisp but half-size. A utility such as QuickRes or DisplayMenu can help give you more choices for non-standard Mac resolutions. (Note: Even some of our non-deprecated apps are not retina-savvy. I will have a separate post about this soon.)

Encoding choices for symbolic fonts

Sometimes people make fonts that don’t have letters and such in them, but instead have some kind of symbols.

In many cases such symbols have legitimate encoding slots in the Unicode standard, which is used to dictate encoding for most fonts made today. But working with unusual characters from Unicode can be a bit of a pain. So sometimes people assign unusual symbols to the same slots as A, B, C, etcetera. This is technically wrong, but often convenient.

Here is a quick guide to the options and tradeoffs when creating a symbol or “pi” font. This advice is applicable across all font creation tools, not only ours.


  1. Use “proper” Unicode codepoints for all glyphs in your font. This means looking up correct Unicode codepoints for the symbols. 
    • Disadvantage: People won’t be able to type the symbols directly, unless you create custom keyboard drivers for your font. Likely they will need to use a character picker built into their OS or app.
    • Advantages: If they switch fonts to another one that has the right symbols properly encoded, their content will remain correct. Unicode/text purists won’t complain.
  2. Use “normal” codepoints for your symbols, so that your symbols are assigned to a, b, c, 1, 2, 3, etc. 
    • Disadvantage: If people switch fonts, the symbols will turn into alphabetic gibberish, and it may not even be apparent what was intended. Also, that alphabetic gibberish really is the underlying text, so this approach will confuse screen readers, search, and other things that rely on understanding the text. As a result, it is considered technically “wrong.”
    • Advantage: Can by typed off the keyboard!
  3. Use Private Use Area Unicode codepoints. These are codepoints reserved for special purposes, that have no pre-set meaning. 
    • Disadvantages: Has all the disadvantages of using proper Unicode, plus most of the disadvantages of of assigning the symbols to alphabetic codepoints
    • Advantage: usually none, unless others have used these PUA codepoints in some consistent way.

How to Choose

Personally, if the font is going to be used to create public documents and text, I will tend towards option #1. If nobody is going to need to manually enter text using the font, or not often, I will tend towards option #1, If neither of those things is true, and the content will have more limited use or be in a closed system, I will tend towards option #2.
What if your symbols don’t even have proper Unicode codepoints? In that case, the first option is unavailable to you. You might consider whether there is a semi-standard solution being used for those symbols (for example, there is a block in the Private Use Area that has often been used for Klingon).
Thanks to the user who wrote me the question that prompted this blog post!

FontLab VI ship update

For the latter part of last year, and all this year, we have been expecting and saying that FontLab VI would ship, well, “this year” (2016). But we are not going to make that, as became clear to us earlier this month. Instead, we currently expect to ship in February.

FontLab VI in action

FontLab VI in action (click for full size)

We could have hurried up with the last couple of things and “just shipped it.” But anybody who has used software a long time knows what that will do — FontLab VI just needs more “bake time.” That is, time for us all continue to give it a real workout, doing extensive and ongoing type design tasks, so we can find and fix a bunch more bugs and usability issues before we ship it.

We continue to make prerelease builds available, and even more frequently! Another one just came out on December 15th. If you already have a Public Preview build on Mac or Windows, just launch it and it will prompt you to download and install the newest built. If not, you can register and get emailed a download link from our Preview page. When you find problems in the Public Preview, please report them in our user forum! We appreciate your help and feedback in making this a better app.

FontLab VI, like previous versions, is a very flexible tool that can be used in many ways. That means it has many possible workflows. This is great, but means the app will really benefit from feedback from real-world users trying real-world tasks. Not just us doing things the way we would do them.

We really want to make FontLab VI a great tool for type designers and font friends everywhere. Thanks for your support.