Hi.

Thanks for a great product! I just found a little detail that might be a bug.

In our company, we use scanfonts to generate css definitions of new fonts used in our solutions. We ran into a problem when it comes to condense fonts. We have two fonts that are the same except one of them are condensed. We looked at the font files, and there is a proportion setting there, and it is set to condense in one of the fonts but not for the other one.

My question then is, should not this property cause font-stretch: condensed in the font definition output from scanfonts since this is a standard value for font-stretch?

Instead, we got two equal definitions and need to put a manual override there to be able to use both of the font variants:

/* Helvetica Neue LT Pro, 45 Light */
@font-face {
    font-family: "Helvetica Neue LT Pro";
    font-weight: 300;
    font-style: normal;
    font-stretch: normal;
    src: url("/usr/local/lib/prince/fonts/HelveticaNeueLTPro-Lt.otf")
}

/* Helvetica Neue LT Pro, 47 Light Condensed */
@font-face {
    font-family: "Helvetica Neue LT Pro";
    font-weight: 300;
    font-style: normal;
    font-stretch: normal;
    src: url("/usr/local/lib/prince/fonts/HelveticaNeueLTPro-LtCn.otf")
}

Currently Prince checks the usWidthClass value in the OS/2 table of TrueType/OpenType fonts to determine an appropriate font-stretch. Perhaps this font needs slightly different treatment to identify its true width. If you can email me (mikeday@yeslogic.com) the font I can take a look and see if we can change the scanfonts behaviour to be more accurate in this case.

We have now released Prince 8.1, which uses the "proportion" field of the Panose font description to determine a more appropriate CSS font-stretch value. This seems to work better.