>Karsten Dambekalns wrote: >> Hi! >> >> Sorry for the 'longish' post... I am working on a script that generates >> FDF data and sends it to the browser for display in a PDF file. > ... >> But it works only in Mozilla, MSIE starts Acrobat Reader which then pops >> up an alert window saying (translated from german) 'An error occured >> while opening this file. The file does not exist.' > ... >> Nothing worked so far, and I'm getting somewhat upset slowly but >> steadily. So please help! > >Answering myself, for the sake of completeness: I found some info about >this on the net, and it seems there just is no solution. I decided to >show an additional paragraph telling the user to save the file and open >it with a double click then (as this works!) for users surfing with MSIE. > >Does anybody know another free way to manipulate *existing* PDF >documents, that might help solve this issue in a different way?
Yes. The *REAL* problem you are having is this: Microsuck, in its infinite wisdom, has decided that REGARDLESS of the "Content-type:" header you are sending, in accordance with the HTTP spec, the URL doesn't end in ".pdf" so it must *NOT* be a PDF file. Similarly, if you use a query string (eg ".../fakepdf.php?id=42") Microsuck IE (in some variants) will also assume that it must not REALLY be a PDF, because who would make a dynamic PDF? Never mind that's the whole POINT of FDF. This is Microsuck. We don't do that. Both behaviours are, of course, in direct and flagrant disregard for HTTP specifications, but it's Microsuck, so what did you really expect? What ya gotta do is *FORCE* your URL to end in .pdf so you can "fool" the IE browser into believing that the URL really really *IS* a static PDF file. The simplest way to do that is to take your existing script, which probably ends in .php or .htm, and rip off the .php or .htm part. Then, put something like this in your .htaccess file: <Files yourexistingscript> ForceType application/x-httpd-php </Files> That will force Apache to treat the file 'yourexistingscript' as a PHP file, even though it has no .php on the end. Then, when you use a URL (including one on the submit buttons inside your FDF files) you use something like this: http://example.com/yourexistingscript/phony.pdf IE, in its infinite wisdom, will "see" the 'phony.pdf' and say "Oh, that's a PDF file, I know what to do with that" Apache, knowing that no such file (phony.pdf) exists will fire up the script 'yourexistingscript' and, because of the .htacess setting, will pass it to PHP for processing. Meanwhile, your script will still use the correct HTTP headers to keep real browsers happy, and IE will be mind-numbingly stupid, as usual, but you've fooled it into getting 'phony.pdf' as far as Microsuck can tell. It's dumb enough to rely on the URL for content-type, so it's not real hard to fool it. You can, of course, replace 'phony.pdf' with whatever you want for a download name, and you can also access that part of the URL using various 'path_info' variables -- see phpinfo() and php.ini (register_globals et al) to determine/affect precisely which variables actually hold 'phony.pdf' for you. In addition, if you need to pass in variables, you can use, say: http://example.com/yourexistingscript/id/42/phony.pdf and do the exact same thing -- You'll need to tear apart /id/42/ from the 'pathinfo' to "GET" your variables, since they are not being passed in the usual GET/POST way, but that is relatively easy. Apache is going to mostly ignore (except for stuffing into 'pathinfo' the crap after 'yourexistingscript' -- Non-IE browsers will be using the Content-type: headers in accordance with the spec, and IE will be blindly reading the URL as if it were TRUTH. You could go whole-hog and get really complicated using mod_rewrite if you were feeling particularly masochistic. :-) Tip: rewrite_log is your buddy when trying to learn mod_rewrite, no matter how much it might slow your server down. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
