Commit ba61c3aef0f4369f4db2f7b48b19c2cebbcf95e0
1 parent
3844aedd
Updates to TODO file
Showing
1 changed file
with
79 additions
and
10 deletions
TODO
| 1 | Next | 1 | Next |
| 2 | ==== | 2 | ==== |
| 3 | 3 | ||
| 4 | +Using FIXME as a marker for issues that must be resolved prior to | ||
| 5 | +release. | ||
| 6 | + | ||
| 7 | +https://github.com/qpdf/qpdf/wiki/pdftopdf | ||
| 8 | + | ||
| 4 | *** ABI changes have been made. build.mk has been updated. | 9 | *** ABI changes have been made. build.mk has been updated. |
| 5 | 10 | ||
| 6 | - * Do a Windows 64-bit build. MSVC 2010 Professional x86_64 verified | ||
| 7 | - to build and test cleanly in 2.3.1. Hopefully the next release | ||
| 8 | - will include 64-bit binary distributions and external libraries. | 11 | + * Reconsider dumping off_t in favor of qpdf_off_t defined as uint64_t. |
| 12 | + | ||
| 13 | + * 64-bit windows build, remaining steps | ||
| 14 | + | ||
| 15 | + - new external-libs have been built and copied into | ||
| 16 | + ~/Q/storage/releases/qpdf/external-libs. Release is done in | ||
| 17 | + git. Just need to upload when ready. Remember to document that | ||
| 18 | + this version is needed for >= 2.4. | ||
| 19 | + | ||
| 20 | + - make_windows_releases will need to be updated in a manner | ||
| 21 | + similar to how external-libs build.sh was: run the two mingw | ||
| 22 | + builds, then instruct to run the msvc builds in separately | ||
| 23 | + configured shells | ||
| 9 | 24 | ||
| 10 | - * Building 64-bit libraries with MSVC works with existing build.sh as | ||
| 11 | - long as the x86_64 version of the compiler is in the path. | ||
| 12 | - Currently this generates 32-bit mingw and 64-bit msvc. We need to | ||
| 13 | - figure out a way so that make_windows_releases builds both 32-bit | ||
| 14 | - and 64-bit versions and puts them in a sensible place. This has | ||
| 15 | - only been verified with MSVC 2010 so far; we still need to get it | ||
| 16 | - working with 64-bit mingw. | 25 | + - update docs to indicate that MSVC 2010 is the supported version. |
| 17 | 26 | ||
| 18 | * Provide an option to copy encryption parameters from another file. | 27 | * Provide an option to copy encryption parameters from another file. |
| 19 | This would make it possible to decrypt a file, manually work with | 28 | This would make it possible to decrypt a file, manually work with |
| @@ -23,6 +32,66 @@ Next | @@ -23,6 +32,66 @@ Next | ||
| 23 | * See if I can support the new encryption formats mentioned in the | 32 | * See if I can support the new encryption formats mentioned in the |
| 24 | open bug on sourceforge. Check other sourceforge bugs. | 33 | open bug on sourceforge. Check other sourceforge bugs. |
| 25 | 34 | ||
| 35 | + * Would be nice to confirm that it's working for > 4GB files. | ||
| 36 | + | ||
| 37 | + * Splitting/merging concepts | ||
| 38 | + | ||
| 39 | + newPDF() could create a PDF with just a trailer, no pages, and a | ||
| 40 | + minimal info. Then the page routines could be used to add pages to | ||
| 41 | + it. | ||
| 42 | + | ||
| 43 | + Starting with any pdf, you should be able to copy objects from | ||
| 44 | + another pdf. The copy should be smart about never traversing into | ||
| 45 | + a /Page or /Pages. | ||
| 46 | + | ||
| 47 | + We could provide a method of copying objects from one PDF into | ||
| 48 | + another. This would do whatever optimization is necessary (maybe | ||
| 49 | + just optimizePagesTree) and then traverse the set of objects | ||
| 50 | + specified to find all objects referenced by the set. Each of those | ||
| 51 | + would be copied over with a table mapping old ID to new ID. This | ||
| 52 | + would be done from bottom up most likely disallowing cycles or | ||
| 53 | + handling them sanely. | ||
| 54 | + | ||
| 55 | + Command line could be something like | ||
| 56 | + | ||
| 57 | + --pages [ --new ] { file [password] numeric-range ... } ... -- | ||
| 58 | + | ||
| 59 | + The first file referenced would be the one whose other data would | ||
| 60 | + be preserved (like trailer, info, encryption, outlines, etc.). | ||
| 61 | + --new as first file would just use an empty file as the starting | ||
| 62 | + point. | ||
| 63 | + | ||
| 64 | + Example: to grab pages 1-5 from file1 and 11-15 from file2 | ||
| 65 | + | ||
| 66 | + --pages file1.pdf 1-5 file2.pdf 11-15 -- | ||
| 67 | + | ||
| 68 | + To implement this, we would remove all pages from file1 except | ||
| 69 | + pages 1 through 5. Then we would take pages 11 through 15 from | ||
| 70 | + file2 and add them to a set for transfer. This would end up | ||
| 71 | + generating a list of indirect objects. We would copy those objects | ||
| 72 | + shallowly to the new PDF keeping track of the mapping and replacing | ||
| 73 | + any indirect object keys as appropriate, much like QPDFWriter does. | ||
| 74 | + | ||
| 75 | + When all the objects are registered, we would add those pages to | ||
| 76 | + the result. | ||
| 77 | + | ||
| 78 | + This approach could work for both splitting and merging. It's | ||
| 79 | + possible it could be implemented now without any new APIs, but most | ||
| 80 | + of the work should be doable by the library with only a small set | ||
| 81 | + of additions. | ||
| 82 | + | ||
| 83 | + newPDF() | ||
| 84 | + QPDFObjectCopier c(qpdf1, qpdf2) | ||
| 85 | + QPDFObjectHandle obj = c.copyObject(<object from qpdf1>) | ||
| 86 | + Without traversing pages, copies all indirect objects referenced | ||
| 87 | + by <object from qpdf1> preserving referential integrity and | ||
| 88 | + returns an object handle in qpdf2 of the same object. If called | ||
| 89 | + multiple times on the same object, retraverses in case there were | ||
| 90 | + changes. | ||
| 91 | + | ||
| 92 | + QPDFObjectHandle obj = c.getMapping(<object from qpdf1>) | ||
| 93 | + find the object in qpdf2 corresponding to the object from qpdf1. | ||
| 94 | + Return the null object if none. | ||
| 26 | 95 | ||
| 27 | General | 96 | General |
| 28 | ======= | 97 | ======= |