[texhax] adobe 10

[Philipp Stephani]

Am 29.05.2011 um 01:26 schrieb Reinhard Kotucha:

> On 2011-05-28 at 19:38:05 +0200, Philipp Stephani wrote:
> 
>> It is not necessary to lock open files on Windows, and race
>> conditions can always occur when write access to a shared resource
>> is not protected.
> 
> You mean that if AR has a file opened and you run TeX in order to
> replace this file, AR sees the new file then?  Then it would crash, of
> course. 

Or do something more sensible, e.g. showing blank pages, which is exactly what auto-reloading viewers like Evince do.

> 
>>> AR doesn't lock files on Unix.  You can have a file opened in AR
>>> while TeX is creating a new one.  AR displays the old one until
>>> you explictly reload the file.  Applications don't have to be
>>> prepared for that.
>> 
>> It has to be prepared not to read from the file while it's being
>> written.
> 
> Why?  As I said before, a file exists even after it has been deleted.
> It exists until the last process accessing it dies.  AR can read from
> an already opened file whenever it wants, regardless of whether TeX
> created a new, incompatible, version of a file with the same name.
> There are actually two distinct files, though only one of them has a
> name (a directory entry).
> 
> If you want AR to display the newly created file, you have to close
> the old file (which still exists) *explicitly* and open the file again.
> There is absolutely nothing a programmer has to take care about.
> 
> For instance, when I update the C runtime library, all processes
> started before the update are still using the old version, all
> processes started after the update are using the new version.
> Similarly, if I update Apache while it's running, the update has no
> effect until I explicitly re-start Apache again.
> 
> I hope this makes things a bit clearer.

This is not relevant here since AFAIK no TeX engine deletes the destination file before creating it. Unless you delete the file, you have only one file, and the viewer is reading the same file that the engine is writing.

> 
>>> Regarding Windows: If you think that Adobe is the culprit, then
>>> please tell them what they are doing wrong.
>> 
>> They are opening the file without sharing enabled. 
> 
> What does "without sharing enabled" mean technically?

Not passing the FILE_SHARE_WRITE flag in the third argument to CreateFileW.

> 
>> I don't know why they are doing that, but this article indicates
>> that locking was not present in early versions of AR, and therefore
>> it is probably intentional:
>> http://www.planetpdf.com/forumarchive/134906.asp
> 
> I suppose that under Windows, if TeX creates a newer version of the
> file, the old one is not preserved and AR sees the new one while it
> still has parts of the old version in memory.  This can't work and AR
> will crash then, of course.  In this case it's indeed best to lock the
> file.

This happens on all systems.

$ open -a 'Adobe Reader' texput.pdf 
$ lsof texput.pdf 
COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
AdobeRead 10134 philipp    9r   REG   14,2     8175 21807894 texput.pdf
$ pdftex
This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010)
**\null\vfill\eject
entering extended mode
[1{/usr/local/texlive/2010/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
*^Z
[1]+  Stopped                 pdftex
$ lsof texput.pdf 
COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
AdobeRead 10134 philipp    9r   REG   14,2      130 21807894 texput.pdf
pdftex    10154 philipp    4w   REG   14,2      130 21807894 texput.pdf
$ 

Note that the file is opened twice, and it is the same file.

> 
> I could imagine workarounds, but they are quite painful to implement
> and if the old and new version of a PDF file don't exist both at the
> same time, AR has to be frozen completely while TeX is running, which
> certainly confuses users.

No, many other PDF viewers implement workarounds: they just show blank pages if a page or document is invalid.

>>> I don't know why everybody is blaming Adobe for the file locking
>>> mess.
>> 
>> I don't know why everybody is blaming Microsoft for the file
>> locking mess, given that is is perfectly valid to open a file
>> without locking on Windows, and that it's purely the choice of the
>> application developers whether they want locking or not, and there
>> exist many applications that avoid locking open files or keeping
>> them open all the time.  
> 
> See above.  I'm not blaming Microsoft because AR locks the files.  The
> question is whether programs work properly under Windows if files are
> _not_ locked.

Depends on the programs. If files are not locked, then concurrent reads/writes must be handled appropriately. Again, nothing related to Windows.
You are constantly assuming that there is some behavior of Windows that would cause problems without locking. I wouldn't rule out that possibility, but I think you have to provide more evidence than just one application that behaves differently. One could imagine many reasons why AR chooses to lock files on Windows, but not on Unix-like systems: maybe they just didn't know about how to do it?

>  I think that you can't blame Adobe for the
> inconveniences if the locks are necessary under Windows (even though
> they can be turned off).

I don't blame AR because the TeX community is irrelevant to them. Normal users just don't have PDFs that change while viewing, so from Adobe's point of view it is not relevant whether files are locked or not. Perhaps they just didn't read the documentation and passed 0 as the third argument, which enables all locks.

>> The solution to all this (using Sumatra PDF) has already been
>> posted, so I don't see much reason to continue this thread.
> 
> It's not a solution at all, sorry.  Does Sumatra PDF support
> animations, movies, JavaScript, layers, interactive 3D graphics,
> attachments, and so on?  All this is already supported by pdftex since
> it exists, i.e. for more than a decade.  Most PDF viewers are not even
> able to display the documentation of the respective LaTeX packages
> properly, hence people using crippled viewers don't even notice what
> they are missing.
> 
> Sorry, but PDF is by far much more than DVI with hyperlinks.
> 
> I can only recommend to use a PDF viewer which actually supports PDF,
> even if it's a bit clumsy and only free in the sense of free beer.

So you're supporting a non-free software monopoly? ;-)
Yes, PDF supports 3D graphics, JavaScript, etc., but I don't think it is the right format for these gadgets. Adobe apparently wants to create a competitor to HTML, but in essence PDF (at least most PDF documents I've encountered) is still a static, page-oriented format primarily intended for printing. I think we don't need videos etc. in PDF because we have HTML. HTML is the only document format that everybody agrees upon, its possibilities are endless, and it extends its scope at a tremendous pace. In fact, if I could, I'd dump PDF today in favor of HTML.