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,6 +115,43 @@ to be done to make them possible to build. | ||
| 115 | 115 | ||
| 116 | # Architectural Thoughts | 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 | Create a new top-level class called `QPDFAssembler` that will be used to perform page-level | 155 | Create a new top-level class called `QPDFAssembler` that will be used to perform page-level |
| 119 | operations. Its implementation will use existing APIs, and it will add many new APIs. It should be | 156 | operations. Its implementation will use existing APIs, and it will add many new APIs. It should be |
| 120 | possible to perform all existing page splitting and merging operations using `QPDFAssembler` without | 157 | possible to perform all existing page splitting and merging operations using `QPDFAssembler` without |