Forum How do I...?

PDF generated via command line, but not PHP script

dianepana
I am trying to generate a PDF document on a web page, using the PHP interface I downloaded. While the document is being created, there are no errors - at least, my webserver doesn't log any errors, and neither does Prince when I turn on logging with setLog. In the end, a file 1 byte large is created, and when the file opens in Document Viewer, I see the error "File type plain text document (text/plain) is not supported." When I take the HTML I am trying to turn into a PDF and do the conversion through the command line, a perfect PDF file is created, no errors whatsoever.

Initially my problem was there were ampersands all over the place in the HTML file as text, which prevented the PDF from being created via command line as well as PHP. I changed all instances of & into & but still can't create a PDF. I feel like it must be another character that is causing trouble, because I can generate simple PDFs (just text, also simple tables), just not the one that I actually need to create.

What am I missing here?

Thanks for the help,
Diane
mikeday
Is anything appearing in the log file at all? If it's working, you should see something like this:
Thu Mar  3 11:05:23 2011: ---- begin
Thu Mar  3 11:05:24 2011: ---- end

If it works fine from the command line but not through PHP, then there may be a permissions problem, or the wrong path name is being used to refer to the Prince executable.
epanagio
Are you referring to the system log file or a Prince specific log file?
mikeday
The Prince log file, enabled with the --log option or setLog() method.
dianepana
Hmm, a log file isn't being created at all. I have the location of the executable correct, that is for sure. Probably a permissions issue, then? How would I go about fixing that?
mikeday
Can you paste a sample of your PHP code where you initialise the Prince object? There are two possibilities: it may be failing to run the Prince executable, or that may be succeeding but Prince does not have write permissions to the log directory. This should not stop it from producing a PDF file, though. Are you using the passthru method to return the PDF directly to the browser, or saving it to the file system somewhere?
dianepana
Sure, here is the initialization code:
include('include/prince.php');
$prince = new Prince('/usr/local/bin/prince');
$prince->setLog('prince_log');
header('Content-Type: application/pdf');
header('Content-Disposition: attachment; filename="test.pdf"');
$prince->convert_string_to_passthru($html);


A file is being created, so the executable file is definitely being run, it just gets interpreted as a plain text file.
epanagio
For me it was the DOCTYPE. As soon as I deleted it...poof it worked.

Again, thanks for the great support. We'll give it another day of testing and then we'll buy the professional license.

Evan
mikeday
Try setting an absolute path in a known-writable directory for the log file, eg. "/tmp/prince.log" or something like that. And perhaps make a really simple value for $html, eg. "<html><body><p>Hello!</p></body></html>" and see if that works.
dianepana
Hey, look at that! Logging to /tmp worked.

I played around with the page I'm trying to turn into a PDF and read the log file - apparently there are some issues with understandable but not strictly correct markup. The command line converter recognizes "<hr>" as the markup to create a horizontal line, but the PHP interpreter needs "<hr/>" in order to render properly. That greatly simplifies what I have to do - not worrying about file permissions, just going through the HTML with a fine-toothed comb!

Thanks very much for your help!
mikeday
Prince treats XML and HTML documents differently, with XML documents getting a much stricter parser that follows XML-specific rules. When run from the command-line, Prince looks at the document and has a guess whether it is XML or HTML, based on the content and the file extension. When you are converting a string, there is no file extension, and Prince assumes it is XML unless you specify otherwise with setHTML(1). However, sometimes there are advantages to using XML (or XHTML): stricter error checking and better Unicode handling can make it easier to figure out when you make a mistake.