Commit 716381f65a2b2dc72f8da2426ba71aeab02c507f

Authored by m-holger
Committed by Jay Berkenbilt
1 parent 68e4aec0

Fix doc typos

include/qpdf/PointerHolder.hh
... ... @@ -118,7 +118,7 @@
118 118  
119 119 // POINTERHOLDER_TRANSITION = 3
120 120 //
121   -// Warn for all use of PointerHolder<T>. This help you remove all use
  121 +// Warn for all use of PointerHolder<T>. This helps you remove all use
122 122 // of PointerHolder from your code and use std::shared_ptr instead.
123 123 // You will also have to transition any containers of PointerHolder in
124 124 // your code.
... ...
include/qpdf/QPDFObjectHandle.hh
... ... @@ -149,7 +149,7 @@ class QPDFObjectHandle
149 149 // representation of the token. For a string, this means that
150 150 // there are no delimiters, and for a name, it means that all
151 151 // escaping (# followed by two hex digits) has been resolved.
152   - // qpdf's internal representation of name includes the leading
  152 + // qpdf's internal representation of a name includes the leading
153 153 // slash. As such, you can't write the value of token.getValue()
154 154 // directly to output that is supposed to be valid PDF syntax. If
155 155 // you want to do that, you need to call writeToken() instead, or
... ... @@ -163,8 +163,8 @@ class QPDFObjectHandle
163 163 // writeToken(). Example:
164 164 // writeToken(QPDFTokenizer::Token(QPDFTokenizer::tt_name, "/text/plain"))
165 165 // would write `/text#2fplain`, and
166   - // writeToken(QPDFTokenizer::Token(QPDFTokenizer::tt_string, "a\\(b"))
167   - // would write `(a\(b)`
  166 + // writeToken(QPDFTokenizer::Token(QPDFTokenizer::tt_string, "a\\(b)")
  167 + // would write `(a\(b)`.
