Hello,

It seems I have the same problem as in this thread: http://drupal.org/node/530320. I've tried three different versions of the Print Module in combination with DomPDF 0.5.1. All text is printed, but the PDF shows a "Broken Image" graphic. When I switch to Administration Mode the following error occurs: "warning: file_put_contents() [function.file-put-contents]: Filename cannot be empty in /.../www/sites/all/modules/print/lib/include/image_cache.cls.php on line 117." The Print This Page function functions normally. Can anybody indicate where I should look to solve this problem?

Thanks in advance!

Comments

peterx’s picture

peterx commented

I have a site with print 6x-1.8 and dompdf 0.5.1. Jpegs display in PDFs but not PNG images. The PDF contains the correct space for the PNG image and the space is blank, there is no red cross. PNGs appear in the print version. Converting a PNG to jpeg in Gimp produces a file that works in PDF. Avondrood, what type of images are you using?

peterx’s picture

peterx commented

See also http://www.martinvseticka.eu/index.php?sekce=browse&page=160 for a similar sounding problem.

Found a PNG related issue. I will try dompdf_0-5-2 for the PNG problem.
It still don't work with PNG imag

The cpdf component of dompdf and/or the pdf data format itself do not support some png features. In particular excluded are
- apha blending
- certain compression
- certain color oding
On some image processing applications I found no way to switch off conflicting options, and there are many conflicting png images around. Therefore with dompdf_0-5-2_alpha1, addPngFromFile loads the image into a gd object, converts it to a gd object without alpha channel and with addImagePng converts th gd object back to a png file image. It is not sure that all conflicting options are catched by this.

peterx’s picture

peterx commented

dompdf_0-5-2 converted both PNG and Jpeg to big red crosses. Back to 0.5.1.

Avondrood’s picture

Avondrood commented

Thank you for your input. I'm using PNG and Jpeg files. Both formats are not displayed.

Avondrood’s picture

Avondrood commented

I've tried TCPDF in stead of DomPDF, this seems to solve this particular problem.

charlie-s’s picture

charlie-s commented

I'm using TCPDF as well to solve this problem, but a new problem has emerged from it -- half of my images are displayed so large that only 20-30% of the image is on the pdf, the rest falls off-screen. Frantically researching this issue now...

ryan_courtnage’s picture

ryan_courtnage commented

If you are experiencing problems with broken images, and you are using dompdf, this may help you.

I've discovered that dompdf-0.5.1 will not display PNG images that have transparency. Remove the transparency and the PNG will display just fine.

dompdf-0.5.2_alpha1 seems to have problems displaying my PNG images, regardless of transparency. It's just an alpha version though, some bugs are to be expected.

tcpdf didn't have a problem with transparent PNG (for me anyways)

peterx’s picture

peterx commented

The PNGs are screen prints from Gimp and should not have transparency. I will look at the Gimp defaults and creating a test PNG with no alpha channel.

Avondrood’s picture

Avondrood commented

I've found a solution. TCPDF caused similar resolution-problems as described by Charlie1234: images with a resolution higher than 72 dpi, which displayed correctly on-screen, were displayed too big in the PDF-file. This made me return to the original problem with dompdf 0.5.1. I've implemented the fix PeterX proposed: http://www.martinvseticka.eu/index.php?sekce=browse&page=160 and tested the PDF-generator. Still no images. As an experiment, I manually created the "tmp" folder mentioned in the fix and now it works like a charm! The location of the tmp-folder is print/lib/tmp and writing permissions should be set. Thank you for your trouble!

peterx’s picture

peterx commented

I converted a PNG from RGB to indexed using Gimp and the image appears in the PDF. The image size is halved. Unfortunately Gimp does not let you count the number of colours in an image and does not let you set more than 256 colours when you index the image. My test image has two curved colour areas requiring about 500 colours. Gimp chooses to change the most common colours, two large flat areas of light grey to horrible beige. Some of the other images will require more colours. I might have to reinstall my ten year old copy of Paintshop Pro.

Layer > Transparency > Remove Alpha Channel
Reduced image from 36KB to 33KB and the image works in PDF. Why does Gimp create an alpha channel for images with no transparency? Weird. I wonder if there is an option to change the default?

I can now go back to using dompdf 0.5.1 and CSS. For my current use, deleting the alpha channel is of more benefit than #9 because deleting the alpha channel also reduces the image size.

charlie-s’s picture

charlie-s commented

@peter FWIW, Gimp and Photoshop both set Transparency=on by default when saving PNGs, regardless of whether or not transparency channel is being used.

Two important things to keep in mind is keep the DPI @ 72 and NO SPACES IN FILENAMES OF IMAGES!

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Fixed

So I guess this is fixed..

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.