[XeTeX] Low-level diagnostic ("fwrite") generated by XeTeX
Keith J. Schultz
keithjschultz at web.de
Wed Feb 3 08:08:04 CET 2010
As Jonathan said there has to be some better
error handling here.
The questions are:
1) what is returned by the different processes
2) should something different be returned
3) is a processs not checking the exit code?
From what a have read it seems that XeTex already has
a file handle and tries to send data to it, but gets told it can not!
So how did XeTex get this handle in the first place or did it
become invalid after being passed on?
For me it is a bug, because the handle should be check once it comes
back or when it was created.
Am 02.02.2010 um 19:59 schrieb Philip TAYLOR:
> Khaled Hosny wrote:
>> Since, AFAIK, Adobe Reader doesn't change files (it is a reader not
>> writer), it shouldn't lock the file in the first place. This what other
>> document viewers (Evince here) does, actually it also recognize that the
>> file has been updated and reload it.
> Although I have some understandable sympathy with this perspective,
> I should just clarify that the file was open in <stress>Adobe
> Acrobat</>, not Acrobat Reader, so it is quite understandable
> that the former should lock the file as it is potentially
> modifiable by the application. But as I said in my earlier
> response to Ross, I don't think this is the issue : XeTeX,
> as Jonathan had already agreed, should be more robust when
> encountering such an error and not fall back on a low-level
> ** Phil.
> Subscriptions, Archive, and List information, etc.:
More information about the XeTeX