Panose number - Family Kind

Belloc's picture

Given the fonts below, why are they classified as Panose Family Kind = Latin Hand Written (3), instead of LatinText (2) ?

Edit : the font name should be "DFKai-SB" instead of "DFK-SB"

riccard0's picture

Most probably because what you show is the generic latin part of fonts meant for non-latin typesetting, and whose non-latin parts are more akin hand writing.

Belloc's picture

@riccardO

I don't know, but reading this statement "Extensions of the PANOSE system to other families of writing forms (Kanji, Hebrew, Arabic, etc.) have not been defined at the time this revision was written" here, the "Latin Text", or the "Latin Hand Written", or the "Latin Decorative" classification, should apply only to the latin characters on those fonts.

John Hudson's picture

Huge, huge amounts of fonts contain incorrect Panose information. There are various reasons for this, mostly due to the difficulty of producing accurate Panose information: to date, automated tools cannot be trusted, so the only way to produce a complete set of accurate data is manually, which is very time consuming involving lots of measuring of individual glyph features and then calculation of derived values and then matching of these values to the Panose definitions. Most font vendors simply don't bother: they either guess at values based on the very misleading names associated with the values in the Panose spec, accept e.g. FontLab's autogenerated Panose values (never, in my experience, even close to correct), or set everything to 'no fit'.

That said, the meta 'Latin Text' category is just about the only Panose value that should be fairly easily set for most fonts without measurement. But some decisions are also guided by bugs or peciliar interpretation of Panose values in applications: a classic case of massaging font data to work around software bugs. My guess, looking at the examples you provide, is that someone, somewhere along the road found that some unwanted behaviour resulted in some piece of software if a non-Latin font were categorised as 'Latin Text' for Panose purposes, but that this behaviour could be avoided if the setting were changed to 'Latin Hand Written'.

Microsoft and other contributors to OT/OFF are currently revisiting the definition of Panose in the spec, as covered in the OS/2 table. At present, the spec references version 1.0 of the Panose documentation, which isn't readily available and contains some significant differences to the current version, so there is a proposal to change the OT/OFF spec to reference that version instead. Presuming that goes ahead, it would be a good first step to cleaning up the Panose font data mess, but there will still be thousands of fonts with bad data out there, making Panose an unreliable technology for any of the purposes for which it was intended or might to which it might be put. I suspect there will eventually need to be a certification flag in fonts, by which a font vendor signals that a font contains accurate Panose data, and that software will ignore Panose data in most other fonts. In other words, the whole thing needs to be rebooted if it is to have any value, and I don't see that happening without tools that do a better job of automated at least some of the data sets, with corresponding validators.

Belloc's picture

I think I found the answer right below the statement shown above, on that same page :

"A. Answer the following three questions. If they are all yes, then it belongs in this group. If the answer is still ambiguous, go to step B.
> Does the font belong to a family that includes italic versions? Most fonts in this group have a variety of weights and most include italic versions.
> Are the characters in the font made up of standard topologies constructed of standard parts?
> Is some portion of the font suitable for composing a paragraph of text?"

I've noticed that those fonts have no italic sub-family. That is, they don't satisfy question number 1.

Could that be the reason for the "Latin Hand Written classification" ?

Edit : John, I hadn't seen your answer while I was typing this.

John Hudson's picture

Well, it could be the reason for non classification as 'Latin Text', but it hardly explains why 'Latin Hand Written' was selected instead.

Belloc's picture

I guess by exclusion, as they cannot be considered as "decorated fonts".

Belloc's picture

John, do you know what they mean by this second question above :

"> Are the characters in the font made up of standard topologies constructed of standard parts?"

John Hudson's picture

It could mean almost anything, although I presume it means something like 'Does the font correspond to your expectations of a Latin text font?'. I find the Panose specification both confused and confusing: it is a mix of very precise objectively determined data sets (things to be measured and calculations to be made) with very imprecise and poorly defined subjective criteria such as 'standard topologies' and 'standard parts'.

Nick Shinn's picture

Panose might be relevant academically as a theoretical taxonomic system, but its purported practical usage—substituting “similar to” fonts for unavailable fonts—is a can of worms, for various reasons.

My present practice is to enter zero (“any”) for every field, effectively ignoring Panose.

Belloc's picture

Nick Shinn,

But according to this page, MS does use this criteria to identify, or to substitute a font :

