Replies: 1 comment
-
This looks great. You did a fair bit of work on this and there are certainly some things I'd be interested in merging. It works for me because in my personal/professional uses of pikepdf I almost never need forms, but obviously, lots of people do. I could definitely see some things like more intuitive content stream builder, form manipulation of course, and font support being useful. Is there anything in particular that you were thinking you'd like to upstream? Some caveats so far: Licensing - Can you create a license file for your project? No one can reuse your work until you decide how to license it. If you're not sure, I recommend using Apache 2.0, because it requires you also guarantee you don't hold PDF-related patents or trademarks. (I probably should have chosen Apache for pikepdf instead but I haven't changed the license because it's worth the hassle.) pikepdf uses MPL 2.0. Code you contribute to pikepdf could be under that license if you like to that or redistributed under a more permissive license. Features - I prefer to avoid duplicating features that already exist in QPDF. That's where I'd prefer to wait till have a chance to expose the QPDF features. Tests - I am trying to get pikepdf to 100% coverage. Especially for the C++ side since there's more risk there. I suggest switching from argparse to typer. typer is just fantastic at making great CLIs, with less code, better validation, automatic completions, and more testability than argparse. |
Beta Was this translation helpful? Give feedback.
-
Continuing conversation from an issue thread at
#58 (comment):
@dmjohnsson23dmjohnsson23 wrote:
Beta Was this translation helpful? Give feedback.
All reactions