This library appears to be crippled with DRM anti-features.  Here's a patch
to remove them.  Please apply it so that our users can exercise the fair use
rights they're entitled to.

* Robert Millan <rmh@aybabtu.com>, 2008-05-14, 12:01:
[...]
But it is not. Functions, which the patch virtually disables, are never
internally used to disallow anything.

What is more, the patch breaks existing software, e.g. pdfinfo.

I don't recall the exact details, but I've seen other programs rely on those
functions.  So they're not used internally, but externally.  IOW, it provides
a helper framework to facilitate implementation of restriction management in
an upper layer.

2008/6/11 Robert Millan <rmh@aybabtu.com>:

So what? You are going to cripple the library just because another programs use
these functions? Patch those programs and not libpoppler then. It just provides
functions on top of PDF specs.

Ondrej

* Robert Millan <rmh@aybabtu.com>, 2008-06-11, 15:03:
Right. pdftoabw and pdftohtml from poppler-utils use them to restrict
access (pdfimages, pdftops and pdftotext have been already patched not
to do that - see 02_permissions.dpatch.diff).

Tools from xpdf-utils do the same, although they are not linked with
poppler.

Don't hesitate to file bugs against _these_ packages.
It's nothing wrong with that, as long as you are free _not_to_ use the
framework.

The PDF specs are supposed to describe how PDF is laid out, not how your
program should behave.  There's no reason you have to follow a spec on
things that are outside the scope of it.

For example, if RFC 821 said that messages containing the word "freedom"
should be automaticaly discarded, it would be silly for MTAs to implement
that, even if it's in a standard.

In practice, it tends to generate confusion.  For example, the implementor of
a libpoppler-based program might naively think that access to the data is
disallowed by cryptography instead of restriction management, and make her
program disallow access to the document in good faith.

Or one could be writing a program that lists files and their properties, and
mistakenly tell the user that a PDF file cannot be printed.  This happened to
the KDE developers in fact:

http://bugs.kde.org/show_bug.cgi?id=162089

  (although they didn't want to recognize it)

If you don't want to remove the functions, please consider at least renaming
them and clearly documenting in the code that they're purely informative.

Thanks

clone 481183 -1
reassign -1 poppler-utils
thanks

Doing. Thanks for the pointer.

2008/6/11 Robert Millan <rmh@aybabtu.com>:

And so what? You want to disallow people to write such programs? Or
you want to disallow people to write DRM programs at all? And what
about their freedoms?

Well, on other hand I completely agree with their reasons and same
reasons apply here. These functions doesn't restrict you, they just
inform you about flags used in PDF.

Try asking upstream. I don't see any reason to mangle with API/ABI
just because of your holy war.

Ondrej.

 Did you mean to reassign to xpdf-utils?

Considering there's no mechanism that would allow us to "disallow" people from
writing a specific program, I think this is entirely out of context.  But yes,
I respect their freedom to write anything they like using Debian, even trojans,
viruses or spammer tools.

This doesn't change the fact that a user who installs non-mallicious programs
based on this library may obtain bizarre information, such as a file manager
telling her a PDF can be read but not printed, whereas this is in fact not
only false, but it even violates the principles of information theory.

Since I already replied to this, I assume you didn't read it.  I'm pasting
it here for your convenience:

<quote>
Pino, I agree with what you said.  But the information it is displaying leads the user to believe this document cannot be printed, which isn't true most of the time.  It is misleading.

An accurate description of the information would be, that the author of this document pretended to restrict you from printing it, but this will only have an effect if you're not using the free PDF viewer that came with KDE.

I don't know how to summarize this, but certainly "cannot be printed" doesn't describe reality.
</quote>

(from http://bugs.kde.org/show_bug.cgi?id=162089#c9)

Since upstream not only added these functions in first place, but also
used them to implement restriction management, I expect that discussing
this with upstream would be even less productive than it is discussing
it with you or the KDE developers.

What holy war?  I'm talking about technical flaws;  namely, that programs
make biased assumptions about this library's API, which ultimately leads to
false information being reported to the user.

Please don't turn it into politics ...