White page with PNG image

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Generate a img-tag with a png image
2. Put it into your HTML-Code for your PDF (img-tag nested 
3. Generate PDF

What is the expected output? What do you see instead?
Normally you get a PDF (with the image at inserted place in HTML Code).
Instead I got a white page (no PDF was generated, no error message was shown).

What version of the product are you using? On what operating system?
dompdf 0.6.0 beta 2

Please provide any additional information below.
It is really strange, because I thought that PNG-images work in the new version.
I have a local apache (xampp) installation on my Windows 7 machine which works 
fine.

But when I want to view a PNG on the test server (SLES 11, PHP 5.2.14) it 
generates just a white HTML page, no PDF.

When there is some time left, I try to check / test a bit more.

Original issue reported on code.google.com by ukarr...@gmail.com on 27 Jul 2011 at 3:49

[GoogleCodeExporter]

Is there some important write permissions (other than lib/fonts/) or some 
special grafic libraries which are needed for generating the PDF?

But JPEG works fine ...

Original comment by ukarr...@gmail.com on 28 Jul 2011 at 3:21

[GoogleCodeExporter]

Everything is checked in the config/setup script at dompdf/www/setup.php
It looks like this : http://pxd.me/dompdf/www/setup.php
The GD2 library is required.

Original comment by fabien.menager on 31 Jul 2011 at 1:34

[GoogleCodeExporter]

I checked it and seems to be all like domPDF need it. On my local machine 
(Windows; where the PDF output works) is no APC available, but that seems to be 
no problem.

But on the test server (SLES) it returns a white page. I would expect when an 
error occur, that domPDF outputs something in the log file, but there´s 
nothing.
And as well ther is no output what domPDF do, so no indication where the 
problem is / where dompDF stops.

It seems that domPDF just stop working somewhere, that´s why no PDF but a 
white page is returned.

I have no idea ... :(
On the local machine it works, on the test server (in both cases same DB) it 
works not. The problem must be in combination with the content (comes as well 
from the DB), but I do not understand why it works locally and not on the 
server. Without an error message or a logging it´s really hard to debug!

Original comment by ukarr...@gmail.com on 8 Aug 2011 at 11:51

[GoogleCodeExporter]

On your server do you get a blank PDF or what appears to be a blank HTML page? 
It sounds like an error is happening that's halting rendering. DOMPDF doesn't 
modify you log settings so if an error is encountered you should be able to 
find it in the usual log file for your server.

You can always try enabling log display manually in your PHP:
ini_set('display_errors',true);

Original comment by eclecticgeek on 9 Aug 2011 at 5:43

[GoogleCodeExporter]

Yes it is just a white (empty) HTML page which is returned, because domPDF dies 
during processing/rendering.

I enabled display_errors (I think it is anyway activated) ... but it does not 
work. No errors in the apache logs as well as in the dompdf fonts/log.html. :(

Original comment by ukarr...@gmail.com on 10 Aug 2011 at 1:01

[GoogleCodeExporter]

We have seen some instances where bugs in PHP will result in a fatal error/core 
dump, meaning that no errors are displayed to the web browser. Depending on 
your configuration this could result in an error being logged to the apache 
error log. I don't believe this is something we've seen on your version of PHP.

Do other image formats (GIF, JPG) work?

Original comment by eclecticgeek on 10 Aug 2011 at 5:19

[GoogleCodeExporter]

Yes, other images work. I put a header image into the PDF template via img-tag 
and absolute path.

The strange thing is, that it works local on Windows with XAMPP. Now I test 
again against the pre-requirements domPDF needs (your link above).
Here are the differences between my local XAMPP installation and the test 
server with Linux (test/local):
- PHP Version: 5.2.14 / 5.3.5
- APC: suhosin.apc_bug_workaround Flag available but is OFF / no APC (no 
suhosin)

And as well, one machine is linux, the other is Windows. But export other pages 
as PDF works fine. It is only one page. I make as well a echo from the HTML 
source code (I put to the pdf_create() function) ... but I see no things which 
would be a problem.

Neither special CSS classes nor special HTML things.
Only one floating and a PNG image.
But when I remove the floating div with the PNG image inside it does not work 
either.

Actually the PDF output local with XAMPP works, as well with PNG and that 
floating div (it is just not shown in the PDF, e.g. because it is a PNG!? I 
don´t know).

No more information available at the moment ... :(

Original comment by ukarr...@gmail.com on 16 Aug 2011 at 8:43

[GoogleCodeExporter]

Some more information.
The apache log (and FF extension Live Headers) shew me, that the HTTP 
Status-Code is 200 (seems to be okay) but then only a length of 2 (bit?) is 
sent.

No error code in the apache logs.
I seet debug mode for apache on as well and get no error. Just a 200 Code.

From CodeIgniter I got as well no error message.

Original comment by ukarr...@gmail.com on 16 Aug 2011 at 1:42

[GoogleCodeExporter]

It's not too surprising you would have different experiences on the two 
machines. The PHP libraries will vary between linux and Windows and there could 
be a bug in the library on your SLES server. Can you attach the problematic 
page/image?

Also, can you try a variety of PNG images to see if there's one particular type 
causing problems? You can find a test suite of PNG images here: 
http://www.schaik.com/pngsuite/pngsuite.html

Original comment by eclecticgeek on 16 Aug 2011 at 6:24

[GoogleCodeExporter]

Thanks for the PNG information.

But I´m not sure if this really helps. Because there is only one PNG image in 
the HTML Code and it comes out of the DB. And I removed it there to be sure and 
domPDF is still (without the PNG) returning a white page.

So my first thought that the png is the problem seems not to be right. It´s 
very confusing.

Original comment by ukarr...@gmail.com on 18 Aug 2011 at 7:35

[GoogleCodeExporter]

Since you're not getting any kind of error message things are going to be 
difficult to debug. So now it comes down to some step-by-step debugging:

1) render a simple "hello world" style document
1) grab your db content end echo to the browser (don't load DOMPDF)
2) grab your db content, instantiate DOMPDF
3) 1+2+load the HTML into DOMPDF
3) 1+2+3+echo $dompdf->output_html()
4) 1+2+3+$dompdf->render()
...

