I notice on some browsers that when you use a cgi app like texis to display pdf files there is a problem with display (doesn't display!) in the pdf plugin. Whereas if you open the same file using a file path, there is no problem.
I use a function in a vortex script to display pdf files with a .pdf extension instead of .html. I assume all the correct http headers are being sent when I do this and in fact, most browser versions work. Is there anything I can do in vortex or is this a "bug" in acrobat?
How are you sending the file? Perhaps the method you are using is somehow mangling it. To send a file from the filesystem use <spew>. To send a binary field from a database field use <fmt "%s" $fieldname>.
You can check your headers with the geturl utility included with Texis.
geturl http://yoururl | more
I didn't use <spew> I just checked using an absolute file path from the doc root, ie texis was not involved in this transaction at all. (http://mysite/myfile.pdf)
I wonder if the acrobat plugin does something different when you send content headers versus just loading the file from the web server. I just don't know enough about the different way the web server interacts with the browser in this situation as opposed to a cgi interaction.
If done properly, there should be no difference that acrobat could detect between a webserver file fetch and webserver cgi spew. If your function is called with a .pdf extension vortex should set the mime type correctly. If it's not for some reason use the <header name="Content-Type" value="application/pdf"> call to force it.
Where did $PDF come from? A field? If so, what type?
Try both ways (working and nonworking) with geturl and compare the output.