The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced. If the font is a symbol font, the first byte of the PANOSE number (bFamilyType) must be set to “pictorial.” The specification for assigning PANOSE values can be found here.

Nick Shinn's picture

Yes, that’s why I enter zero, because I don’t want MS identifying my fonts according to Panose values that don’t correspond with other font ID systems—weight in particular. That can cause conflicts and wrong fonts.

Belloc's picture

Nick Shinn,

I'm a newbie on fonts, so I would very much appreciate if you could elaborate on your last comment. I didn't quite follow what you said above, specially regarding the part "Panose values that don't correspond with other font ID systems, weight in particular".

Thanks.

Belloc's picture

John Hudson

>> Huge, huge amounts of fonts contain incorrect Panose information. There are various reasons for this, mostly due to the difficulty of producing accurate Panose information: to date, automated tools cannot be trusted, so the only way to produce a complete set of accurate data is manually, which is very time consuming involving lots of measuring of individual glyph features and then calculation of derived values and then matching of these values to the Panose definitions. <<

After reading this from your first post above, I asked myself why is it so difficult to automate these calculations ? Why Monotype Image can't provide theses computations? : "The rules for proper measurement, laid out below, are being refined so that minimal human intervention will be required to classify a typeface. At this time, however, there are no approved tools for the automation of PANOSE Classification Number assignment.

I confess I didn't go into the details of the calculations myself !

Nick Shinn's picture

With regard to the weight scale, here are two Font Info panels from FontLab.
In the past, I have produced fonts which misfunction in certain applications because of automatically generated Panose weight values.
That is why I now give all Panose values as zero, as it seems to me to be classic featuritis—the answer to a question that nobody asked, that makes my brain hurt.


Belloc's picture

Nick Shinn,

I had to google for the term "featuritis", as English is not my mother tongue. But I've got it now, although "the answer to a question that nobody asked, that makes my brain hurt", is still undecipherable.

My understanding is that the difficulty in determining these Panose numbers is directly related to their computations, and the number 0, is a clever way to bypass these difficulties, as it will be interpreted by the software, more or less, as "anything goes".

But what surprises me is the fact that, from all the fonts used by Word 2010, I could say that the vast majority of them have Panose numbers different than zero. Maybe that's what John was referring to, when he said : Most font vendors simply don't bother: they either guess at values based on the very misleading names associated with the values in the Panose spec, accept e.g. FontLab's autogenerated Panose values (never, in my experience, even close to correct), or set everything to 'no fit'.

Nick Shinn's picture

"the answer to a question that nobody asked…"

In this instance, “What available font would most closely substitute for the font in this document, were it not available or embedded in the document?”

Panose, for all its profiling, doesn’t deal with the most relevant parameter of this problem, which is character count, offering a mix of descriptions in several unrelated categories, and using the upper case /O as the basis of its measurement. Given that arguably the most pertinent substitution issue is reflow of U&lc text, Panose almost completely fails to address the issue.


If a typographer were designing a substitution algorithm, it would include a U&lc character count, just like the type specimens that type shops used to produce in the mid 20th century.

"…makes my brain hurt…"

http://www.youtube.com/watch?v=IIlKiRPSNGA

John Hudson's picture

Belloc, Dave Opstad at Monotype built a prototype automated Panose tool a few years ago, but says it is nowhere near complete or reliable enough to be released. The difficulty is, I suspect, one of topography: the system is based on precise measurements of particular features of certain glyphs, which means that an automated system needs to be able to identify those features. Since there is no topographic labelling in fonts, a tool would need to be able to reliably guess the features.

Té Rowan's picture

Apparently, then, PANOSE is today's version of block transfer computations.

Belloc's picture

Nick Shinn

But what the heck is "U&lc character count" and why is this so important in font substitution ?

Edit : as a matter of fact, I think I know now what a U&lc character count is. But why is it important for font substitution ?

John Hudson's picture

Character count is the average number of characters in a given amount of line length at a particular size. Ideally, it is weighted for individual character frequency in a given language. It is important for font substitution if one of the goals of font substitution is to avoid, as far as possible, document reflow. In other words, if font substitution should not make a document appreciably longer or shorter, or bump content that fits on one line with font A onto two lines with font B.

Panose, as Nick notes, fails to address character count. Instead it tries to match something like 'look and feel' of typefaces according to their proportions, weight and some stylistic features.

Belloc's picture

John,

Again, thank you for your precise and courteous responses.

Syndicate content Syndicate content