Commit 1ad6451e8c09b22fc45694eb4263efcff24c8afc
1 parent
d96f74ae
Fix comment formatting and update notes
Showing
4 changed files
with
12 additions
and
9 deletions
TODO-pages.md
| ... | ... | @@ -70,6 +70,7 @@ Here are some examples. |
| 70 | 70 | * Center the smaller page horizontally and bottom-align the trim boxes |
| 71 | 71 | * Generalized overlay/underlay allowing n pages in a given order with transformations. |
| 72 | 72 | * n-up -- application of generalized overlay/underlay |
| 73 | + * make one long page with an arbitrary number of pages one after the other (#546) | |
| 73 | 74 | |
| 74 | 75 | It should be possible to represent all of the existing qpdf operations using the above framework. It would be good to re-implement all of them in terms of this framework to exercise it. We will have to look through all the command-line arguments and make sure. Of course also make sure suggestions from issues can be implemented or at least supported by adding new selectors. |
| 75 | 76 | |
| ... | ... | @@ -139,6 +140,7 @@ Easier to parse but yuck: |
| 139 | 140 | # To-do list |
| 140 | 141 | |
| 141 | 142 | * Go through all issues marked with the `pages` label and ensure that any ideas are represented here. Keep a list with mappings back to the issue number. |
| 143 | + * gh search issues label:pages --repo qpdf/qpdf --limit 200 --state=open | |
| 142 | 144 | * When ready, open a discussion ticket. |
| 143 | 145 | * Flesh out an implementation plan. |
| 144 | 146 | ... | ... |
TODO.md
| ... | ... | @@ -47,6 +47,7 @@ Next |
| 47 | 47 | cleaned up. See also issue #22. |
| 48 | 48 | * Make it possible to see incremental updates in qdf mode. |
| 49 | 49 | * Make it possible to add incremental updates. |
| 50 | + * We may want a writing mode that preserves object IDs. See #339. | |
| 50 | 51 | |
| 51 | 52 | Possible future JSON enhancements |
| 52 | 53 | ================================= | ... | ... |
include/qpdf/QPDFAcroFormDocumentHelper.hh
| ... | ... | @@ -22,16 +22,16 @@ |
| 22 | 22 | // This document helper is intended to help with operations on interactive forms. Here are the key |
| 23 | 23 | // things to know: |
| 24 | 24 | |
| 25 | -// * The PDF specification talks about interactive forms and also about form XObjects. While form | |
| 25 | +// * The PDF specification talks about interactive forms and also about form XObjects. While form | |
| 26 | 26 | // XObjects appear in parts of interactive forms, this class is concerned about interactive forms, |
| 27 | 27 | // not form XObjects. |
| 28 | 28 | // |
| 29 | -// * Interactive forms are discussed in the PDF Specification (ISO PDF 32000-1:2008) section 12.7. | |
| 30 | -// Also relevant is the section about Widget annotations. Annotations are discussed in | |
| 31 | -// section 12.5 with annotation dictionaries discussed in 12.5.1. Widget annotations are discussed | |
| 29 | +// * Interactive forms are discussed in the PDF Specification (ISO PDF 32000-1:2008) section 12.7. | |
| 30 | +// Also relevant is the section about Widget annotations. Annotations are discussed in section | |
| 31 | +// 12.5 with annotation dictionaries discussed in 12.5.1. Widget annotations are discussed | |
| 32 | 32 | // specifically in section 12.5.6.19. |
| 33 | 33 | // |
| 34 | -// * What you need to know about the structure of interactive forms in PDF files: | |
| 34 | +// * What you need to know about the structure of interactive forms in PDF files: | |
| 35 | 35 | // |
| 36 | 36 | // - The document catalog contains the key "/AcroForm" which contains a list of fields. Fields are |
| 37 | 37 | // represented as a tree structure much like pages. Nodes in the fields tree may contain other |
| ... | ... | @@ -49,7 +49,7 @@ |
| 49 | 49 | // traversing through the "/AcroForm" dictionary from the document catalog. In the simplest case |
| 50 | 50 | // (and also a very common case), a form field's widget annotation will be merged with the field |
| 51 | 51 | // object, and the object will appear directly both under "/Annots" in the page dictionary and |
| 52 | -// under "/Fields" in the "/AcroForm" dictionary. In a more complex case, you may have to trace | |
| 52 | +// under "/Fields" in the "/AcroForm" dictionary. In a more complex case, you may have to trace | |
| 53 | 53 | // through various "/Kids" elements in the "/AcroForm" field entry until you find the annotation |
| 54 | 54 | // dictionary. |
| 55 | 55 | |
| ... | ... | @@ -85,7 +85,7 @@ class QPDFAcroFormDocumentHelper: public QPDFDocumentHelper |
| 85 | 85 | QPDF_DLL |
| 86 | 86 | bool hasAcroForm(); |
| 87 | 87 | |
| 88 | - // Add a form field, initializing the document's AcroForm dictionary if needed, updating the | |
| 88 | + // Add a form field, initializing the document's AcroForm dictionary if needed, updating the | |
| 89 | 89 | // cache if necessary. Note that you are adding fields that are copies of other fields, this |
| 90 | 90 | // method may result in multiple fields existing with the same qualified name, which can have |
| 91 | 91 | // unexpected side effects. In that case, you should use addAndRenameFormFields() instead. |
| ... | ... | @@ -182,7 +182,7 @@ class QPDFAcroFormDocumentHelper: public QPDFDocumentHelper |
| 182 | 182 | // to the document or pages. You have to do that yourself after calling transformAnnotations. If |
| 183 | 183 | // this operation will leave orphaned fields behind, such as if you are replacing the old |
| 184 | 184 | // annotations with the new ones on the same page and the fields and annotations are not shared, |
| 185 | - // you will also need to remove the old fields to prevent them from hanging round unreferenced. | |
| 185 | + // you will also need to remove the old fields to prevent them from hanging around unreferenced. | |
| 186 | 186 | QPDF_DLL |
| 187 | 187 | void transformAnnotations( |
| 188 | 188 | QPDFObjectHandle old_annots, | ... | ... |
libqpdf/QPDFAnnotationObjectHelper.cc
| ... | ... | @@ -171,7 +171,7 @@ QPDFAnnotationObjectHelper::getPageContentForAppearance( |
| 171 | 171 | QPDFObjectHandle::Rectangle rect = rect_obj.getArrayAsRectangle(); |
| 172 | 172 | bool do_rotate = (rotate && (flags & an_no_rotate)); |
| 173 | 173 | if (do_rotate) { |
| 174 | - // If the the annotation flags include the NoRotate bit and the page is rotated, we have to | |
| 174 | + // If the annotation flags include the NoRotate bit and the page is rotated, we have to | |
| 175 | 175 | // rotate the annotation about its upper left corner by the same amount in the opposite |
| 176 | 176 | // direction so that it will remain upright in absolute coordinates. Since the semantics of |
| 177 | 177 | // /Rotate for a page are to rotate the page, while the effect of rotating using a | ... | ... |