Working with Mark Smith an a context bundle I am trying to get the same html output as generated with the latex bundle but I am having troubles calling the PDF into the browser.
Here is what I have, a hack of the LaTeX bundle:
# PDF ConTeXt # Save Current File # Input=Entire Document # Output=Show as HTML
# this requires pdflatex Web2C 7.5.3 # Below are the instructions for the html output of the texexec run command
cat <<EOF <html><head><style> * { color: #998; } a { color: #000; text-decoration: none; } a:hover { color: #000; text-decoration: underline; } </style></head><body><pre> EOF
# below is the name for the temp file called by texexec tmp=`mktemp /tmp/texexecpdf_XXXXXXXX`
# If TM_LATEX_MASTER not set use TM_FILEPATH [ -z "$TM_LATEX_MASTER" ] && export TM_LATEX_MASTER="$TM_FILEPATH"
# Here is the actual command followed by the perl script to find the output. cd `dirname "$TM_LATEX_MASTER"` texexec --pdf --nonstop /tmp\ `basename ${tmp}` `basename "$TM_LATEX_MASTER"` \ | perl -pe '$| = 1; s/^(/.*?):(\d+):\s*(.*)$/<a href="txmt:\/\/open?url=file:\/\/$1&line=$2">$3</a>/'
# If PDF file exists and not empty, display it. This is were I loose it! [ -s ${tmp}.pdf ] && echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'${tmp}'.pdf">'
{ sleep 30; rm ${tmp} ${tmp}.*; } </dev/null >/dev/null 2>&1 &
The command runs fine and displays the log file as it should, but does not load the PDF. At the end of the context log, the output that texexec registers is: Output written on c_position_authority.pdf (1 page, 7354 bytes). This is the name I gave to the original file, not texexecpdf.xxxxxxxx. Should it be? Transcript written on c_position_authority.log.
return code : 0 run time : 2 seconds sorting and checking : running texutil
TeXUtil 9.0.0 - ConTeXt / PRAGMA ADE 1992-2004
action : processing commands, lists and registers option : sorting IJ under Y option : converting high ASCII values input file : c_position_authority.tui output file : c_position_authority.tuo
I am using Web2c 7.5.4 Any suggestions?
Thanks Robert
On Apr 5, 2005, at 19:08, Robert Ullrey wrote:
# If PDF file exists and not empty, display it. This is were I loose it! [ -s ${tmp}.pdf ] && echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'${tmp}'.pdf">'
The “[ -s <file> ]” tests for the existence of <file> AND that <file> has a size greater than 0. If this condition is true, it will perform the echo and output the redirect-line. A more verbose version would be:
if [ -s ${tmp}.pdf ]; then echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'${tmp}'.pdf">' fi
(I'm misusing the lazy/short-cut nature of the && operator as an if-statement)
The command runs fine and displays the log file as it should, but does not load the PDF. At the end of the context log, the output that texexec registers is: Output written on c_position_authority.pdf (1 page, 7354 bytes). This is the name I gave to the original file, not texexecpdf.xxxxxxxx. Should it be?
Well, the redirect (written using the echo) should at least point to the proper PDF file, the same goes for the if.
So I'm thinking the line should be something like: pdf=`basename "$TM_LATEX_MASTER"`.pdf [ -s $pdf ] && echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'$pdf'>'
On 06-04-2005, at 11:11, Allan Odgaard wrote:
The “[ -s <file> ]” tests for the existence of <file> AND that <file> has a size greater than 0. If this condition is true, it will perform the echo and output the redirect-line. A more verbose version would be: if [ -s ${tmp}.pdf ]; then echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'${tmp}'.pdf">' fi (I'm misusing the lazy/short-cut nature of the && operator as an if-statement)
This is so common as to almost be the-way-to-do-it(tm) :-p. Actually, didn't I alter this part of the script? Hmm.. don't remember, but I use that short-cut stuff as well.
Thanks Allan, but neither suggestion worked to get the pdf into the browser. I am still getting the output pdf as I should, the script just does not seem to see it. Not sure where the problem is. I'll look more this weekend.
Robert
On Apr 6, 2005, at 2:11 AM, Allan Odgaard wrote:
So I'm thinking the line should be something like: pdf=`basename "$TM_LATEX_MASTER"`.pdf [ -s $pdf ] && echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'$pdf'>'
if [ -s ${tmp}.pdf ]; then echo '</pre><meta http-equiv="Refresh" content="0;URL=file:///'${tmp}'.pdf">' fi
On Apr 7, 2005, at 19:04, Robert Ullrey wrote:
Thanks Allan, but neither suggestion worked to get the pdf into the browser. I am still getting the output pdf as I should, the script just does not seem to see it. Not sure where the problem is. I'll look more this weekend.
I'm currently having the problem that the HTML output refuses to follow any redirects to file:// which does cause a similar problem. This probably happened after one of the last system updates.
As a workaround I changed the redirect command to go through localhost like this:
[ -s ${tmp}.pdf ] && { cp "$tmp" ~/Sites/web_kit_workaround.pdf; chmod 666 ~/Sites/web_kit_workaround.pdf; echo "</pre><script>window.location='http://localhost/~%24USER/ web_kit_workaround.pdf'</script>"; }
Now it follows the redirect again, but unfortunately the PDF plugin doesn't work, it freezes after showing “Loading...”, but this is also the case when loading the PDF in Safari (and OmniWeb crashes). I did try the latest 2.2 of the plugin.
Well... hopefully the rumored native PDF capability in Tiger will make the actual rendering work. But I'm not sure what to do about not being able to do a file://-redirect.
On Apr 19, 2005, at 3:30, Allan Odgaard wrote:
As a workaround I changed the redirect command to go through localhost like this:
[ -s ${tmp}.pdf ] && { cp "$tmp" ~/Sites/web_kit_workaround.pdf; chmod 666 ~/Sites/web_kit_workaround.pdf; echo "</pre><script>window.location='http://localhost/~%24USER/ web_kit_workaround.pdf'</script>"; }
Ah, reading this again, the reason why the PDF plugin froze was that it wasn't the proper file I copied over as the PDF, should have been:
[ -s ${tmp}.pdf ] && { cp "${tmp}.pdf" ~/Sites/web_kit_workaround.pdf; chmod 666 ~/Sites/web_kit_workaround.pdf; echo "</pre><script>window.location='http://localhost/~%24USER/ web_kit_workaround.pdf'</script>"; }
Now it actually works again! :) Although still going through localhost.
Allan Odgaard wrote:
On Apr 7, 2005, at 19:04, Robert Ullrey wrote:
Thanks Allan, but neither suggestion worked to get the pdf into the browser. I am still getting the output pdf as I should, the script just does not seem to see it. Not sure where the problem is. I'll look more this weekend.
I'm currently having the problem that the HTML output refuses to follow any redirects to file:// which does cause a similar problem. This probably happened after one of the last system updates.
Hi
This happens on my system too - I believe the 10.3.9 update broke it (It contained a new Safari Version, and thus probably a new WebKit too, which I suppose the HTML-View is based on ;-) ).
Might this be a "security feature"? After all, it might not be unreasonable not to allow a web-page to redirect to a page on the client computer...
Maybe it's just a matter of telling the Webkit-View that the page it is displaying is to be trusted or something like that?
I'll try to put the html the pdf-preview-command is generating onto some webserver, and check if safari follows the redirect... I'll report back when I tried that out..
greetings, Florian Pflug
On Apr 19, 2005, at 9:45, Florian G. Pflug wrote:
This happens on my system too - I believe the 10.3.9 update broke it (It contained a new Safari Version, and thus probably a new WebKit too, which I suppose the HTML-View is based on ;-) ).
Yes, I saw your msg on IRC (after you left) :)
Might this be a "security feature"? After all, it might not be unreasonable not to allow a web-page to redirect to a page on the client computer...
I think it is meant as a security feature, maybe one can e.g. redirect an iframe to a local file and use Javascript/DOM to read the contents and post it to a server -- however, when the original file is also loaded from file:// (and in this case, even programmatically set) then I think it should be allowed.
Maybe it's just a matter of telling the Webkit-View that the page it is displaying is to be trusted or something like that?
There's no such API that I know of, but there is the ability to overload various steps of the page-loading process, so it might be possible for me to allow some way of redirection to local files.
I'll try to put the html the pdf-preview-command is generating onto some webserver, and check if safari follows the redirect... I'll report back when I tried that out..
I tested this, it works in OmniWeb but not Safari nor Firefox when I redirect to file://, if however I redirect to a custom URL scheme then it works for Safari. Also, Safari/webview refuses to follow any <a href="file://..."> or <form action="file://..."> (i.e. also when this is the output from a TextMate command).
Allan Odgaard wrote:
As a workaround I changed the redirect command to go through localhost like this:
[ -s ${tmp}.pdf ] && { cp "$tmp" ~/Sites/web_kit_workaround.pdf; chmod 666 ~/Sites/web_kit_workaround.pdf; echo "</pre><script>window.location='http://localhost/~%24USER/ web_kit_workaround.pdf'</script>"; }
Now it follows the redirect again, but unfortunately the PDF plugin doesn't work, it freezes after showing “Loading...”, but this is also the case when loading the PDF in Safari (and OmniWeb crashes). I did try the latest 2.2 of the plugin.
I changed it to just open the pdf in preview, using "open ${tmp}.pdf". It's not as nice as opening it in the same window, but generally prefer Preview over the PDF-Plugin for viewing pdfs, so I guess it's a draw ;-)
Well... hopefully the rumored native PDF capability in Tiger will make the actual rendering work. But I'm not sure what to do about not being able to do a file://-redirect.
I believe some tiger-featuer-list published by apple confirmed the pdf-viewing feature, so I'll only have to live with the workaround for two weeks ;-)
greetings, Florian Pflug
-
Allan Odgaard -
Florian G. Pflug -
Robert Ullrey -
Sune Foldager