Comments are inline preceded with '>>'.
-----Original Message-----
From: Hussein Shafie [mailto:[email protected]]
Sent: Friday, April 24, 2009 5:50 AM
To: Clark Karr
Cc: xmleditor-support at xmlmind.com
Subject: Re: [XXE] Detecting a locked PDF file
Clark Karr wrote:
> Rishi's comments are, in my opinion, correct. Assuming the typical XXE
user
> is intelligent but lacks expertise in technical details (or is
uninterested
> in learning these technical details), these error message(s) are cryptic,
> contain too much information, and don't guide the user to a solution.
>
> My users run into this problem frequently.
Please note that this problem is specific to Windows and cannot happen
on Linux and on the Mac.
>> While I'm all for abandoning Windows for Linux, some of my authors (the
least technically savvy) use Windows and I can't seriously ask them to
either switch to Linux or use a dual boot approach. My technically savvy
authors work in Linux already on dual boot machines.
> I've had to include in the
> training material a statement to the effect, "If XXE fails to generate pdf
> after the first successful generation, close the file in pdf viewer."
>
Thank you for this feedback.
> Anything that takes the user out of the primary job of writing should be
> minimized. These 'context switches' are mentally disruptive and reduce
> productivity.
>
> To that end, please consider:
> 1. Have the pdf generation process check before generating the pdf and
> tell the user "Cannot generate pdf until the pdf file is closed in pdf
> viewer" or words to that effect.
We currently don't know how to detect this case, but may be we'll find a
way.
>> Well, an inelegant way would attempt to open, lock, and write an empty
'test file' to the target file. To protect the target file, you could copy
and write it to a 'save' file like XXE does with files being edited (the
file extension has '~' appended to it). Simply trying to read the file to
create the copy might detect the lock.
You could use the target file as the 'test file'. So the scheme could
be open, lock, copy <filename>.pdf to <filename>.pdf~, and write
<filename>.pdf~ to <filename>.pdf. Problems along the way are reported to
the user and stops the pdf conversion process (It's going to fail on the
write anyway, so why proceed?).
I don't know about java file ('streams' really: see java.io) handling
capabilities, but I expect there's more elegant support for checking file
status.
> 2. Include a 'friendly' pdf viewer in XXE. That way, the user wouldn't
> have to switch between applications and the pdf viewer pane/tab could use
a
> 'refresh/redraw' strategy (instead of locking the file) to 'play nicely'
> with the editing panes/tabs.
>
This is a very high-end approach, may be even a bit overkill, but why
not? Can you recommend a 100% Java PDF viewer component?
>> Just use your browser to search for 'java pdf viewer' to get some
candidates. For example, https://pdf-renderer.dev.java.net/ claims "a 100%
Java PDF renderer and viewer".
