From: Merciadri Luca on
Mihamina Rakotomandimby wrote:
>> Merciadri Luca <Luca.Merciadri(a)student.ulg.ac.be> :
>> Andrei Popescu wrote:
>>
>>> I thought that was a limitation of the OS (Windows).
>>>
>>>
>> I don't know. Maybe.
>>
>>
>
> It *_IS*_
>
Okay. Sorry, Windows constitute bad memories for me, nothing more. And I
tend to forget bad memories to let some place for better stuff.

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


Don't fall before you're pushed.

From: Merciadri Luca on
Sjoerd Hardeman wrote:
> Op 13-05-10 23:40, Merciadri Luca schreef:
>
>> Sven Joachim wrote:
>> Thanks for this answer. There are *many* reasons not to use pdfLaTeX.
>> They do not enter in the scope of this mailing list, but I am pretty
>> sure you will find them directly on the Internet. For example, pdfLaTeX
>> encourages one to use directly JPG, etc., for the inclusion in the
>> document, which is pretty bad. There are also many incompatibilities
>> with different packages.
>>
> Or png or pdf which basically is eps or even real eps via the epstopdf
> package.
>
/
> Sorry, pdflatex offers more choice. That's not a bad thing.
>
I do not agree, sorry. PDFLaTeX generally write bigger PDFs, simply
because there is no compression (consider for example
http://www.tug.org/pipermail/pdftex/2004-June/005046.html). Moreover, I
think that psTricks does not work with PDFLaTeX (you need to use PDFTricks).

I also vaguely remember about many situations where, if I had had to use
PDFLaTeX, I would not have been able to produce the same document,
because I would have had to change many packages which were incompatible.

You might ask on comp.text.tex, this is a better place for this, because
this is my point of view, and it is not shared by the whole community.

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


Instruction ends in the schoolroom, but education ends only with life.
(F. W. Robertson)

From: Erik Heil on
Hi,
The problem here is that Windows has problems in implementing
"propper" file locking symantics. On the side of acroread.exe, it
should not assume documents are static on disk. Not sure if something
like file alteration monitor exists on Windows. What is needed is a
cross-platform FAM-like library. Any suggestions?

Erik Heil
<eheil1(a)gmail.com>

On 5/13/10, Merciadri Luca <Luca.Merciadri(a)student.ulg.ac.be> wrote:
> Sven Joachim wrote:
>> On 2010-05-13 17:04 +0200, Merciadri Luca wrote:
>>
>>
>>> When compiling any .tex document using the route latex -> dvips ->
>>> ps2pdf, I get a PDF.
>>>
>>
>> This is a rather clumsy way these days. Why don't you use pdflatex?
>>
>>
>>> Normal, but the problem is that if I the PDF is
>>> already opened (e.g. because I was reading the version of the document
>>> before having modified and compiled it) when the compilation and the
>>> whole process ends, the opened PDF is blank, i.e. the current page
>>> becomes white, and every page I go at is white.
>>>
>>
>> The changes in the file seem to confuse acroread. At least it does not
>> crash.
>>
>>
>>> If I then re-open the
>>> document, I find the new version of my PDF.
>>>
>>
>> A smart reader would have an option to detect changes to the file and
>> reload it automatically. Since I haven't used acroread for ages I don't
>> know whether it has such an option.
>>
>>
>>> I would like to know how this process actually works. For me, it looks
>>> like the ps2pdf tool creates the PDF from scratch, and overwrites the
>>> old PDF.
>>>
>>
>> A quick experiment shows that this does not seem to be the case, ps2pdf
>> writes to the existing file.
>>
>>
>>> But why am I receiving no warning message from acroread?
>>>
>>
>> Ask Adobe…
>>
>>
>>> Anyway, acroread seems not to be locking the file, or, if so, ps2pdf
>>> forces the writing.
>>>
>>
>> I would be rather annoyed if a reader locked a file that it does not
>> even open for writing.
>>
> Thanks for this answer. There are *many* reasons not to use pdfLaTeX.
> They do not enter in the scope of this mailing list, but I am pretty
> sure you will find them directly on the Internet. For example, pdfLaTeX
> encourages one to use directly JPG, etc., for the inclusion in the
> document, which is pretty bad. There are also many incompatibilities
> with different packages.
>
> Note that, under Windows, I remember that acrord32.exe always blocked
> the file for writing, even if it was only being read by acrord32.exe.
> Okay, it's Windows. Bad memories.
>
> --
> Merciadri Luca
> See http://www.student.montefiore.ulg.ac.be/~merciadri/
> I use PGP. If there is an incompatibility problem with your mail
> client, please contact me.
>
>
> What doesn't kill you will make you stronger. (Friedrich Nietzsche)
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTimza2PO6g_7aDaRh0Nd0qjbdl283hswYOzZg79H(a)mail.gmail.com
From: Mark Allums on
On 5/14/2010 2:41 AM, Andrei Popescu wrote:
> On Thu,13.May.10, 23:40:51, Merciadri Luca wrote:
>>
>> Note that, under Windows, I remember that acrord32.exe always blocked
>> the file for writing, even if it was only being read by acrord32.exe.
>> Okay, it's Windows. Bad memories.
>
> I thought that was a limitation of the OS (Windows).
>
> Regards,
> Andrei

I believe SOP on Windows is to always use a working copy, not the
original file. When it is time to exit the application, the working
copy is "moved" onto the original. The OS handles the move, and how
Windows actually does that is something I'm not familiar with.

Saving a file does not necessarily overwrite the original file. Instead,
the changes are written to the working copy. It is a matter of policy,
so different programs can act differently. When the file is closed,
though, the saved changes are made permanent.

So, this OS "limitation" is a matter of differing philosophies. To get
a certification of "Made for Windows", certain practices must be adhered
to. A lesser certification "Works with Windows" is also available.

In other words, the behavior of an application is still up to the author
of the program, in spite of the monopolistic tendencies of Microsoft.
Increasingly, though, programmers must jump through lots of hoops to get
the behavior they want.

One common bad behavior of Windows apps is opening a file and never
closing it. It remains open until the person editing it closes it in
the app. This causes files to remain blocked for the duration and leads
to all manner of disasters. It the event of a serious crash, all those
open files become casualities. (Which is one reason why the practice
of using working copies is so prevalent.)

I find it interesting that Acroread's behavior is different in Linux.
The programmers of the Linux version seem to be aware of *nix standard
practice. This is a good thing, I think.


MAA



--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BED4C94.4070802(a)allums.com
From: Merciadri Luca on
Mark Allums wrote:
> On 5/14/2010 2:41 AM, Andrei Popescu wrote:
>
> I believe SOP on Windows is to always use a working copy, not the
> original file. When it is time to exit the application, the working
> copy is "moved" onto the original. The OS handles the move, and how
> Windows actually does that is something I'm not familiar with.
>
> Saving a file does not necessarily overwrite the original file.
> Instead, the changes are written to the working copy. It is a matter
> of policy, so different programs can act differently. When the file
> is closed, though, the saved changes are made permanent.
>
> So, this OS "limitation" is a matter of differing philosophies. To
> get a certification of "Made for Windows", certain practices must be
> adhered to. A lesser certification "Works with Windows" is also
> available.
>
> In other words, the behavior of an application is still up to the
> author of the program, in spite of the monopolistic tendencies of
> Microsoft. Increasingly, though, programmers must jump through lots of
> hoops to get the behavior they want.
>
> One common bad behavior of Windows apps is opening a file and never
> closing it. It remains open until the person editing it closes it in
> the app. This causes files to remain blocked for the duration and
> leads to all manner of disasters. It the event of a serious crash,
> all those open files become casualities. (Which is one reason why
> the practice of using working copies is so prevalent.)
>
> I find it interesting that Acroread's behavior is different in Linux.
> The programmers of the Linux version seem to be aware of *nix standard
> practice. This is a good thing, I think.
I totally agree with you. I was so suprised that acroread shown no error
under Linux that I thought there was a bug. It often happens to modify a
PDF and compile the source files, having forgotten the fact that the PDF
viewer is still open with the PDF. I remember that when doing the whole
process: latex -> dvi2ps -> ps2pdf under Windows, it was frustrating to
notice (too late) that the PDF was still open in a window when ps2pdf
wanted to replace it.

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.