Bo Peng wrote:
X86-64 is the only processor which do this trick though. Alpha,
powerpc and others really have no acrobat at all. Not that it
matters much, there being other reasons for using other viewers.
On my rhel4 x86, I tried to use ggv, xpdf and acrobat to print a file.
ggv printed only
X86-64 is the only processor which do this trick though. Alpha,
powerpc and others really have no acrobat at all. Not that it
matters much, there being other reasons for using other viewers.
On my rhel4 x86, I tried to use ggv, xpdf and acrobat to print a file.
ggv printed only the first page
Bo Peng wrote:
This trick works with windows as well as linux, and of course such
scripts
could be distributed with lyx.
Are you sure about this part? This is not as simple as a script, we
need pdfopen.exe, pdfclose.exe to track the process id of acrobat
reader and re-open it if necessary. I s
TechTonics wrote:
> This trick works with windows as well as linux, and of course such
> scripts could be distributed with lyx.
BO: Are you sure about this part? This is not as simple as a script,
we need pdfopen.exe, pdfclose.exe to track the process id of acrobat
reader and re-open it if nec
Several people have mentioned that there is no acrobat reader for
x86-64 systems. This is not the case. The acrobat reader rpm works
just fine. Maybe it is not in 64 bit, but it runs well.
Bo
This trick works with windows as well as linux, and of course such scripts
could be distributed with lyx.
Are you sure about this part? This is not as simple as a script, we
need pdfopen.exe, pdfclose.exe to track the process id of acrobat
reader and re-open it if necessary. I seriously doubt th
Bo Peng wrote:
> That is for acrobat reader only, and under windows only. Using
> different temp files will solve the problem for all potential viewers,
> under all OSs.
The problem exists only under Windows.
It is maybe acrobat reader only, but it is even worse under linux.
That is to say:
1
John McCabe-Dansted wrote:
On 8/9/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
If we use a different temp file each time, how do we know
when we can delete it?
What if we attempt to delete each old version of the temp file each
time we create a new one? That way we do not proliferate o
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> For ghostscript:
Bo> 1. view ps (kghostview is started) 2. modify file 3. update pd ==>
Bo> does not work.
The setting 'Watch File' helps here.
JMarc
> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
John> On 8/9/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
>> If we use a different temp file each time, how do we know when we
>> can delete it?
John> What if we attempt to delete each old version of the temp file
John> each t
On Sat, Aug 19, 2006 at 12:11:55PM +0200, Andre Poenitz wrote:
> On Thu, Aug 10, 2006 at 01:31:42PM +0200, Helge Hafting wrote:
> > Do you really want more and more acrobat windows cluttering your
> > screen each time you do a new preview?
>
> Uh... I know that I want such behaviour sometimes to v
For DVI files the dvi viewer automatically reloads the file, but keeps
the same page open etc. This behaviour can be handy. Perhaps it should
be configurable per viewer?
Isn't that the task of view->update->dvi? This actually confirms my
belief that view should use a different name.
For DVI:
1
On 8/9/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
If we use a different temp file each time, how do we know
when we can delete it?
What if we attempt to delete each old version of the temp file each
time we create a new one? That way we do not proliferate old temp
files unless we know
> That is for acrobat reader only, and under windows only. Using
> different temp files will solve the problem for all potential viewers,
> under all OSs.
The problem exists only under Windows.
It is maybe acrobat reader only, but it is even worse under linux.
That is to say:
1. under windows:
On Tue, Aug 08, 2006 at 06:32:10PM -0500, Bo Peng wrote:
> It is pretty annoying to me that I can not preview a document if a
> previous version is being previewed so the file can not be
> overwritten. What prevents us from using a different temp file each
> time? (I remember that there is even a t
On Wed, Aug 09, 2006 at 10:35:18AM -0500, Bo Peng wrote:
> >Asger posted some code last June that would enable you to write a wrapper
> >for
> >Acrobat that would obviate the problem. See:
> >
> >http://thread.gmane.org/gmane.editors.lyx.devel/46077
>
> That is for acrobat reader only, and under
On Thu, Aug 10, 2006 at 01:31:42PM +0200, Helge Hafting wrote:
> Do you really want more and more acrobat windows cluttering your
> screen each time you do a new preview?
Uh... I know that I want such behaviour sometimes to viually compare two
versions of the same doc.
Andre'
Am Donnerstag, 10. August 2006 17:50 schrieb Paul A. Rubin:
> Bo Peng wrote:
> >> Perhaps the Windows
> >> installers could offer to install them (and recognize them as the
> >> default viewer for PDF formats if installed)?
> >
> > Currently, lyx uses the default pdf viewer of windows by default.
On Thursday 10 August 2006 12:38, Helge Hafting wrote:
> There is
> no acrobat reader for 64-bit linux, but xpdf is open source so
> it exists and works for every linux there is.
Just to add, don't forget that there is no acrobat reader for linux ppc, or
any other arch you choose.
--
José Abí
Bo Peng wrote:
Perhaps the Windows
installers could offer to install them (and recognize them as the
default viewer for PDF formats if installed)?
Currently, lyx uses the default pdf viewer of windows by default.
Users will have to set them manually after lyx is installed.
True, but that's b
Bo Peng wrote:
Can anyone confirm this problem? (linux)
1. open lyx,
2. type a
3. pdflatex preview
4. type b
4. pdflatex preview
the /tmp//newfile1.pdf is successfully re-generated (tested using
xpdf), but "acroread /tmp/.../newfile1.pdf" will not do anything since
acrobat reader thinks the
Bo Peng wrote:
Asger posted some code last June that would enable you to write a
wrapper for
Acrobat that would obviate the problem. See:
http://thread.gmane.org/gmane.editors.lyx.devel/46077
That is for acrobat reader only, and under windows only. Using
different temp files will solve the pr
Can anyone confirm this problem? (linux)
1. open lyx,
2. type a
3. pdflatex preview
4. type b
4. pdflatex preview
the /tmp//newfile1.pdf is successfully re-generated (tested using
xpdf), but "acroread /tmp/.../newfile1.pdf" will not do anything since
acrobat reader thinks the file is not cha
Perhaps the Windows
installers could offer to install them (and recognize them as the
default viewer for PDF formats if installed)?
Currently, lyx uses the default pdf viewer of windows by default.
Users will have to set them manually after lyx is installed.
Bo
There are plenty of alternatives (e.g. XPDF and KPDF on Linux), which behave
better than acroread.
I have tried all of them, and I have to say that they are not as
capable as acrobat reader.
MikTeX has the pdfopen and pdfclose scripts which work around that exact
problem. They also have been
The problem exists only for acrobat and only under Windows. Nobody has
complained about LyX's behaviour in this regard in 10 years of existence. That
suggests that people like LyX's behaviour.
This problem also happens for acrobat reader under linux.
If you want to compare to previous versions
Juergen Spitzmueller wrote:
MikTeX has the pdfopen and pdfclose scripts which work around that exact
problem. They also have been ported to Linux AFAIK.. People who insist on
acroread should use this.
I use those scripts, and there's no down side to them AFAIK (other than
a lack of awareness
Bo Peng wrote:
> Well, this is the _one_ most important viewer we are forced to use.
There are plenty of alternatives (e.g. XPDF and KPDF on Linux), which behave
better than acroread.
MikTeX has the pdfopen and pdfclose scripts which work around that exact
problem. They also have been ported to
Bo Peng <[EMAIL PROTECTED]> writes:
JMarc> And changing this type of thing just because of _one_ piece
JMarc> of poorly written software is a bit annoying.
Bo> Well, this is the _one_ most important viewer we are forced to use.
It seems to me that your statement above renders your earlier point r
/tmp is not cleaned when LyX dies brutally.
Lyx can not be blamed for this. Actually, we recently cleaned our
network disk and found gigabytes of uncleaned temp files of SAS since
users get used to Ctrl-c this poor application ...
If you are really concerned with disk space, at least we can try
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Donot we remove all lyx tmp folder for each session?
>> Yes, but what if you do many previews in a same session?
Bo> Then there will be a lot of temp files under this lyx tmp
Bo> directory. If lyx quits normally (hopefully also when lyx is
Bo
Asger posted some code last June that would enable you to write a wrapper for
Acrobat that would obviate the problem. See:
http://thread.gmane.org/gmane.editors.lyx.devel/46077
That is for acrobat reader only, and under windows only. Using
different temp files will solve the problem for all pot
Bo> Donot we remove all lyx tmp folder for each session?
Yes, but what if you do many previews in a same session?
Then there will be a lot of temp files under this lyx tmp directory.
If lyx quits normally (hopefully also when lyx is killed by Ctrl-C),
they will all be cleaned; otherwise, we dep
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> >> Then you have a broken viewer. Get one that doesn't mind having the
> >> viewed file overwritten.
> Bo> This happens to acrobat viewer. This is easy to confirm: open lyx,
> Bo> type a, view pdflatex, type b, view pdflatex, lyx says I cannot
> B
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Then you have a broken viewer. Get one that doesn't mind having the
>> viewed file overwritten.
Bo> This happens to acrobat viewer. This is easy to confirm: open lyx,
Bo> type a, view pdflatex, type b, view pdflatex, lyx says I cannot
Bo> write
Then you have a broken viewer. Get one that doesn't mind
having the viewed file overwritten.
This happens to acrobat viewer. This is easy to confirm: open lyx,
type a, view pdflatex, type b, view pdflatex, lyx says I cannot write
on file 'newfile1.pdf'.
A workaround if you can't fix the view
Bo Peng wrote:
Hi,
It is pretty annoying to me that I can not preview a document if a
previous version is being previewed so the file can not be
overwritten. What prevents us from using a different temp file each
time? (I remember that there is even a trick in lyx wiki to address
this problem.)
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Hi, It is pretty annoying to me that I can not preview a document
Bo> if a previous version is being previewed so the file can not be
Bo> overwritten. What prevents us from using a different temp file
Bo> each time? (I remember that there is ev
Hi,
It is pretty annoying to me that I can not preview a document if a
previous version is being previewed so the file can not be
overwritten. What prevents us from using a different temp file each
time? (I remember that there is even a trick in lyx wiki to address
this problem.)
Bo
39 matches
Mail list logo