Original comment by eclecticgeek on 18 Aug 2011 at 5:42

[GoogleCodeExporter]

Hi.

The problem is solved.

As I wrote, I set the error reporting, but I got no error (neither nothing in 
the PHP Framework CodeIgniter nor in the Apache Logs).

Now we start to debug the problem, we go back in the call hierarchy and set in 
the file include/dompdf.cls.php/render() a view echos and set the error 
reporting. We think that dompdf sets the error reporting back, so that we 
don´t see any errors.

The problem then was identified as a memory problem. We had just 2 pages with 
HTML tables (inside some colours, implemented in HTML with background colours 
via CSS) and domPDF said it needs more then 128 MB RAM.

So we set in the php.ini the attribute memory_limit to 256.

I think it is really important that domPDF has an extra log directory for 
system and error logs.
Would be really nice if that would be configurable in the config-files.

Thanks for your suggestions! :)

Original comment by ukarr...@gmail.com on 30 Aug 2011 at 12:59

[GoogleCodeExporter]

Extended informations.

Error reporting on the server is on, but dompdf seems to set the error 
reporting level to 0. So no error was displayed. Only setting it in the 
dompdf.cls.php/render() shows us the real problem.

Original comment by ukarr...@gmail.com on 30 Aug 2011 at 1:03

[GoogleCodeExporter]

DOMPDF can require extra resources to handle tables, especially if you have 
nested or page-spanning tables. We're still working to improve table handling 
for the next release.

I don't know why you're not seeing errors, but so far as I know DOMPDF doesn't 
modify the error reporting settings. There are a few places where the error 
handler is changed, but errors are still reported. Have you double-checked your 
settings via phpinfo()?

I'll close this issue since the problem has been solved. However, you might 
want to start a new issue/enhancement request related to error reporting. 
Certainly we have it in mind for the future, but nothing concrete yet.

Original comment by eclecticgeek on 22 Sep 2011 at 2:28

• Changed state: Invalid

[GoogleCodeExporter]

I too have this issue where PNG images with full alpha channels would have the 
image show as white while the alpha channel still displayed properly. Some 
investigation showed that the problem was the utilization of imagick. I found a 
fix that involves disabling imagick's PNG rendering.

Add the following to "dompdf_config.custom.inc.php" (so you can still choose to 
enable it if your setup is working fine):
define("DOMPDF_ENABLE_IMAGICK", false);

Change line 4324 of "class.pdf.php" from:
elseif (extension_loaded("imagick")) {
to:
elseif (extension_loaded("imagick") && DOMPDF_ENABLE_IMAGICK) {

This makes it so the configuration file is disabling the buggy PNG processor.

Original comment by kzeni1 on 15 Feb 2012 at 1:08

[GoogleCodeExporter]

@kzeni1 ImageMagick use was only included in a release version of dompdf as of 
0.6.0 beta 3. So I think your issue is probably different than that originally 
posted. Can you start a new bug report? It would be helpful if you could 
include information on your version of ImageMagick

Original comment by eclecticgeek on 15 Feb 2012 at 3:22

[GoogleCodeExporter]

Hi, I am using dompdf to generate PDF files in my php web application.  It is 
working fine in my local environment but not in my testing environment.  
Previously I used to get log in dompdf/lib/fonts/log.htm file by enabling 
something in dompdf config file be referring dompdf site settings option.  But 
now I forgot those settings and I could not access the URL 
(http://pxd.me/dompdf/www/setup.php) .  Can you please tell me how to enable 
log in dompdf?  I have no idea whats the bug in my pdf rendering. I will attach 
my local rendered PDF file and partially rendered server PDF file with this.  
Please help to resolve this issue.  Thanks in advance.

Regards,
Sankar.

Original comment by kssankar...@gmail.com on 18 Dec 2012 at 1:27

Attachments:

• Serverfile.pdf
• Localfile.pdf

[GoogleCodeExporter]

@kssankarmahadevan your question is more appropriate for the support forum or 
StackOverflow. Post again to one of those resource and someone should be able 
to help you.
https://groups.google.com/forum/#!forum/dompdf
http://stackoverflow.com/questions/tagged/dompdf

Original comment by eclecticgeek on 18 Dec 2012 at 3:10

[GoogleCodeExporter]

Original comment by eclecticgeek on 30 May 2013 at 5:16

• Added labels: Restrict-AddIssueComment-Commit