Uploaded image for project: 'PDFBox'
  1. PDFBox
  2. PDFBOX-699

Add support for InputStreams to PDFMergerUtility

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • None
    • 1.2.0
    • Utilities
    • None

    Description

      Currently the PDFMergerUtility class is only set up to merge files, not streams. I need to extend this to be able to handle both and I'm trying to determine how best to do this so it can be contributed back in a manner which won't disrupt others.

      Currently there's a List<File> which holds all the source documents. I'd like to convert this to a List<InputStream> but the problem arises in when exceptions are thrown. The normal usage of this class would be something like this:
      PDFMergerUtility merger = new PDFMergerUtility();
      merger.setDestinationFileName("output.pdf");
      merger.addSource("file0.pdf");
      File pdf1 = new Flie("file1.pdf");
      merger.addSource(pdf1); // just demonstrating files work as well as filenames
      merger.mergeDocuments();

      mergeDocuments() is the only thing above which may throw an exception. If the List were converted to hold InputStream object, we could just wrap the File with a "new FileInputStream(sourceFile)" and "new FileInputStream(new File(sourceFileName))". The problem is that may throw an exception if the file can't be read for some reason. I don't really want to just log an error (basically ignoring the problem, in terms of the path of code execution), but I'm hesitant to change the API so addSource() throws an exception. Order matters (i.e. merging file0 with file1 isn't the same as merging file1 with file0), so it'd be difficult to have two lists (one for Files and one for Streams). The other thing I thought it catching the Exception and throwing a RuntimeException (which doesn't need to be declared in the API).

      So I'm looking for some feedback from the community here. The cleanest solution is to add "throws Exception" to the addSource() methods (they already may throw a NullPointerException, but that's a RuntimeException...). Do you think changing the API an option? If not, how would it be best to handle this?

      Attachments

        1. PDFBOX-699_fixed.patch
          4 kB
          Adam Nichols

        Activity

          People

            Unassigned Unassigned
            adamnichols Adam Nichols
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: