Hi Tilman, thanks for your reply. If I had to prioritize the list of tests, I’d choose:
1) Exit on missing input PDF files 2) Exit on bad (unparsable/corrupt/damaged/encrypted?) input PDF file 3) Warning on password-protected PDF 4) Fail on too many input pages For #4, eventually I’d prefer a more gracious handling (add suffixes to file name, start a new output file), but I may be able to manage that issue myself, creating separate input files. To prevent too much scope creep, I’d be happy to separate #3 and #4 into a separate bounty in the future. And if a paid bounty is an issue, I’d be happy to donate directly to Apache as a ’thank you’ to the community. Happy New Year. :) On 2025/12/27 14:36:37 Tilman Hausherr wrote: > Hi, > > IMHO it is a useful feature however I'm not interested in money because > the bureaucracy around it would need more time than to develop the > feature. I might do it later, in a few days / weeks when I'm done with > the xmp bugfixes I'm working on. > > However the "Testing only needs to be basic" part seems to contain much > more things than "reading from a file". We don't check for password > protected features, or for a page count. > I searched google whether the "reading from file" feature is available > from Picocli and didn't get a useable answer. Google seems to get worse > and worse. So I asked ChatGPT and yes it is possible. > The prompt was "Does picocli have a feature to get a list of files not > from the command line, but from a file containing lines with the filenames?" > > https://chatgpt.com/share/694fee54-eb20-8006-b712-16d734640efc > > Tilman > > Am 26.12.2025 um 20:19 schrieb PDF Newbie via dev: > > Hi. I’ve reviewed the documentation for the PDFMerger utility located here: > > > > https://pdfbox.apache.org/3.0/commandline.html#pdfmerger > > > > And it appears that it only accepts a list of input files on the command > > line with the -i option. While this is good, I would also like to be able > > to pass a list of file names (one per line), and have the list of files > > added to a single output file specified by the already-existing -o option. > > > > Why? The number of files I’ll be merging is larger than most UNIX/Linux > > shell environments permit, and file names may be up to 68-characters long > > (64-character string + .pdf), further reducing the number of files I can > > merge within one command. > > > > While I don’t particularly care how this is implemented, other open source > > utilities follow the convention of prefixing an input file name with an > > ‘at’ symbol (‘@‘), or offer a separate option (“-l” / lowercase L) to > > specify the file. > > > > Testing only needs to be basic — before beginning, ensure all files > > described in the list file exist, and optionally test the > > correctness/compliance of the input PDF’s to ensure a defective merged PDF > > isn’t created, and ensure that the input file doesn’t contain more pages > > than the PDF spec allows for, and potentially adding a warning when files > > that contain incompatible options (password protected features such as > > copying / printing, etc.) are added. > > > > Given that the use case for this is commercial in nature, I’d like to offer > > a bounty for this feature - I’m neutral as to which platform should be used > > for posting / tracking / paying for this — just let me know which one. I’d > > prefer to work with one of the core maintainers for the project, but other > > recognized contributors are also eligible, my only requirement is that the > > change is added to the main distribution. I’d also consider making a > > donation directly to the project if that is preferred. > > > > Thanks. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail:[email protected] > > For additional commands, e-mail:[email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
