CODEWITHSUNDEEP
phppdfpngtcpdf
Sean Fahey
Sean Fahey

Reputation: 1910

TCPDF produces "An error exists on this page." in Acrobat with PNGs

Some PDFs generated by TCPF 6.0.099 are displaying this error, but only in Acrobat:

An error exists on this page. Acrobat may not display the page correctly. Please contact the person who created the PDF document to correct the problem.

The error occurs on some pages with .png images, though not all PDFs with images will generate the error. Opening the PDF in Chrome is fine and the images are shown. Removing the .pngs from the page prevents the error. There are no errors from TCPDF in the php_errors log.

Producing a PDF with the same content,using the same code, and same version of TCPDF on my localhost does not produce this Acrobat error. My local server runs OSX. The web server runs Centos 6.5. Both local and web servers are running PHP 5.5.

The images are in <img> tags, part of a big chunk of html written to the PDF with writeHTMLCell() using an absolute url in the src. I ran the web server’s PDF through the pdfHarmony demo and it returned two errors that match up problem pages:

page: 004 Could not find the XObject named 'I2'.
page: 007 Could not find the XObject named 'I12'.

Running pdfHarmony on local’s PDF returned no errors at all.

I thought that maybe the webserver had a permissions issue on TCPDF’s cache folder, except that the images still show in Chrome. Opening up the permissions to cache had no effect. Setting paths in tcpdf_config.php for K_PATH_MAIN, K_PATH_URL, and K_PATH_CACHE had no effect.

The PDF that errors out is larger than the than the PDF that does not have errors. (147k vs 109k). The first diff between the files (that isn’t a timestamp) is this:

  Webserver: /ColorSpace [/ICCBased 27 0 R]
  Localhost: /ColorSpace /DeviceGray

And those differences appear throughout the file. This blog post says that ICCBased isn’t supported by all tools, but I have no idea if that includes Acrobat, or how to specify from TCPDF what color space to use. I know that TCPDF uses either ImageMagick or GD to render .pngs. Both servers have imagick 3.1.2 and GD version “bundled (2.1.0 compatible)”. I don’t know if there is a way to tell TCPDF to use one library over another, or how to tell which library it is currently using.

Telling our users not to use .pngs isn’t an option. Maybe it is possible to convert the .png to some other format that doesn't cause this error. But why does one server produce PDFs with the error and another does not?

Example

I set up an example of the problem.

Here is a problem png

Here a PDF will be generated that includes the image (This will prompt for download right away)

Here is the important part of the code:

$pdf->AddPage();

$html = '<img src="https://example.com/1.png">';

$pdf->writeHTMLCell($w=0, $h=0, $x='', $y='', $html, $border=0, $ln=1, $fill=0, $reseth=true, $align='', $autopadding=true);

Upvotes: 2

Views: 2091

Answers (1)

Sean Fahey
Sean Fahey

Reputation: 1910

I found a hack fix for my problem, but I’m not at the root of the issue yet. By removing the alpha mask from the generated .png at the end of TCPDF->ImagePngAlpha() I can now open the PDF with Acrobat. I removed $imgmask from the end of $this->Image($tempfile_plain, $x, $y, $w, $h, $type, $link, $align, $resize, $dpi, $palign, false);

See this example of a fixed PDF

I still don’t know why it is a problem on the web server vs localhost. In TCPDF->Image() I see two different results for the $info var once TCPDF_IMAGES::$mtd($file); is called.

On the web server:

array(11) {
  ["w"]=>
  int(183)
  ["h"]=>
  int(88)
  ["ch"]=>
  int(1)
  ["icc"]=>
  string(6936) "
}

On localhost:

array(11) {
  ["w"]=>
  int(183)
  ["h"]=>
  int(88)
  ["ch"]=>
  int(1)
  ["icc"]=>
  bool(false)
  ["cs"]=>
  string(10) "DeviceGray"
  ["bpc"]=>
  int(1)
  ["f"]=>
  string(11) "FlateDecode"
  ["parms"]=>
  string(75) "/DecodeParms << /Predictor 15 /Colors 1 /BitsPerComponent 1 /Columns 183 >>"
  ["pal"]=>
  string(0) ""
  ["trns"]=>
  string(0) ""
  ["data"]=>
  string(32) "H?c???c?!"
}

I don’t know why I get these differences, but at least I have a good fix for now. I don’t need the alpha mask for my .pngs in this case.

Update

What I said before about not needing the mask wasn't really true. Turns out I did need it for some of my .pngs, but I have a better fix now. I commented out the entire ImageMagick section of TCPDF->ImagePngAlpha() forcing it to use GD. It works!

Upvotes: 2

Related Questions