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
The effort put into the PANOSE guide, I think is an indication of it's low importance. Let's face it, some of us draw alphabets because this kind of thing makes our brains seize up. There are no visual references in this section, which is important because I think my StepRat might be greater than 0.85.
I still don't know what some the decorative classes mean. I could never figure out what derivative and collage is supposed to mean.
A web site could take people through the process using specimens and multiple choice questions. Each specimen would use the same characters so users could visually compare with their own designs. And then for the more technical parts, users could upload sample glyphs and calculate tip rats or other rodents could be calculated.
I can’t remember any of the details, but it took me a long while to figure out that it was Panose that had had broken my fonts, and I was really pissed off—even though it wasn’t the fault of Panose per se.
So no, I want nothing further to do with this classification system, besides which I think the whole premise of check-box description and automated font matching is preposterous.
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.
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:
For those interested, there is the Dave & Ben Bauermeister (PANOSE inventor) hangout recording
https://www.youtube.com/watch?v=GDjIzwbmFqw&feature=youtu.be
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.
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.
Just to put it out there as I don't have an answer: Are measurements and calculations really needed to *visually* match fonts?
And when can I stop capitalizing PANOSE.
@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.