qpdf: What am I doing wrong here?

Hi,

I’m programming agains the JSON interface and try to encrypt a file with these settings, but that always fails. Do you know what I’m doing wrong?

{
  "inputFile": "TestFiles\test.pdf",
  "outputFile": "C:\\3eb6fc52-800f-4c32-a5fb-9ad1709d5260\\output_encryption_256_bit.pdf",
  "linearize": "",
  "encrypt": {
    "256bit": {
      "accessibility": "y",
      "annotate": "y",
      "assemble": "y",
      "extract": "y",
      "form": "y",
      "modifyOther": "y",
      "modify": "all",
      "print": "full",
      "cleartextMetadata": "y"
    },
    "userPassword": "user",
    "ownerPassword": "owner"
  }
}

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 63 (20 by maintainers)

Most upvoted comments

It’s a bug that removeAttachment doesn’t take an array. Thanks for catching that. I guess I don’t have any test cases for that specifically. I’ll check to see if any other repeatable options are not correct.

The overlay/underlay is working according to expectation, assuming your test.pdf has one page. Perhaps the documentation needs to be clarified? The "to" argument restricts which pages of the output to apply the overlay to but doesn’t otherwise change the behavior that overlay stops when the source file runs out of pages unless "repeat" is given.

jberkenbilt on Apr 24, 2022

No objections – you don’t need my permission to copy from/reference my readme in yours.

jberkenbilt on Apr 20, 2022

Thanks, that is a good solution adding a wiki page. I’ll just want to avoid that people try to reinvent the same wheel more then once because I know how much work it can be to write something “simple” as a wrapper around another library.

I also don’t mind if there are some breaking changes in the json interface, that is something you sometimes can’t avoid and that is why I’m making unit test to make sure that I detect breaking changes before releasing a new package.

It is also not a problem if the versions get somewhat out of sync because I include a compiled version of qpdf in the .net package that I’m going to release on nuget (because I also modified the json interface somewhat to get back everything from cout and cerr) so that people just have to install the package in there C# ide and have everything they need.

I also want to include some more advanced options in the C# nuget package but the current to be released package is a good starting point for most people if they want to do the basic things. Making wrappers from C# to C++ sometimes can be very difficult because of the different object types you have between both programming languages. I find is sometimes very difficult to marshal object from C# to C++ because of the ways interfaces are made in both languages

Sicos1977 on Apr 20, 2022

The qpdf-c.h and qpdfjob-c.h APIs are disjointed. Being able to trap stdout, etc., is definitely on the roadmap. Sorry if the qpdfjob API seems bare. It is really just a json wrapper around passing command-line arguments and is just slightly tighter integration than communicating with qpdf as a subprocess. So right now it doesn’t really do enough for a full qpdf wrapper into another language except for stuff that could be done with the CLI. Your questions are helpful in letting me know what the priorities should be though. A few of the other items I’d like to consider are

Making sure json output can replace all the calls that currently print information to stdout (--check, --show-object, --show-linearization`, etc.)
Custom progress reporter
Some kind of interface for replacing objects (maybe)
Possibly json output mode instead of stdout/stderr
Job chaining – essentially the ability to do something that would cover multiple qpdf commands, though you can often combine multiple operations

This is not terribly high priority. There are two big things in front of it: JSON v2 (full bidirectional serialization/deserialization between PDF and JSON) and a higher-level document manipulation API that I will probably reimplement much of QPDFJob on top of. This in turn clears the way for supporting many more document-level features in page splitting, which are by far the most requested features.

jberkenbilt on Apr 13, 2022