OpenSystemsDevelopment / qpdf

Commit 379fc7e579c2258074e8d82012a3ca582c6034db

Authored by Jay Berkenbilt
1 parent 122df44a

TODO-pages: new idea to work in

Inline Side-by-side
Showing 1 changed file with 37 additions and 0 deletions
TODO-pages.md
  View file @379fc7e
... ... @@ -115,6 +115,43 @@ to be done to make them possible to build.
115 115  
116 116 # Architectural Thoughts
117 117  
  118 +XXX WORK IN: Dump `QPDFAssembler`. Instead, these are enhancements to `QPDFJob`. Don't try to
  119 +generalize this too much. There are actually only a few things we need to add to `QPDFJob`. Go
  120 +through and flesh out the list, but roughly:
  121 +
  122 +* From the C++ API, make it possible to use an arbitrary QPDF as an input rather than having to
  123 + start with a file. That makes it possible to do arbitrary work on the PDF prior to submitting it.
  124 +* Allow specification of n blank pages of a given size, e.g. `--blank=5@612x792`. Maybe we can
  125 + support standard paper sizes, inches, centimeters, or sizes relative to other pages.
  126 +* Generalize underlay/overlay
  127 + * Maybe we can do it by adding flags and allowing them to be repeated
  128 + * Maybe we need a new syntax, like pstops, but with the ability to specify anchors and proportions
  129 + based on varoius boxes
  130 + * Maybe we need something like `--stack`
  131 + * It needs to be possible to stack arbitrary pages with arbitrary transformations and to have the
  132 + transformations be a function of the source or destination page; the rectangle mapping idea
  133 + discussed elsewhere may be a good basis
  134 +* Have a page composition phase after the overlay/underlay stage
  135 + * Allow n-up, left-to-right (can reverse page order to get rtl), top-to-bottom, or modular
  136 + composition like pstops
  137 + * Possible hook for page composition to allow custom compositions
  138 +* A few additional split options
  139 +
  140 +Then, we need to make the existing logic handle other document-level structures, preferably in a way
  141 +that requires less duplication between split and merge. Maybe we can add a flag to disregard
  142 +document-level structures for speed, but I think being able to turn them on and off individually is
  143 +overkill, especially since people who are that sophisticated can tweak with JSON or just do it in
  144 +code.
  145 +
  146 +The challenge will be able to come up with command-line syntax to do most things from the CLI and to
  147 +make the C++ API flexible enough for users to insert their own bits in key places, just as we can
  148 +now grab the QPDF before the write phase. This approach eliminates all the function stuff. We just
  149 +have to make sure we can support all these features and have a relatively easy way to add new ones
  150 +or to let developers extend. The documentation will have to explain the flow of QPDFJob so people
  151 +can know where to apply hooks.
  152 +
  153 +----------
  154 +
118 155 Create a new top-level class called `QPDFAssembler` that will be used to perform page-level
119 156 operations. Its implementation will use existing APIs, and it will add many new APIs. It should be
120 157 possible to perform all existing page splitting and merging operations using `QPDFAssembler` without
... ...