168 168 class QPDF_DLL_CLASS TokenFilter
169 169 {
170 170 public:
... ... @@ -531,7 +531,7 @@ class QPDFObjectHandle
531 531 // PDF name is a sequence of bytes, excluding the NUL character,
532 532 // and starting with a slash. Name objects as represented in the
533 533 // PDF specification can contain characters escaped with #, but
534   - // such escaping is not of concern calling QPDFObjectHandle
  534 + // such escaping is not of concern when calling QPDFObjectHandle
535 535 // methods not directly relating to parsing. For example,
536 536 // newName("/text/plain").getName() and
537 537 // parse("/text#2fplain").getName() both return "/text/plain",
... ... @@ -955,7 +955,7 @@ class QPDFObjectHandle
955 955 QPDF_DLL
956 956 QPDF* getOwningQPDF();
957 957  
958   - // Create a shallow of an object as a direct object, but do not
  958 + // Create a shallow copy of an object as a direct object, but do not
959 959 // traverse across indirect object boundaries. That means that,
960 960 // for dictionaries and arrays, any keys or items that were
961 961 // indirect objects will still be indirect objects that point to
... ...
manual/design.rst
... ... @@ -130,7 +130,7 @@ classes are intended to contain higher level APIs that allow developers
130 130 to work with certain document constructs at an abstraction level above
131 131 that of ``QPDFObjectHandle`` while staying true to qpdf's philosophy of
132 132 not hiding document structure from the developer. As with qpdf in
133   -general, the goal is take away some of the more tedious bookkeeping
  133 +general, the goal is to take away some of the more tedious bookkeeping
134 134 aspects of working with PDF files, not to remove the need for the
135 135 developer to understand how the PDF construction in question works. The
136 136 driving factor behind the creation of helper classes was to allow the
... ... @@ -751,7 +751,7 @@ actually quite rare and largely avoidable.
751 751 Smart Pointers
752 752 --------------
753 753  
754   -This section describes changes to the use of smart pointers there were
  754 +This section describes changes to the use of smart pointers that were
755 755 made in qpdf 10.6.0 as well as some planned for 11.0.0.
756 756  
757 757 Starting in qpdf 11, ``PointerHolder`` will be replaced with
... ... @@ -886,7 +886,7 @@ switching from ``PointerHolder`` to ``std::shared_ptr``:
886 886 To use ``POINTERHOLDER_TRANSITION``, you will need to ``#define`` it
887 887 before including any qpdf header files or specify its value as part of
888 888 your build. The table below describes the values of
889   -``POINTERHOLDER_TRANSITION``. This informatoin is also summarized in
  889 +``POINTERHOLDER_TRANSITION``. This information is also summarized in
890 890 :file:`include/qpdf/PointerHolder.hh`, so you will have it handy
891 891 without consulting this manual.
892 892  
... ... @@ -898,10 +898,10 @@ without consulting this manual.
898 898 - meaning
899 899  
900 900 - - undefined
901   - - same as ``0``, but start with qpdf 11.0, issues a warning
  901 + - Same as ``0``, but starting with qpdf 11.0, issues a warning
902 902  
903 903 - - ``0``
904   - - provide a backward compatible ``PointerHolder`` and suppress
  904 + - Provide a backward compatible ``PointerHolder`` and suppress
905 905 all deprecation warnings
906 906  
907 907 - - ``1``
... ... @@ -911,10 +911,10 @@ without consulting this manual.
911 911 - Deprecate ``getPointer()`` and ``getRefcount()``
912 912  
913 913 - - ``3``
914   - - Starting in qpdf 11, deprecate all uses of ``PointerHolder``
  914 + - Starting with qpdf 11.0, deprecate all uses of ``PointerHolder``
915 915  
916 916 - - ``4``
917   - - Starting in qpdf 11, disable all functionality from
  917 + - Starting with qpdf 11.0, disable all functionality from
918 918 ``qpdf/PointerHolder.hh`` so that ``#include``-ing it has no
919 919 effect.
920 920  
... ... @@ -1012,7 +1012,7 @@ After qpdf 11 is out
1012 1012 In the 10.6 manual, this section represents a plan and is subject to
1013 1013 change. However, it has been tested in practice using a version of the
1014 1014 qpdf 11 ``PointerHolder`` on a branch, so it is likely to be accurate.
1015   -In the meantime, think of this is a preview.
  1015 +In the meantime, think of this as a preview.
1016 1016  
1017 1017 First, make sure you have done the steps in the 10.6 section. (Note:
1018 1018 once qpdf 11 comes out, the goal is to not have to migrate to 10.6
... ... @@ -1090,8 +1090,8 @@ symbol. Here are the remaining changes.
1090 1090  
1091 1091 - Build and test. Fix any remaining issues.
1092 1092  
1093   -- If not supporting older qpdf, remove all references to
1094   - ``<qpdf/PointerHolder.hh>``. Otherwise, you wil still need to
  1093 +- If not supporting older versions of qpdf, remove all references to
  1094 + ``<qpdf/PointerHolder.hh>``. Otherwise, you will still need to
1095 1095 include it but can ``#define POINTERHOLDER_TRANSITION 4`` to prevent
1096 1096 ``PointerHolder`` from being defined. The
1097 1097 ``POINTERHOLDER_IS_SHARED_POINTER`` symbol will still be defined.
... ... @@ -1102,6 +1102,6 @@ Historical Background
1102 1102 Since its inception, the qpdf library used its own smart pointer
1103 1103 class, ``PointerHolder``. The ``PointerHolder`` class was originally
1104 1104 created long before ``std::shared_ptr`` existed, and qpdf itself
1105   -didn't start requiring a C++11 compiler version 9.1.0 released in
1106   -late 2019. With current C++ versions, is no longer desirable for qpdf
  1105 +didn't start requiring a C++11 compiler until version 9.1.0 released in
  1106 +late 2019. With current C++ versions, it is no longer desirable for qpdf
1107 1107 to have its own smart pointer class.
... ...
manual/qpdf-job.rst
... ... @@ -184,10 +184,10 @@ This section describes some of the design rationale and history behind
184 184 Documentation of ``QPDFJob`` is divided among three places:
185 185  
186 186 - "HOW TO ADD A COMMAND-LINE ARGUMENT" in :file:`README-maintainer`
187   - provides a quick reminder of how to add a command-line argument
  187 + provides a quick reminder of how to add a command-line argument.
188 188  
189 189 - The source file :file:`generate_auto_job` has a detailed explanation
190   - about how ``QPDFJob`` and ``generate_auto_job`` work together
  190 + about how ``QPDFJob`` and ``generate_auto_job`` work together.
191 191  
192 192 - This chapter of the manual has other details.
193 193  
... ... @@ -207,7 +207,7 @@ such. This created a number of problems:
207 207  
208 208 - Users of other languages who just wanted an interface to do things
209 209 that the CLI could do didn't have a good way to do it, such as just
210   - handling a library call a set of command-line options or an
  210 + handing a library call a set of command-line options or an
211 211 equivalent JSON object that could be passed in as a string.
212 212  
213 213 - The qpdf CLI itself was almost 8,000 lines of code. It needed to be
... ...
manual/release-notes.rst
... ... @@ -12,7 +12,7 @@ For a detailed list of changes, please see the file
12 12 The next major release of qpdf will replace ``PointerHolder`` with
13 13 ``std::shared_ptr`` across all of qpdf's public API. No action is
14 14 required at this time, but if you'd like to prepare, read the
15   - comments :file:`include/qpdf/PointerHolder.hh` and see
  15 + comments in :file:`include/qpdf/PointerHolder.hh` and see
16 16 :ref:`smart-pointers` for details on what you can do now to create
17 17 code that will continue to work with older versions of qpdf and be
18 18 easier to switch over to qpdf 11 when it comes out.
... ... @@ -139,7 +139,7 @@ For a detailed list of changes, please see the file
139 139 ``const`` argv array.
140 140  
141 141 - ``QPDF::emptyPDF`` has been exposed to the C API as
142   - ``qpdf_empty_pdf``. This makes it possible to create PDF from
  142 + ``qpdf_empty_pdf``. This makes it possible to create a PDF from
143 143 scratch with the C API.
144 144  
145 145 - New C API functions ``qpdf_oh_get_binary_utf8_value`` and
... ...