Font personalization is storing customer-specific or transaction-specific information inside a font file.
This can be done manually, by a foundry making a custom version of a font. More interestingly, it can be done automatically by systems at the point-of-sale.
Items that are under discussion for inclusion:
* Serial number: for example, font number 345 that is purchased in order number 789 from YourFonts.com could be encoded as the text “YF789:345”; a simple integer could also be used. Fonts that contain serial numbers are sometimes called serialized fonts
* Licensee name: person and company
* Date of license purchase
More detail is available on the Personalization Fields page.
Font personalization is not strictly part of the need for EULA abstracts. However, the technology that offers foundries and distributors a way to store specific EULA abstracts inside fonts is very similar to that needed to personalize fonts in this way. It would also necessarily be part of any system that stores EULA abstracts on a foundry’s or distributor’s server, rather than inside the font.
Implications of each licensed font being a different file
The same font licensed by two different customers will now have some differences. Systems that rely on identifying fonts, or validating fonts, by methods that depend on identical font files will break with serialized fonts, and must be updated to allow differences in certain parts of the font file.
Comment from David Lemon: A leading rasterizer and security expert assures me that comparisons which allow differences in any part of a font file cannot guarantee that the output of two fonts will be identical. For this reason, customers who are concerned about output fidelity must embed personalized fonts in order to achieve it.
Systems that may break with personalized fonts:
- All simple file comparison schemes
- Apple FontSync?
- DiamondSoft Font Sense?