Commit 379fc7e579c2258074e8d82012a3ca582c6034db
1 parent
122df44a
TODO-pages: new idea to work in
Showing
1 changed file
with
37 additions
and
0 deletions
TODO-pages.md
| ... | ... | @@ -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 | ... | ... |