search

dompdf / dompdf

HTML to PDF converter for PHP
https://dompdf.github.io/
GNU Lesser General Public License v2.1
10.57k stars 1.8k forks source link

Using DejaVu fonts only works in Chrome preview, all other PDF viewers display gibberish #1433

Open floriandammeyer opened 7 years ago

floriandammeyer commented 7 years ago

We are using Dompdf 0.8.0 to create PDF invoices from HTML. We have global clients, so in rare cases the invoice has to support i. e. cyrillic letters. For that reason we wanted to use the DejaVu fonts that ship with Dompdf, but somehow the PDF files using that font can't be displayed correctly by any PDF viewer except for Google Chrome's built-in PDF preview.

Chrome's PDF preview shows everything correctly, but other PDF viewers show either weird symbols or, in case of Adobe Acrobat, only empty rectangles. I've attached an example PDF document: Invoice_Example_Stripped.pdf

What is going wrong here? Is the font not being embedded correctly? We are using Dompdf with its default options, do we need to change some of them to enable embedding? I've found some other issues that might be related to this (like #938).

hakimio commented 7 years ago

The font is embedded, but maybe it's not the right one. You can try to use custom fonts to see if it helps. Also, have you tried the solution which worked for duong841992: https://github.com/dompdf/dompdf/issues/938#issuecomment-269274979

bsweeney commented 7 years ago

It looks like the font it embedded correctly. I'm not sure why it would display correctly in Chrome but not in other viewers. Can we see a sample of the HTML+CSS you're using?

ziprain commented 7 years ago

@bsweeney After trying the solutions offered in #938 XODO Docs and Adobe PDF Viewer were still unable to read the font correctly. We reverted all changes concerning the DejaVu font. Right now the relevent styling for the font-family is body{font-family: Helvetica, Arial, sans-serif; font-size: 11pt; margin: 0;}. Chrome managed to handle this styling we used, but the above mentioned failed. body{font-family: DejaVu, Arial, sans-serif; font-size: 11pt; margin: 0;}.

Edit: Eventhough Chrome will display the letters correctly, some of them won't get displayed right away, like for example the upper half of the letter is missing. They will however appear after marking them with Ctrl+A.

hakimio commented 7 years ago

@ziprain Yup, dompdf for sure has some issues embedding fonts. I would recommend to try out mikehaertl/phpwkhtmltopdf . wkhtmltopdf works really well even on a headless linux server when used with Xvfb.

ziprain commented 7 years ago

@hakimio Thank you for your suggestion, but switching is not yet an option. We'd like for now stay with dompdf.

@bsweeney Is there any information I could provide, which would help you troubleshoot the problem?

bsweeney commented 7 years ago

Can you clarify the font definition? You specified "DejaVu" but the actual font family names used by the included fonts are "DejaVu Sans" and "DejaVu Serif" (for example).

bsweeney commented 7 years ago

Thinking about it more ...

Are you moving dompdf from one system to another? It could be that dompdf recognizes your font family declaration and sets up the PDF as if it is using that font. But when Dompdf goes to grab the font file for embedding it's not finding the file.

If this is the case the quickest fix should be to reset the font directory back to its initial state.

ziprain commented 7 years ago

I think we used "DejaVu Sans", would have to look it up the other day to confirm.

No, we used to use the ZendPDF module, but it got really messy and we were looking for another one. Everything concerning the PDF generation was coded complete from scratch, as ZendPDF does things differently.

I will try and see whether or not DomPDF can find the File or not.

Again thank you for your suggestions, I will report as soon as I have time to mess with it.

simonberger commented 7 years ago

Ok so far a first approach to fix this issue. I looked at the created PDF, at the specified PDF file format and tested some references.

Removing the parameter /CIDToGIDMap 12 0 R in object ID 10 renders the pdf correctly in all PDF viewers that I have tested. The whole object-ID 12 can be removed out of the PDF with this change. I want to state that this is not a fix in this form that will be included in DOMPDF as this seems to introduce even more header errors. But it still could help finding the problem and some to correctly render pdfs for now.