[texworks] SCRIPTING: get current poppler page number

Reinhard Kotucha reinhard.kotucha at web.de
Wed Oct 20 23:22:29 CEST 2010

On 20 October 2010 Bruno Voisin wrote:

 > Le 20 oct. 2010 à 14:47, Paul A Norman a écrit :
 > > http://code.google.com/p/texworks/issues/detail?id=261&can=5#c35
 > > 
 > > Here is a simplistic scripting implementation of a suggestion by Bruno
 > > to look at using pdfopen. Could use pdfclose if that is needed as
 > > well.
 > Credit to whom credit is due: this was Reinhard's suggestion, not
 > mine (I was not even aware of the existence of pdfopen and pdfclose
 > in TeX Live beforehand).
 > That said, on Mac OS X pdfopen does not work. Typing "pdfopen
 > somefile.pdf" in Terminal launches X11 then yields
 > 	pdfopen: acroread startup failed

Hi Bruno,
under Linux it doesn't work either for me.  pdfopen starts AR and
opens the PDF file.  pdfclose doesn't have any effect.  Subsequent
invocations of pdfopen fork new AR processes and open the file again.
I don't know why it forks at all.

However, the implementation of these programs seems to be completely
different on Windows.  There isn't even a fork() system call and the
Windows version is using DDE for inter process communication while, as
far as I understand, the Unix version uses X11 facilities.

Though I can't test anything on Windows, a friend of mine told me that
he's using pdfopen/pdfclose on Windows and that they work well.  But I
don't know *how* he uses them.  Anyway, they should do something
sensible when invoked from the command line.

The problem on Windows is the file system.  If a file is opened by a
program, the program has to be able to access the meta data of the
file, i.e. the size, time stamps, a pointer to the actual data blocks,
and so on.  This has to be accessible until the file is closed.

On Unix all meta data are stored in dedicated data blocks called
inodes.  The directory only contains the file name and the associated
inode number.  Once a file is opened, the directory entry isn't needed
anymore.   Hence you can delete a file while a process is using it.
Deleting a file on Unix means to remove the directory entry.  If you
create a new file with the same name, a new directory entry is created
and associated with another inode.  The other inode will be marked as
unused if the last process accessing it finishes.

In other words, if AR is displaying a file, TeX can delete it and
create a new one.  If you press "Reload" in the "File" menu, AR closes
the old file.  It will be deleted forever unless any other process is
accessing it.  Then the open() system call associates the file name
with the inode number of the newly created file and you see the result
of the last TeX run.

On Windows, however, file meta data are stored in the directory
itself.  This means that a file can't be removed while a process is
using it.  Thus, Windows locks files which are in use.  I suppose that
NTFS is better in this respect, but it's well known that Microsoft
doesn't support all of its features yet.

Though pdfopen/pdfclose are not as important on Unix as they are on
Windows, it would be nice if they work as expected there too.  On OS X
the situation is a bit difficult because X11 is just an add-on and
AFAIK is not always installed.

I must admit that I don't know who is maintaining the programs, but I
suppose that the Windows version in TeX Live is maintained by Akira.


Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the texworks mailing list