1

Hello all,

I have been struggling with this problem for a while. I am on a server running PHP 4.3.9 (I cannot change this) and trying to run html2pdf ver. 3.19. I have locally installed FPDF ver. 1.53 and modified 00_fpdf_codebar.class.php to require the earlier version. The result is a blank single page PDF file using a known good HTML template.

I have run a control on a different server running PHP ver. 5.1.2 with the box stock html2pdf using the same HTML template. This results in a valid PDF file. The vaid PDF file turns out to be 2 KB smaller than the blank one. When I uncompress both the blank and valid files using PDFTK I see that string lines are missing data. I don't really know the format, but I see the differences.

Here's an example of the uncompressed files lines:

Valid PDF: q 0.000 g BT 16.48 809.89 Td (Harry F. Anderson, PhD) Tj ET Q
Blank PDF: q 0.000 g BT Td (Harry F. Anderson, PhD) Tj ET Q

I changed the name in these examples so if the number data has to do with the original name that's why.

I'm hopping someone can point me to solving this vexing problem. Keep in mind I have no control over the PHP version that's running on the servers.

Thanks very much

2

rlg0613 (./1) :
have run a control on a different server running PHP ver. 5.1.2 with the box stock html2pdf using the same HTML template. This results in a valid PDF file. The vaid PDF file turns out to be 2 KB smaller than the blank one. When I uncompress both the blank and valid files using PDFTK I see that string lines are missing data. I don't really know the format, but I see the differences.


when you have make this test, it was with v1.53 or v1.6 of fpdf ?
Ancien pseudo : lolo

3

I made the test with a modified 1.6 FPDF - all sprintf "F" converted to "f" - hoping that the only reason FPDF did the test in 1.6 was for floating point format and not some deeper reason within the PHP version.

However, I have come up with a fix that seems to work. I have modified mypdf.class.php and 01_fpdf_bookmark.class.php to again swap out "F" for "f" in sprintf calls. I also modified 00_fpdf_codebar.class.php to use my system resident FPDF with the same mods for sprintf.

This produces a valid document. It is still larger in size than my control document, but that may be a PHP thingsince the control was running on PHP 5.1.2.

Thanks for the help. Merci.

4

I thought I had this one solved, but...

The file is OK when I save it, but if I try the download option "d" or the default reading to the screen I get the error "File does not begin with '%PDF-'".

It does have those characters when I look into the saved file.

Is there a compatibility issue with Adobe readers and html2pdf? My system defaults to Adobe 9.0 Reader to open the file.

Thanks.

5

"File does not begin with '%PDF-'". : it is because you write somethongs before the ob_start function
Ancien pseudo : lolo

6

Upstream of the ob_start I do several fwrite statements. Is that it?
Do I need to do those outside of this script? I do need to modify/create the HTML source template before the ob_start.
Thanks for the help Spipu.

7

no.

the only things that could give "File does not begin with '%PDF-'" is to write something to the client (like with echo)
Ancien pseudo : lolo

8

Thanks Spipu. You helped me find an issue that's been a problem in other situations as well.

After commenting out every possible line that could 'echo' I still had the problem. I use PSPad as an editor. More for readability than anything else I usually leave a blank line or two after the closing PHP tag (?>). When I eliminated those lines everything works fine. I guess they were issuing newlines to the screen. I'll have to tune up/clean up my editing style and get rid of the extra lines.

I wonder if PSPad has a truncate option?

9

the php closing tag ?> is not mandatory wink

so, if you don't write it, you will never hava blank line at the end of your php files wink
Ancien pseudo : lolo