Enrico Forestieri wrote:
On Fri, Jul 11, 2008 at 05:55:31PM -0400, Paul A. Rubin wrote:
This came up on the user list. I'm not sure if it needs to go into
bugzilla, so I'm looking for opinions. (I didn't find this in either
bugzilla or the wiki.)
On Windows, user specifies PDF (pdflatex) viewer as acrord32.exe. View
-> PDF (pdflatex) runs pdflatex, but no Acrobat Reader window opens.
Task Manager shows a copy of AR running (and eating a lot of CPU cycles)
but without a window. You have to kill it. Turns out the problem is
that LyX is passing the path to the file as "C:/whatever", nicely
wrapped in quotes to preserve spaces but with Unix-style (maybe I should
say real-world style) path separators. If you intercept the path and
reverse the separators, things work ok.
The easiest workaround, assuming the user wants AR to be their PDF
viewer, is to put it on the system path and use 'auto' as the viewer.
Maybe the best solution is to put that on the wiki? I'm a bit leery
about things that innocently can create windowless CPU-gulping children,
though.
Thoughts?
This one seems to be another Windows idiosyncrasy. I had already
observed a strange behavior with permissions. For example, ttf
fonts are ignored if they don't have the executable bit set.
In this case, it seems there is some other strange problem with permissions,
rather than the use of '\' or '/' as path separator. I did the following
test. Started lyx and previewed a new file through "View->PDF (pdflatex)".
The file was shown in AcroRd32. Then, without quitting lyx, I tried to
view the very same file through the command
$ AcroRd32.exe "C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf"
AcroRd32 ran and was consuming cpu cycles, but nothing showed up. I killed it.
Now I did:
$ mv "C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf"
"C:/tmp/lyx_tmpdir848a00800/newfile1.pdf"
$ AcroRd32.exe "C:/tmp/lyx_tmpdir848a00800/newfile1.pdf"
and AcroRd32 hung again. However, after
$ mv "C:/tmp/lyx_tmpdir848a00800/newfile1.pdf" "C:/tmp/newfile1.pdf"
$ AcroRd32.exe "C:/tmp/newfile1.pdf"
AcroRd32 came up showing the file.
So, there's something in the permissions of the lyx tempdir preventing
AcroRd32 from showing the file when using '/' as a separator.
Instead, why it indeed works when using '\' really escapes me.
I had already stopped trying to find rational explanations about Windows
behavior long ago.
This is more irrational (or at least irregular) than I thought. I get
somewhat different behavior repeating your experiment on Win XP (Home).
I wonder if any of that is related to non-M$ software (I have bits of
GnuWin32 installed, but not Cygwin, on this machine). Repeating your
experiment:
1. AcroRd32 applied to "/Documents and
Settings/.../lyx_tmpbuf0/mydoc.pdf" displays the document in Reader.
2. AcroRd32 applied to "/temp/mydoc.pdf" or "/temp/.../mydoc.pdf"
starts Reader, but Reader displays a "file cannot be found" message.
3. AcroRd32 applied to "C:/Documents and
Settings/.../lyx_tmpbuf0/mydoc.pdf" or "C:/temp/mydoc.pdf" causes a
windowless Reader to eat CPU cycles.
So at least on my machine, mixing the drive letter "C:" with Unix-style
separators causes the bug, regardless of where I put the file (hence not
a permissions issue), while using Unix-style separators but not the
drive letter works in the lyx buffer but not anywhere else.
(Incidentally, I was doing this from a DOS prompt in an unrelated
directory (C:\WINDOWS). I also tried closing LyX, reopening (so the
temp directory changed) and repeating, and it still displayed
"/Documents .../mydoc.pdf" correctly. I thought maybe that had to do
with the fact that it had already been opened once (by LyX), so I
double-clicked the copy under C:\temp to display it, closed that and
tried "/temp/.../mydoc.pdf" again -- and again got the file not found
error. I have no clue whatsoever as to why the one in the local temp
path can be opened using Unix slashes and no drive letter.
For users who have Reader as their default viewer, the 'auto' setting
should work. If anyone wants to have a different default viewer but
still have a View option that uses AR, I suspect a script is going to be
needed.
/Paul
