- Package:
- poppler-utils
- Source:
- poppler
- Description:
- PDF utilities (based on Poppler)
- Submitter:
- Robert Millan
- Date:
- 2010-09-15 11:33:07 UTC
- Severity:
- wishlist
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.
Today I stubled upon this crippling "feature" of poppler-utils. I agree that the API shouldn't be changed (the API itself does not enforce anything), but at least pdftohtml and pdftoabw should be patched. Could you please add this patch to fix those two utilities?