Hi,

I am using Prince to create a financial report in HTML to then render it to a PDF

We are using 6 custom fonts (different headings and weights).

Rendering the PDF displays all the custom fonts perfectly:
http://cl.ly/image/0k3P1y3o181J

But when I print the page only 1 of the fonts shows up (for the heading 'Ontvangsten der...')
http://cl.ly/image/1Q1I0Y280c1R (the logo is an SVG)

Is there a known issue related to this?

When I delete the custom fonts, use Arial instead, everything renders as expected.

What are the custom fonts? We have had reports of some fonts that do not work with some printers.

The custom fonts are Guardian. See the attached pdf that has the problem.
The problem only occurs when printing from Preview or from the Chrome internal pdf viewer on OSX. Printing from Acrobat Reader on OSX or Windows works without problems.

It seems to be related to the embedded font encoding: see http://www.screencast.com/t/QLCA4f6Nqm
I created 2 pdfs, one with an € sign in the title, and one without. The pdf with the € sign does not print correctly, the pdf without the euro sign but with exactly the same fonts prints correctly. When checking the font properties in Acrobat reader, I see that the fonts that don't print all have Type 1 (CID) and Encoding Identity-H. The same font with encoding Roman prints perfectly.

I don't think it is related to the printer itself: it occurs on all printers we try, and occurs also when exporting as a pdf from Preview.

1. foto (1).JPG‎ 101.4 kB ‎
   result of print from Preview
2. tmp_52a86a925db80.pdf‎ 162.3 kB

Right, this is a bug in MacOS X Preview affecting OpenType fonts with PostScript Type 1 / CFF outlines (.otf files, basically). We do not have a workaround for this issue yet, so far the only fix has been to use different fonts, or a different PDF viewer.

I don't think the variables are just OpenType fonts with PostScript Type 1 / CFF outlines and Mac OS X Preview since if I drop a few fonts in Illustrator and print them using preview everything works just fine.

http://cl.ly/image/052F1v0Q162K --> this prints as expected (made with Illustrator)

With my test files (made with HTML+ Prince) for now I have been able to correctly print the files with Adobe Acrobat Pro. Oddly enough 1 of the 6 fonts in my test doc does print when I run it through preview.

The fonts are Guardian Egyptian Headline (Bold, Medium, Semibold) and Guardian Sans Text (Regular, Medium, Bold) from Commercial Type.

Yes, it depends on the way the fonts are embedded in the PDF file. There is another way of embedding them that we can try. Unfortunately I think some other PDF viewers don't like that method, but perhaps MacOS X Preview outranks them now.

It would be good if any changes to how fonts are embedded be enabled via a command line option.
I have yet to publish, but I am hoping to use createspace and thus will have no control over what sort of machine / software will ultimately be used to print the pages.

(I have no idea whether any of this has ever been a problem for POD publishers -- I just basically freaked out when my document showed up as mostly blank pages when I tried printing it on an Mac OS setup )

This is less likely to be an issue for print on demand, as they are not using MacOS X Preview. But sometimes there can be other issues with fonts, or colors, or image formats, and ultimately the only way to be certain is to check with the printer, or send a few PDFs through and see that they come out right.

I also encountered a custom font issue that only manifested in OSX Preview, though it was not only when printing. The visual bug was that the font always showed up about 1/4 size as in other PDF viewers like Acrobat Reader and the Chrome plugin.

My custom font was specified as so:

@font-face {
	font-family: 'PulseIcons';
	src:url('PulseIcons.eot');
	src:url('PulseIcons.eot?#iefix') format('embedded-opentype'),
	url('PulseIcons.woff') format('woff'),
	url('PulseIcons.ttf') format('truetype'),
	url('PulseIcons.svg#PulseIcons') format('svg');
	font-weight: normal;
	font-style: normal;
}

When I changed the CSS to only use the .ttf, the bug no longer occurred. Before, the .woff was getting used, which I guess is just a web version of .otf.

A somewhat different issue, but thought I'd quickly post this in case it helps someone.

Pulse Energy

Interesting! If you can email me (mikeday@yeslogic.com) a sample document that demonstrates the problem, we can take a look.

Any news?

The problem still exists in macOS 10.12.4 and Prince 11. Only Adobe Acrobat can print such PDFs but not Preview, or PDF Expert, or …

We have fixed some issues affecting CID-keyed CFF fonts in the latest build, but unfortunately MacOS X Preview is still very picky about fonts, so some issues may remain.

I have already tested with the latest build from today but it's the same and no text is printed.

Which font are you using? Can you send me (mikeday@yeslogic.com) a test document?

I sent you the two mails with a generated PDF and the fonts I use.

Thanks, I can reproduce the printing problem here but only from MacOS X Preview, it's very strange. We will take a look and see if we can figure something out, although we don't really have many clues to go on at the moment.

We have included a workaround for this issue in the latest build.

There was one related issue, that I'm not sure if anyone ever actually encountered, that could affect Prince generated PDFs in MacOS Preview if the CFF font had more than 255 glyphs in use at one time. Anyway, this has now been fixed in the latest builds.