Re: Xpdf fuckware
On Fri, 16 Mar 2001, Ralph Jennings wrote:
> On Fri, Mar 16, 2001 at 03:59:43PM +0100, Marcus Brinkmann wrote:
> > I agree wholeheartedly. I think that those bits convey some information that
> > might be useful to some, though. In my opinion, the best solution in function
> > and design would be to have some display for these bits (for example a small
> > text box "protected" or something appropriate) which shows the state of
> > these flags for the current document. No command line options, no dialog
> > boxes, just some way to see what the bits contain (either automatic in the
> > main window or in the property box).
>
> Like Netscapes lock for secure pages?
I'd like to add my opinions to the thread:
IMHO the user should know when the author/creator has requested the
material not to be copied or printed. The bits relay the request from the
author. They may have been set for a reason. I think it would be quite
irresponsible for a program to totally ignore the request.
On the other hand, making overriding too hard is not good either. This
rules out the command-line overriding (as a sole overriding mechanism). As
some have said xpdf may be started from a web browser making it
complicated to override. If overriding is made too hard, many will make a
script/alias from xpdf to "xpdf -override" (which probably would remove
all notice about the author's requests).
RMS's suggestion seems like a reasonable one to me, though it too has it's
flaws. It allows all possibilities for the user. I normally would like a
dialog, somebody else might want an option to disable them totally (if,
for instance, she has to work with such material often). For those totally
willing to follow the authors requests there is the -forceperms option.
It has it's flaws too. The checkbox would require a configuration file,
which somebody mentioned xpdf doesn't have yet. What I have also been
afraid of with the command line options is that scripts would start using
them, making the scripts incompatible with the original xpdf. IMHO the
default action should allow copying/printing, perhaps printing a warning
if used without -q - otherwise many scripts might start adding
-ignoreperms or if meant to be portable, could not use the feature at all.
A simple and effective way of overcoming the problem of compatibility
would be to add no new command line options. Using such a file from a
script would result in a warning, unless -q is specified. Of course,
consistency would be broken marginally as the original xpdf wouldn't allow
copying/printing of some files, but I doubt very many would want this
behavior in a script (any realistic examples of such a situation,
anyone?). For consistency, the dialog could be replaced by a text noting
the requests (as the quoted message suggests) - in this case it should be
made visible enough and placed in the main window, not some property box.
I'm not sure which is better. The first possibility allows for total user
control, but may break the command line interface compatibility. The
second one doesn't allow for such fine control, but seems quite simple and
reasonable. In any case, the user should be told everything about the
document (many doubtlessly would be interested) - including the "copy
protection" bits (unless the user has specifically asked not to be
informed).
Just my humble opinions...
__________________________________________________
/____\ Sampo Niskanen <=> sampo.niskanen@iki.fi \
\ http://www.iki.fi/sampo.niskanen \
\ ________________________________________\___
\___/___________________________________________/
Reply to: