Issues after upgrade to 0.8.0 running PHP7

[samhibberd]

Hi There,

I have been trying to work this one out for a few days now but i'm stuck, mainly struggling to debug and identify the actual issue.

Been successfully using version 0.7.0 on a project running on php7 for the last few months, but started experiencing bugs on both our local, staging and production environment servers (likely caused by unrelated updates).

To try and simplify, we are now running 0.8.0 on php7.1, installed via composer and with dependencies installed, all requirements met and pdf generation is causing issues:

• When ->stream to browser: Consistently get 'Failed To Load PDF' in Chrome and Safari
• When ->stream: Creates and downloads the PDF but with no styles applied, or fonts (@font-face) created or images (even a simple html p tag with just the colour style in css doesn't work)

Tried simply rendering simple html string with no difference and tried running the current master (from github) still no good.

Input HTML + CSS both validate wit no errors.

Running 0.7.0 on php7 or php7.1 - I get the following error:

A non-numeric value encountered
....../dompdf/dompdf/src/FrameDecorator/Page.php(494)

Running 0.8.0 on php7 and php 7.1 (on our staging server) - I get the following error:

Internal Server Error
unpack(): Type n: not enough input, need 2, have 0

Really stuck now.

Any reports of any issues, things to try or better ways for debug / track down the actual issue??

[bsweeney]

The "non-numeric value" error when running PHP 7.1 is one of the driving factors behind the release of 0.8.0. So if you don't want to downgrade PHP you'll need to stick with dompdf 0.8.0. There was a missed arithmetic operation (see #1407). So it's possible you'll still run into the issue.

For the other error, there's no indication of where that error occurred. unpack is used by dompdf, mainly when parsing images, and by php-font-lib. There a relevant issue already for php-font-lib so that may be something to keep an eye on (see issue dompdf/php-font-lib#47).

I'm not sure why even a simple document would not render correctly. For your simple test is the CSS inline or in an external document. It sounds like maybe dompdf is having trouble accessing external resources, but I'm not sure.

Might help if you can turn up the error reporting in PHP. If that doesn't help you can try enabling to domdpf debugging capabilities.

[samhibberd]

Thanks for such a prompt response @bsweeney, it really helped me track down the issue, it appears your are right in that it looks to be an issue with external resources, inline styles were file. None of the external images were loading correctly, i finally work this is oddly caused by my local env (running valet) but only when SSL is enabled.

This helped uncover the actual issue, which was fonts, there was a handful of fonts being included via font face, which started to get generated again when the SSL issue was identified (so when running on non SSL) once tracked down I was stuck again, but tried running the font through TransType 4, re exported, re tested and it works!

Tested on our staging site and works running on SSL & NON SSL, so will be something unique to Valet.

Got there in the end, only advice i can offer for anyone else who runs into similar issues is:

• Test with and without SSL enabled
• Worked for me with a full path (not relative in my @font-face
• Isolate any problem fonts (for me 2/10 caused the unpack error) and validate resave (i used TrueType 4)

Thanks.