OpenSystemsDevelopment / qpdf

Commit ba61c3aef0f4369f4db2f7b48b19c2cebbcf95e0

Authored by Jay Berkenbilt
1 parent 3844aedd

Updates to TODO file

Inline Side-by-side
Showing 1 changed file with 79 additions and 10 deletions
1 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 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 27 * Provide an option to copy encryption parameters from another file.
19 28 This would make it possible to decrypt a file, manually work with
... ... @@ -23,6 +32,66 @@ Next
23 32 * See if I can support the new encryption formats mentioned in the
24 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 96 General
28 97 =======
... ...