Log in / Register

Forum › Bugs

No subsetting of opentype fonts

thomas
Good old truetype fonts are subsetted, but not Opentype (CFF) fonts.

Example:

$~ cat foo.html
<html>
<body>
<p style="font-family:ITC New Baskerville Std">Baskerville</p>
<p style="font-family:Droid Serif">Droid Serif</p>
</body>
</html>

$~ prince foo.html

$~ pdffonts foo.pdf  # mind the "sub" (subset) field
name                     type       emb sub uni object ID
------------------------ ---------- --- --- --- ---------
NewBaskervilleStd-Roman  Type 1C    yes no  no       4  0
PXAAAB+DroidSerif        TrueType   yes yes no       5  0


++
Thomas
mikeday
Right, unfortunately OpenType fonts with PostScript Type 1 / CFF glyph outlines are a totally different beast to OpenType fonts with TrueType glyph outlines, and require an entirely different subsetting approach, which we have not yet implemented.
thomas
O.K.

By the way, if someone needs a solution, here is a free and quick workaround: convert to ps using the Adobe reader and back to pdf.

~$ acroread -toPostScript foo.pdf

~$ ps2pdf foo.ps

~$ pdffonts foo.pdf
name                            type     emb sub uni object ID
------------------------------- -------- --- --- --- ---------
UROZEZ+DroidSerif               Type 1C  yes yes no      13  0
ANVMUH+NewBaskervilleStd-Roman  Type 1C  yes yes no      11  0


Sadly, hyperlinks are lost.
Infarinato
mikeday wrote:
Right, unfortunately OpenType fonts with PostScript Type 1 / CFF glyph outlines are a totally different beast to OpenType fonts with TrueType glyph outlines, and require an entirely different subsetting approach, which we have not yet implemented.

Is it still the case? I thought this had been already addressed in version 7, but have just tried with Prince 8.0 and Adobe Garamond Premier Pro and Linux Libertine OT [on Windows 7] and still can’t get them to show, whereas Linux Libertine TT works fine (…I haven’t tried on Mac OS X, yet).

Thanks.
mikeday
The OTF fonts should definitely work, it's only font subsetting to reduce PDF file size that isn't yet supported.
Infarinato
That’s what I thought, but although the attached [minimal] test works fine on Mac OS X (tried last night :D), it definitely doesn’t work for me on Windows 7 (…I also tried with an explicit
src: url("C:\Windows\Fonts\GaramondPremrPro.otf");
…and also with the Linux Libertine OT fonts, in case you want to give it a try yourself with some non-commercial fonts :wink:).

On Windows 7 they default to Times New Roman, which to me means that the system is failing to understand what font is being called… :roll:
  1. prova.zip‎ 0.7 kB ‎
    CFF test
mikeday
Note that in CSS strings, forward slashes are used to escape Unicode characters, eg. "\A0" for no-break space. This means you need to be careful with Windows filenames, and use \\ or / instead, eg. "C:\\abc\\def". Confusingly, this will only cause problems when the character following the slash is a hexadecimal digit, eg. 0..9 and a..f, other characters will not be affected.
Infarinato
Thank you for getting back to me, Mike.

That works… Yet, it looks like a workaround to me more than an actual solution. Indeed, it means that rather than having just one declaration block
@font-face {
    font-family: serif;
    src: local("Garamond Premier Pro");
}
you need something like this:
@font-face {
    font-family: serif;
    font-style: normal;
    font-weight: normal;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro.otf");
}
@font-face {
    font-family: serif;
    font-style: normal;
    font-weight: bold;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-Bd.otf");
}
@font-face {
    font-family: serif;
    font-style: italic;
    font-weight: normal;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-It.otf");
}
@font-face {
    font-family: serif;
    font-style: italic;
    font-weight: bold;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-BdIt.otf");
}
etc… plus —if I’m not mistaken—
h1, h2, h3, h4, h5, h6, strong { font-weight: bold; }
em { font-style: italic; }
etc. :?

Moreover it makes the CSS non-portable. :cry:

Maybe I’m just too “(Xe)TeX-minded”, but since you are already looking into subsetting CFF fonts, maybe it would be worth looking into this issue, too? :)
mikeday
You should not need to repeat all the default rules for h1, h2, etc.

What does Prince generate if you run "prince --scanfonts C:\Windows\Fonts\GaramondPremrPro.otf"?
Infarinato
This:
/* Garamond Premier Pro, Regular */
@font-face {
    font-family: "Garamond Premier Pro";
    font-weight: normal;
    font-style: normal;
    font-stretch: normal;
    src: url("C:\Windows\Fonts\GaramondPremrPro.otf")
}
mikeday
All seems quite normal. Perhaps the fact that it is an OTF font is affecting our ability to see it as a system font. We'll take a look.
Infarinato
Thank you. :D
mikeday
That was indeed the problem! Prince 8.1 is now available, and supports OTF fonts that have been installed on Windows as system fonts.
Infarinato
Thank you for the update, Mike. :)

Let me get this straight, though…

Referring back to my example above, it does look like you no longer need things like this:
h1, h2, h3, h4, h5, h6, strong { font-weight: bold; }
em { font-style: italic; }
on Windows with Prince 8.1 (thank you!).

However, it looks like you still need this: 
@font-face {
    font-family: serif;
    font-style: normal;
    font-weight: normal;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro.otf");
}
@font-face {
    font-family: serif;
    font-style: normal;
    font-weight: bold;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-Bd.otf");
}
@font-face {
    font-family: serif;
    font-style: italic;
    font-weight: normal;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-It.otf");
}
@font-face {
    font-family: serif;
    font-style: italic;
    font-weight: bold;
    src: url("C:\\Windows\\Fonts\\GaramondPremrPro-BdIt.otf");
}
rather than simply
@font-face {
    font-family: serif;
    src: local("Garamond Premier Pro");
}
which works fine on Mac OS X… Is that right?

Thanks.

P.S. PDF output is also negligibly larger on Windows compared to Mac OS X (534 KB versus 521 KB for the above example).
mikeday
Okay, that's weird. I tried installing Garamond Premier Pro on Windows XP and found that it shows up in the font selector box as "Garamond Premr Pro", note the missing "ie" in Premier. When I use this as the font-family name, it works fine.
Infarinato
Thank you, Mike. :D

So, to make the CSS “OS-independent”, I guess one could set something like:
@font-face {
    font-family: serif;
    src: local("Garamond Premier Pro"), local("Garamond Premr Pro");
}
…? (Seems to work on Windows.)
mikeday
Yes, that should work fine. It's still a mystery as to why Windows chooses a different name for the font; perhaps there are length limitations, who knows. :)
cnj125
Is there any update for this issue? I have to embed multiple Chinese OTF fonts(CID Type 0C) into the PDF file, and the PDF file is huge.

I also tried to subset the font by myself, but the character cannot be shown in the PDF.

How should I subset the font, so that the characters can be displayed?

Thanks a lot
mikeday
No, I'm afraid we can't subset OpenType fonts with CFF outlines yet, although we do plan to implement this as soon as we can. In the meantime perhaps it's possible to process the PDF with another tool, or convert the font to TrueType outlines.
sparanoid
Any update for this issue? After 10 years we still wait for this feature. The 10-page document we generate has over 40 MB due to embedded fonts.
mikeday
It's coming! We are finally working on it now, for Prince 13. :D
mikeday
Prince latest builds now support subsetting for CFF fonts! :D
sparanoid
Just tried the latest build and it works awesome, thank you @mikeday and the Prince team!