I received a report today that our PDF wasn't showing plain text in Firefox's built-in PDF viewer. It showed the message "This PDF document might not be displayed correctly." and only bold or italic text was appearing. The rest was blank.

After some further digging, I noted that this only happened when the PDF was generated on a Windows 2012 server. When I generate the same PDF on Windows 7, even Firefox renders it correctly. I understand from some other posts that the Firefox viewer can be flaky but, since it also seems to be tied to the OS, I thought I should submit a report. I'm currently using Firefox 26.

In the attached ZIP, you'll find a slimmed down version of the PDF I created for testing. I did my best to copy the example font usage from the documentation to ensure I wasn't messing anything up.

PS C:\Users\jcampbell\Desktop\prince-test> & 'C:\Program Files (x86)\Prince\Engine\bin\prince.exe' .\test.html -s .\path.css -v -o path2012.pdf
prince: Loading document...
prince: loading HTML5 input: .\test.html
prince: loading document: .\test.html
prince: Applying style sheets...
prince: loading style sheet: .\path.css
prince: Preparing document...
prince: Converting document...
prince: used font: Verdana, Bold
prince: used font: Verdana, Bold Italic
prince: used font: Verdana, Regular
prince: Finished: success

I ran the same command to generate the PDF on both OSes and received the same verbose output.

Any help you can offer with this issue would be greatly appreciated.

1. prince-test.zip‎ 63.5 kB ‎
   Sample Input and Output

It looks like there is something different about the Verdana fonts on Windows 2012. It doesn't appear to be tripping up any other PDF viewers, only Firefox, but it's probably worth investigating further to make sure we aren't missing something important.

Would you be able to regenerate path2012.pdf with --no-compress and --no-subset-fonts on the command-line?

Thanks for the quick response. I did note a difference in version numbers between the font on both machines.

Windows 7: Version 5.05
Windows 2012: Version 5.31

The requested PDF is attached.

PS C:\Users\jcampbell\Desktop\prince-test> & 'C:\Program Files (x86)\Prince\Engine\bin\prince.exe' .\test.html -s .\path.css -v -o path2012.pdf --no-compress --no-subset-fonts
prince: Loading document...
prince: loading HTML5 input: .\test.html
prince: loading document: .\test.html
prince: Applying style sheets...
prince: loading style sheet: .\path.css
prince: Preparing document...
prince: Converting document...
prince: used font: Verdana, Bold
prince: used font: Verdana, Bold Italic
prince: used font: Verdana, Regular
prince: Finished: success

1. path2012no.pdf‎ 412.7 kB

Edited 24 Dec 2013 by jcampbell

Thanks. The fonts look fine to me, and the only issue I could see is that Prince is incorrectly listing the CapHeight as 0, but this is only metadata and doesn't affect display.

Then I tried checking the Firefox output log, which I should have done first, and saw this:

TT: complementing a missing function tail

It comes from pdf.js in a function called sanitizeTTProgram(), which appears to be scanning through the TrueType bytecode and check that it isn't malicious. So it's hitting something it doesn't like in the font, but it's hard to tell if that's a bug in the font or a bug in Firefox. Since no other software has trouble, and TrueType bytecode is notoriously weird (and most implementations don't strictly follow the spec) it's probably that Firefox hasn't caught up with reality yet.

Thanks for your help. I've submitted this as an issue to pdf.js here.

Apparently this issue has since been fixed in pdf.js / Firefox.

We have also fixed the CapHeight showing up as zero in Prince 9 rev 5; I don't think this would cause any problems, but it was better to fix it just in case.