Automating PANOSE data

John Hudson
John Hudson Posts: 3,230
edited December 2015 in Technique and Theory
Putting accurate PANOSE classification data in a font involves doing a lot of detailed measurement of individual glyphs and then calculations based on those measurements. This is news to a lot of font developers, who either guess at PANOSE classifications based on the descriptive names used in the system, copy PANOSE data from a similar font (which might also be inaccurate), or simply don't bother to attempt PANOSE at all, setting most values to 'Any'.

PANOSE is, as a result, a technology that is unreliable for the thing that it was designed to do: font matching and substitution. Leaving aside, for now, a number of issues — the significance of font matching in various circumstances, the failure of PANOSE to accommodate non-Latin fonts, etc. — I'd like to consider whether it might be possible to automate the process of defining accurate PANOSE information for a font.

Before jumping into this discussion, I strongly encourage people to read the PANOSE Classification Guide (currently maintained by Monotype). It's important to understand how PANOSE is designed and how the measurements and calculations apply (although this is not to say that the only way to approach automation would be to directly script performance of those measurements and calculations).

Comments

  • James Puckett
    James Puckett Posts: 1,998
    The problem with automatic PANOSE values is that there are enough possibilities that a computer is almost guaranteed to make a mistake. So somebody who knows PANOSE in and out has to review every decision the computer made. In that case the values might as well be determined manually. Which takes us right back why almost nobody uses PANOSE—it’s too much both for something 99% of graphic designers are not aware of and would probably never use if they did know about it.
  • Georg Seifert
    Georg Seifert Posts: 674
    I think the only sensible way would be better documentation and build on top of it a step by step guide.
  • Kent Lew
    Kent Lew Posts: 944
    John — David Jonathan Ross made a stab at some automated PANOSE calculating a few years back for the FB toolkit, working very hard to interpret the guide. As I recall, it did a half-decent job. But in the end, we wound up setting this aside in actual production because of various performance anomalies, the precise nature of which I don’t recall offhand (but which I suspect were related to the sorts of things Nick alludes to).

    Obviously, I’m not at liberty to share his code, but you could contact him privately if you wanted to find out more details about his attempt.

    The system seems to be plagued from both sides — overly complex & confusing to set on the one hand, and inconsistent (and downright buggy) interpretations/implementations on the other.

  • PabloImpallari
    PabloImpallari Posts: 806
    edited December 2015

    Panose is getting some extra attention these days, because of the renewed interest in parametric fonts. From PANOSE V2 data (not the 10 digits "bucket" system, that is PANOSE V1), Infinifont can generate parametric fonts:

    "The Infinifont Font Engine is a software virtual machine that executes a sequence of special instructions for manipulating font constructs, including points, Bezier curves, and hints.

    The PANOSE file input to the font machine must at least include a minimal set of measurement data, such as a PANOSE number, which can be used to compute global variables representing typographic characteristics common to all of the glyphs in the font. Additional global variables, and local variables needed to capture nuances of individual characters, can then be computed or assigned default values by the Font Engine.

    Metric data embedded in the PANOSE file can be used to coerce the individual characters into predetermined bounding boxes. As needed, any global or local variable can be overridden at any time during the execution of the instruction stream by additional data values stored in the PANOSE file. Therefore, the fidelity with which a traditional typeface can be replicated depends on the number of overrides stored in the input PANOSE file.

    The instruction sequence is sufficiently rich that a wide variety of fonts within a large design space can be instantiated in the field using a relatively small parameter set, without extrapolating from a single master outline or interpolating between two or more outlines. Since the generated character shapes are defined in terms of conventional mathematical constructs, such as points and Bezier curves, they can be easily translated into other digital font formats if necessary.

    An essential feature of Infinifont is the ability to closely replicate existing or traditional typefaces. There are two problems which must be solved before high-fidelity replication can be achieved: matching the character advance and other metrics, and matching the glyph shape.

    A failure to correctly match metrics within a target typeface is easily noticed; if even a single character in a font has been synthesized with a width that is only 1% too large, the document may not paginate identically into two different operating environments.

    However, metrics matching is reasonably well understood and is solved by many font vendors simply by copying the relevant metrics from the target font to the newly generated font. Metric data generally comprises less than 5% of the size of a typeface; hence it is reasonable to copy the metrics into the PANOSE file (and then into the document itself). It is crucial to reconcile the metrics with the glyph shapes during generation.

    The glyph outline conformance problem is solved by using first a PANOSE number, then global override data, and then local override data, to update at synthesis time those parameters which will significantly affect the final glyph shape.

    The override system is designed so that the larger the number of override inputs, the closer the contour conformance, and the most general override inputs are presented and applied first. This provides for a reasonable 95%-5% solution, where a very close replica may be represented in about 5% of the overall space required to store the typeface using a conventional font format.

    Closely replicating well known typefaces while maintaining the size advantage of parametric type is a key advantage of the Infinifont system. The architecture can therefore always be scaled from low to high sophistication by increasing the number of detail strings used to describe a target typeface.

    On some platforms where both volatile and nonvolatile storage space is severly limited (such as a handheld personal computer), size (and degree of conformance) can be reduced; on a workstation or a printer, the degree of conformance (and therefore the required size) can be much higher."

    For those interested, there is the Dave & Ben Bauermeister (PANOSE inventor) hangout recording
    https://www.youtube.com/watch?v=GDjIzwbmFqw&feature=youtu.be

  • Dave Crossland
    Dave Crossland Posts: 1,431
    The infinifont software has been lost. No one has any backups. 
  • John Hudson
    John Hudson Posts: 3,230
    James:

    Which takes us right back why almost nobody uses PANOSE—it’s too much both for something 99% of graphic designers are not aware of and would probably never use if they did know about it.

    To clarify, PANOSE was never intended as something that graphic designers or other end-users would have to know or do anything about. It is intended to be consumed by software systems, which is why it is a data model and not a descriptive classification system.
    _____

    Again, I'd like to set aside questions of whether and where font matching is or is not a good idea, and the reasons PANOSE data is seldom accurately set are well known. I am interested here only in the question of whether the data might be automated. By all means treat this purely as a hypothetical exercise if that helps focus on the question.
  • Deleted Account
    Deleted Account Posts: 739
    The parametric data might be automated. There is also stuff that is data, but can't really be 'analyzed' and quantized to 10ths, or whatever. The problem with separating the 'can it be done' from the 'should it be public' is that the dissemination of a tool would enable the less scrupulous to add good or bad panose data to fonts a foundry didn't want panosossified. 

    I agree, that the original great point of Panose was for hp printers to find a suitable alternative across a publishing boundary hp had created for themselves. Now, the boundaries are considerably grander swaths; the free boundary, the creative cloud boundary, combined with the web non-boundary, aka, garden fence. So, I've always seen panose as a cheat... for which the font industry has received nothing In Return. 

    I welcome guidance on this, and otherwise would be glad to support private projects aimed at mutually assured non-destructive uses of panose. 
  • Bianca Berning
    Bianca Berning Posts: 21
    I always wondered which software systems actually use the data nowadays? I calculated far too many PANOSE values with the help of the guide over the years and can second that it's time-consuming and not very intuitive. I'd be very interested in helping to make it more user-friendly. Not sure it's automatable though (which brings me back to the complexibility/impossibility of type classification in general).

    Just to put it out there as I don't have an answer: Are measurements and calculations really needed to *visually* match fonts?
  • Thomas Phinney
    Thomas Phinney Posts: 2,899
    PANOSE numbers are used in interesting and sometimes surprising ways. For example, if a font is marked as monospaced in PANOSE, Windows GDI will treat it as monospaced regardless of actual glyph advance widths. (That was an interesting issue to figure out, years ago.)
  • Ray Larabie
    Ray Larabie Posts: 1,436
    It seems like it would be useful for finding the most appropriate fallback glyphs. If I'm missing ₹, maybe I'd could have a better chance of getting one in a typeface that's more appropriate. Has PANOSE ever been used that way?\

    And when can I stop capitalizing PANOSE.
  • Nick Shinn
    Nick Shinn Posts: 2,216
    From The Guardian style guide:

    Use all capitals if an abbreviation is pronounced as the individual letters: BBC, VAT, etc; if it is an acronym (pronounced as a word) spell out with initial capital, eg Nasa, Nato, unless it can be considered to have entered the language as an everyday word, such as awol, laser and, more recently, asbo, pin number and sim card. Note that pdf and plc are lowercase.


  • Atilla Korap
    Atilla Korap Posts: 9
    Sorry for the late reply, I was just searching for PANOSE, when this thread appeared in the search results...
    @John Hudson, if I remember correctly Monika Bartels (Fontwerk) told me she worked on an implementation in the 90s. And I also remember colleagues telling me that Linotype had a way to automatically calculate it. But that was in the 80s and early 90s when they had their production systems on DEC computers. The code was written in Fortran for VAX and has never been ported to other machines or languages.
    However, just to confirm that I have heard of implementations, even though I never actually worked with one. The problem I guess, is that it not considered important enough.
    You should talk to Monika for more in depth information.

Categories