Hi,
I'm trying to use a font family that does not only provide regular and bold font-weights, but also light, semibold and black.

It is my understanding that the mapping of this should be

light -> 100
regular -> 300
semibold -> 500
bold -> 700
black -> 900

Trying to write appropriate @font-face rules, I ran into a couple unexpected issues

a) paths to font files must be absolute, not relative
b) segregating the @font-face rules into a separate css file and including it does not work
c) according to some limited testing (with adobe reader), only the regular and bold weights are embedded, not the light, semibold, black ones.

is any of this unexpected? Do you want my test case?

a) proved to be a red herring. works now.
b) still seems to hold true.
c) needs further investigation.

Edited 10 Aug 2009 by oliof

Please post some sample CSS and hopefully we should be able to work it out.

Hi,

I was just rereading the CSS definition on font-weight, and it is very imprecise for good reasons it seems. I learned that my assumptions about weights for light/regular were wrong and adjusted accordingly.

@page {
  size: a5 ;
}

body {
  font-size: 8pt ;
  line-height: 13pt ;
  text-align: justify  ;
}

div.light {
 font-weight: 300 ;
}

div.regular {
 font-weight: 400 ;
}

div.semi {
 font-weight: 500 ;
}


div.bold {
 font-weight: 700 ;
}

div.black {
 font-weight: 900 ;
}
/* fonts */

/* body text */

@font-face {
  font-family: serif ;
  font-style: normal ;
  font-weight: 300 ;
  src: url("Calluna/Calluna-Light.otf");
}


@font-face {
  font-family: serif ;
  font-style: normal ;
  font-weight: 400 ;
  src: url("Calluna/Calluna-Regular.otf");
}

@font-face {
  font-family: serif ;
  font-style: italic ;
  font-weight: 400 ;
  src: url("Calluna/Calluna-It.otf");
}

@font-face {
  font-family: serif ;
  font-style: italic ;
  font-weight: 500 ;
  src: url("Calluna/Calluna-SemiboldIt.otf");
}

@font-face {
  font-family: serif ;
  font-style: normal ;
  font-weight: 500 ;
  src: url("Calluna/Calluna-Semibold.otf");
}

@font-face {
  font-family: serif ;
  font-style: italic ;
  font-weight: 700 ;
  src: url("Calluna/Calluna-BoldIt.otf");
}

@font-face {
  font-family: serif ;
  font-style: normal ;
  font-weight: 700 ;
  src: url("Calluna/Calluna-Bold.otf");
}

@font-face {
  font-family: serif ;
  font-style: normal ;
  font-weight: 900 ;
  src: url("Calluna/Calluna-Black.otf");
}

here is prince7b1's debug output (limited to font requests):

prince: Converting document...
prince: debug: pack
prince: debug: font request: serif
prince: used font: Calluna, Regular
prince: debug: font request: italic serif
prince: used font: Calluna, Italic
prince: debug: font request: 300 serif
prince: used font: Calluna, Light
prince: debug: font request: 500 serif
prince: used font: Calluna, Semibold
prince: debug: font request: 500 italic serif
prince: used font: Calluna, Semibold Italic
prince: debug: font request: bold serif
prince: used font: Calluna, Bold
prince: debug: font request: bold italic serif
prince: used font: Calluna, Bold Italic
prince: debug: font request: 900 serif
prince: used font: Calluna, Black
prince: debug: writing output: calluna-test.pdf
prince: Finished: success

The pdffonts tool from the poppler utilities give me the following for a sample document that uses all fonts:

$ pdffonts calluna-test.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
Calluna                              Type 1C (OT)      yes no  no       7  0
Calluna,Italic                       Type 1C (OT)      yes no  no       8  0
Calluna                              Type 1C (OT)      yes no  no       9  0
Calluna                              Type 1C (OT)      yes no  no      10  0
Calluna,Italic                       Type 1C (OT)      yes no  no      11  0
Calluna,Bold                         Type 1C (OT)      yes no  no      12  0
Calluna,BoldItalic                   Type 1C (OT)      yes no  no      13  0
Calluna                              Type 1C (OT)      yes no  no      14  0

$

The separate object IDs suggest these are the various font weights in order of inclusion, but the font names are not unique. This may lead to Adobe Reader showing only one font to be embedded. I don't know if this is a limitation of the PDF format or if it is an error in the embed logic used by Prince.

… and I found out what my problem with putting the @font-face stuff into a separate css file was: import != include – sorry for the noise.

This leaves us with non-unique font names in the PDFs generated.

Right, does the PDF file look correct when viewed in Adobe Reader? Also, are you able to create PDF files using these different font weights with another program to compare the names?

The PDF looks correct in Adobe Reader, but I've been told by printers in the past that that is not enough (I don't know what Adobe does in regards of automatic font weight scaling if it misses a font).

This the pdffonts output of a PDF created via the Mac printing dialog from OpenOffice (directly generating the PDF from OOO makes it default back to standard fonts, I found no way to force use of the fonts defined).

$ pdffonts calluna-ooo-print.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
PCDCUS+Calluna-BoldIt                Type 1C           yes yes no      13  0
VPTZXH+Calluna-Light                 Type 1C           yes yes no       8  0
BNFHYH+Calluna-Regular               Type 1C           yes yes no      10  0
BNFHYH+Calluna-Bold                  Type 1C           yes yes no      14  0
VPTZXH+Calluna-Black                 Type 1C           yes yes no      15  0
PCDCUS+Calluna-It                    Type 1C           yes yes no       9  0
PCDCUS+Calluna-SemiboldIt            Type 1C           yes yes no      11  0
BNFHYH+Calluna-Semibold              Type 1C           yes yes no      12  0

I don't know where the prefix comes from, but the parts after the + are the unique (internal) font names.

The prefix is related to font subsetting, and it appears that it is using the PostScript name for the font, which is unique within that family. We can do this in Prince as well, but we've tried this in the past and it has caused problems with some fonts, so we'll need to do some further investigation.

As another datapoints, here is the pdffonts output for a PDF created with Scribus:

name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
[none]                               Type 3            yes no  no      44  0
[none]                               Type 3            yes no  no      78  0
[none]                               Type 3            yes no  no      93  0
[none]                               Type 3            yes no  no     107  0
[none]                               Type 3            yes no  no     142  0
[none]                               Type 3            yes no  no     180  0
[none]                               Type 3            yes no  no     214  0
[none]                               Type 3            yes no  no     229  0

Okay, for Prince 7.0 we have changed the font name behaviour to use the PostScript name for OpenType CFF fonts. This should improve the embedding situation for these fonts, without breaking regular TrueType fonts.

Sounds great!

On a relared note, I just discovered the "--scanfonts" option in prince 7.0b1 – very useful!

Prince 7.0 is now available, hopefully the new font name behaviour should make usage of OpenType CFF fonts more reliable.