diff options
| -rw-r--r-- | TODO-pages.md | 2 | ||||
| -rw-r--r-- | TODO.md | 1 | ||||
| -rw-r--r-- | include/qpdf/QPDFAcroFormDocumentHelper.hh | 16 | ||||
| -rw-r--r-- | libqpdf/QPDFAnnotationObjectHelper.cc | 2 |
4 files changed, 12 insertions, 9 deletions
diff --git a/TODO-pages.md b/TODO-pages.md index 722d2511..8163ec5e 100644 --- a/TODO-pages.md +++ b/TODO-pages.md @@ -70,6 +70,7 @@ Here are some examples. * Center the smaller page horizontally and bottom-align the trim boxes * Generalized overlay/underlay allowing n pages in a given order with transformations. * n-up -- application of generalized overlay/underlay + * make one long page with an arbitrary number of pages one after the other (#546) 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. @@ -139,6 +140,7 @@ Easier to parse but yuck: # To-do list * 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. + * gh search issues label:pages --repo qpdf/qpdf --limit 200 --state=open * When ready, open a discussion ticket. * Flesh out an implementation plan. @@ -47,6 +47,7 @@ Next cleaned up. See also issue #22. * Make it possible to see incremental updates in qdf mode. * Make it possible to add incremental updates. + * We may want a writing mode that preserves object IDs. See #339. Possible future JSON enhancements ================================= diff --git a/include/qpdf/QPDFAcroFormDocumentHelper.hh b/include/qpdf/QPDFAcroFormDocumentHelper.hh index 9e0ad51e..72078524 100644 --- a/include/qpdf/QPDFAcroFormDocumentHelper.hh +++ b/include/qpdf/QPDFAcroFormDocumentHelper.hh @@ -22,16 +22,16 @@ // This document helper is intended to help with operations on interactive forms. Here are the key // things to know: -// * The PDF specification talks about interactive forms and also about form XObjects. While form +// * The PDF specification talks about interactive forms and also about form XObjects. While form // XObjects appear in parts of interactive forms, this class is concerned about interactive forms, // not form XObjects. // -// * Interactive forms are discussed in the PDF Specification (ISO PDF 32000-1:2008) section 12.7. -// Also relevant is the section about Widget annotations. Annotations are discussed in -// section 12.5 with annotation dictionaries discussed in 12.5.1. Widget annotations are discussed +// * Interactive forms are discussed in the PDF Specification (ISO PDF 32000-1:2008) section 12.7. +// Also relevant is the section about Widget annotations. Annotations are discussed in section +// 12.5 with annotation dictionaries discussed in 12.5.1. Widget annotations are discussed // specifically in section 12.5.6.19. // -// * What you need to know about the structure of interactive forms in PDF files: +// * What you need to know about the structure of interactive forms in PDF files: // // - The document catalog contains the key "/AcroForm" which contains a list of fields. Fields are // represented as a tree structure much like pages. Nodes in the fields tree may contain other @@ -49,7 +49,7 @@ // traversing through the "/AcroForm" dictionary from the document catalog. In the simplest case // (and also a very common case), a form field's widget annotation will be merged with the field // object, and the object will appear directly both under "/Annots" in the page dictionary and -// under "/Fields" in the "/AcroForm" dictionary. In a more complex case, you may have to trace +// under "/Fields" in the "/AcroForm" dictionary. In a more complex case, you may have to trace // through various "/Kids" elements in the "/AcroForm" field entry until you find the annotation // dictionary. @@ -85,7 +85,7 @@ class QPDFAcroFormDocumentHelper: public QPDFDocumentHelper QPDF_DLL bool hasAcroForm(); - // Add a form field, initializing the document's AcroForm dictionary if needed, updating the + // Add a form field, initializing the document's AcroForm dictionary if needed, updating the // cache if necessary. Note that you are adding fields that are copies of other fields, this // method may result in multiple fields existing with the same qualified name, which can have // unexpected side effects. In that case, you should use addAndRenameFormFields() instead. @@ -182,7 +182,7 @@ class QPDFAcroFormDocumentHelper: public QPDFDocumentHelper // to the document or pages. You have to do that yourself after calling transformAnnotations. If // this operation will leave orphaned fields behind, such as if you are replacing the old // annotations with the new ones on the same page and the fields and annotations are not shared, - // you will also need to remove the old fields to prevent them from hanging round unreferenced. + // you will also need to remove the old fields to prevent them from hanging around unreferenced. QPDF_DLL void transformAnnotations( QPDFObjectHandle old_annots, diff --git a/libqpdf/QPDFAnnotationObjectHelper.cc b/libqpdf/QPDFAnnotationObjectHelper.cc index b967a5b3..1878c0e8 100644 --- a/libqpdf/QPDFAnnotationObjectHelper.cc +++ b/libqpdf/QPDFAnnotationObjectHelper.cc @@ -171,7 +171,7 @@ QPDFAnnotationObjectHelper::getPageContentForAppearance( QPDFObjectHandle::Rectangle rect = rect_obj.getArrayAsRectangle(); bool do_rotate = (rotate && (flags & an_no_rotate)); if (do_rotate) { - // If the the annotation flags include the NoRotate bit and the page is rotated, we have to + // If the annotation flags include the NoRotate bit and the page is rotated, we have to // rotate the annotation about its upper left corner by the same amount in the opposite // direction so that it will remain upright in absolute coordinates. Since the semantics of // /Rotate for a page are to rotate the page, while the effect of rotating using a |