We are trying to create our font calls to rely on font-weight and font-style with a common font-family name. What we are finding is that tools we might use to autogenerate the @font-face rules for a font family are giving us different weight information then we are getting by using prince --scanfonts. We have nearly hundreds of fonts so being able to create a service to provide this information is important to our production workflow.

As an example if we take the Roboto Thin and scan it with prince --scanfonts it tells us the font-weight is “normal.” but if we look at the OS/2 and Windows Metrics table under usWeightClass we get “250.” We have a few ways to find this value and we get the same information with each of them, here is a link to a web site that has a font inspector.

https://opentype.js.org/font-inspector.html

So when we programmatically create a set of CSS @font-face rules with font-weight(s) that do not match what Prince seems to be looking for we end up with a lot of the fonts being dropped and substituted for other fonts from that same family, these usually happen to be those fonts whose font-weight matches.

We have 8 font weights in Gotham, we can only get a handful of them to show up in Prince using our @font-face rules because of this gap in what Prince sees as the fonts weight and what the font metadata indicates it is.

Were is prince --scanfonts getting its font-weight, font-style and font-stretch values from?

Prince is using the OS/2 usWeightClass field, however it expects values that are multiples of 100, the same as CSS, so values like 250 will be ignored and Prince will fallback to checking the head table.

Now that CSS is switching to support fine-grained values from 1..1000 with variable fonts we can update Prince to do likewise and map these intermediate values appropriately.

Do you know how soon you will be doing this? Having some rough idea can help us craft our current solution.

We will investigate and see if we can provide a solution within the next few weeks.