-
Notifications
You must be signed in to change notification settings - Fork 62
Home
SFNT-based font files (OpenType/TrueType) contain a name table which can contain several fields identifying the font. The most important of those being 'fontFamily', 'fontSubfamily', 'fullName' and 'postScriptName'
Fonts on the adobe server almost always have an incorrect 'fontFamily' value, where they will contain not only the font family, but also sometimes some truncated text similar to the fontSubFamily. This Causes two problems:
- Fonts do not group together correctly. Instead of having styles associated with each font family, you have several different font families, each representing a distinct style.
- The truncated fontSubFamily text will sometimes not be unique across all the different font files on the server. For example, you have have two fonts in what you would expect to be in the "Helvetica" family, whose full names are "Helvetica Thin" and "Helvetica Thin Italic" - but the fontFamily for both of these fonts may be "Helvetica Thin" and "Helvetica Thin", so when you try to install both fonts, one is overwritten, as your system thinks they're the same font.
A simple solution would be to read the fonts using opentype.js, modify the name parameters, then encode them back to an OTF file and save. This would be great, except opentype.js does not support many of opentype tables featured in many of the fonts on Adobe Fonts, specifically many non-english alphabet fonts.
We can, however, bodge together our own solution using opentype.js that does not require reading these extra tables at all.
OpenType.js allows us to "parse" and "encode" a name table from a uint8array. So all we need to do is manually parse the table directory table of the font file, find the offset and length of the head table, then parse that chunk of data as a name table. From there, we can modify the output data as a standard dictionary object, and re-encode it back into a uint8array when we're finished, inserting it back into the raw font file data. After that, we need to update all the offsets in the font file to account for the new data, update the name table's checksum, then re-calculate the entire font file's checksum.
A proof of concept of this is on the FontNamesAdjustment branch. It works for several fonts, but for others it seems to be breaking.
Currently, the issue appears to be when I attempt to re-align the font file by adding padding zeroes to the end of the file such that file.length % 4 == 0, which is required of the checksum algorithm. For fonts that are not already aligned, this padding operation causes the checksum to be wrong.
https://github.com/HinTak/Font-Validator/
This tells you everything wrong with a font file as well as warnings about potential issues.