Commit 607345d00d512ef5a23a7a2485bd47e7d1597fe0
1 parent
9ae7bdea
Hand-fix formatting issues in TODO.md
Showing
2 changed files
with
25 additions
and
23 deletions
.git-blame-ignore-revs
| @@ -15,3 +15,4 @@ d740c6ccced02147f84a39d5e5f0984d12bac6cb | @@ -15,3 +15,4 @@ d740c6ccced02147f84a39d5e5f0984d12bac6cb | ||
| 15 | # Reflow comments and strings to 100 columns | 15 | # Reflow comments and strings to 100 columns |
| 16 | 698a70e6a84cf7c0db667e9d9e021b4c34c85a3e | 16 | 698a70e6a84cf7c0db667e9d9e021b4c34c85a3e |
| 17 | 3c5700c255f4603b5df9c6d183d13dd71a083cc3 | 17 | 3c5700c255f4603b5df9c6d183d13dd71a083cc3 |
| 18 | +9ae7bdea966102f9621b22192747a891078e7470 |
TODO.md
| @@ -46,14 +46,14 @@ Possible future JSON enhancements | @@ -46,14 +46,14 @@ Possible future JSON enhancements | ||
| 46 | 46 | ||
| 47 | * Consider not including unreferenced objects and trimming the trailer in the same way that | 47 | * Consider not including unreferenced objects and trimming the trailer in the same way that |
| 48 | QPDFWriter does (except don't remove `/ID`). This means excluding the linearization dictionary and | 48 | QPDFWriter does (except don't remove `/ID`). This means excluding the linearization dictionary and |
| 49 | - hint stream, the encryption dictionary, all keys from trailer that are removed by QPDFWriter:: | ||
| 50 | - getTrimmedTrailer except `/ID`, any object streams, and the xref stream as long as all those | ||
| 51 | - objects are unreferenced. (They always should be, but there could be some bizarre case of someone | ||
| 52 | - creating a PDF file that has an indirect reference to one of those, in which case we need to | ||
| 53 | - preserve it.) If this is done, make | ||
| 54 | - `--preserve-unreferenced` preserve unreference objects and also those extra keys. Search for " | ||
| 55 | - linear" and "trailer" in json.rst to update the various places in the documentation that discuss | ||
| 56 | - this. Also update the help for --json and --preserve-unreferenced. | 49 | + hint stream, the encryption dictionary, all keys from trailer that are removed by |
| 50 | + QPDFWriter::getTrimmedTrailer except `/ID`, any object streams, and the xref stream as long as all | ||
| 51 | + those objects are unreferenced. (They always should be, but there could be some bizarre case of | ||
| 52 | + someone creating a PDF file that has an indirect reference to one of those, in which case we need | ||
| 53 | + to preserve it.) If this is done, make `--preserve-unreferenced` preserve unreference objects and | ||
| 54 | + also those extra keys. Search for "linear" and "trailer" in json.rst to update the various places | ||
| 55 | + in the documentation that discuss this. Also update the help for --json and | ||
| 56 | + --preserve-unreferenced. | ||
| 57 | 57 | ||
| 58 | * Add to JSON output the information available from a few additional informational options: | 58 | * Add to JSON output the information available from a few additional informational options: |
| 59 | 59 | ||
| @@ -78,9 +78,8 @@ good -- just things to consider. | @@ -78,9 +78,8 @@ good -- just things to consider. | ||
| 78 | 78 | ||
| 79 | * How do we chain jobs? The idea would be that the input and/or output of a QPDFJob could be a QPDF | 79 | * How do we chain jobs? The idea would be that the input and/or output of a QPDFJob could be a QPDF |
| 80 | object rather than a file. For input, it's pretty easy. For output, none of the output-specific | 80 | object rather than a file. For input, it's pretty easy. For output, none of the output-specific |
| 81 | - options | ||
| 82 | - (encrypt, compress-streams, objects-streams, etc.) would have any affect, so we would have to | ||
| 83 | - treat this like inspect for error checking. The QPDF object in the state where it's ready to be | 81 | + options (encrypt, compress-streams, objects-streams, etc.) would have any affect, so we would have |
| 82 | + to treat this like inspect for error checking. The QPDF object in the state where it's ready to be | ||
| 84 | sent off to QPDFWriter would be used as the input to the next QPDFJob. For the job json, I think | 83 | sent off to QPDFWriter would be used as the input to the next QPDFJob. For the job json, I think |
| 85 | we can have the output be an identifier that can be used as the input for another QPDFJob. For a | 84 | we can have the output be an identifier that can be used as the input for another QPDFJob. For a |
| 86 | json file, we could the top level detect if it's an array with the convention that exactly one has | 85 | json file, we could the top level detect if it's an array with the convention that exactly one has |
| @@ -152,10 +151,10 @@ This is a list of known issues with text appearance streams and things we might | @@ -152,10 +151,10 @@ This is a list of known issues with text appearance streams and things we might | ||
| 152 | then remove anything that's unreferenced. We have all the code required for that in ResourceFinder | 151 | then remove anything that's unreferenced. We have all the code required for that in ResourceFinder |
| 153 | except TfFinder also gets the font size, which ResourceFinder doesn't do. | 152 | except TfFinder also gets the font size, which ResourceFinder doesn't do. |
| 154 | 153 | ||
| 155 | -* There are things we are missing because we don't look at font metrics. The code from TextBuilder ( | ||
| 156 | - work) has almost everything in it that is required. Once we have knowledge of character widths, we | ||
| 157 | - can support quadding and multiline text fields (/Ff 4096), and we can potentially squeeze text to | ||
| 158 | - fit into a field. For multiline, first squeeze vertically down to the font height, then squeeze | 154 | +* There are things we are missing because we don't look at font metrics. The code from TextBuilder |
| 155 | + (work) has almost everything in it that is required. Once we have knowledge of character widths, | ||
| 156 | + we can support quadding and multiline text fields (/Ff 4096), and we can potentially squeeze text | ||
| 157 | + to fit into a field. For multiline, first squeeze vertically down to the font height, then squeeze | ||
| 159 | horizontally with Tz. For single line, squeeze horizontally with Tz. If we use Tz, issue a | 158 | horizontally with Tz. For single line, squeeze horizontally with Tz. If we use Tz, issue a |
| 160 | warning. | 159 | warning. |
| 161 | 160 | ||
| @@ -164,9 +163,8 @@ This is a list of known issues with text appearance streams and things we might | @@ -164,9 +163,8 @@ This is a list of known issues with text appearance streams and things we might | ||
| 164 | to unicode to the width. See misc/character-encoding/ (not on github) | 163 | to unicode to the width. See misc/character-encoding/ (not on github) |
| 165 | and font metric information for the 14 standard fonts in my local pdf-spec directory. | 164 | and font metric information for the 14 standard fonts in my local pdf-spec directory. |
| 166 | 165 | ||
| 167 | -* Once we know about character widths, we can correctly support auto-sized variable text fields (0 | ||
| 168 | - Tf). If this is fixed, search for | ||
| 169 | - "auto-sized" in cli.rst. | 166 | +* Once we know about character widths, we can correctly support auto-sized variable text fields |
| 167 | + (0 Tf). If this is fixed, search for "auto-sized" in cli.rst. | ||
| 170 | 168 | ||
| 171 | Fuzz Errors | 169 | Fuzz Errors |
| 172 | =========== | 170 | =========== |
| @@ -240,8 +238,11 @@ For qpdf 12, see https://github.com/qpdf/qpdf/discussions/785 | @@ -240,8 +238,11 @@ For qpdf 12, see https://github.com/qpdf/qpdf/discussions/785 | ||
| 240 | C++ Version Changes | 238 | C++ Version Changes |
| 241 | =================== | 239 | =================== |
| 242 | 240 | ||
| 243 | -Use // C++NN: ... to mark places in the code that should be updated when we require at least that | ||
| 244 | -version of C++. | 241 | +Use |
| 242 | +``` | ||
| 243 | +// C++NN: ... | ||
| 244 | +``` | ||
| 245 | +to mark places in the code that should be updated when we require at least that version of C++. | ||
| 245 | 246 | ||
| 246 | Page splitting/merging | 247 | Page splitting/merging |
| 247 | ====================== | 248 | ====================== |
| @@ -653,9 +654,9 @@ Rejected Ideas | @@ -653,9 +654,9 @@ Rejected Ideas | ||
| 653 | 654 | ||
| 654 | QPDF_POINTER_TRANSITION = 0 -- no warnings around calling the QPDF constructor | 655 | QPDF_POINTER_TRANSITION = 0 -- no warnings around calling the QPDF constructor |
| 655 | QPDF_POINTER_TRANSITION = 1 -- calls to QPDF() are deprecated, but QPDF is still available so code | 656 | QPDF_POINTER_TRANSITION = 1 -- calls to QPDF() are deprecated, but QPDF is still available so code |
| 656 | - can be backward compatible and use std::make_shared<QPDF> | ||
| 657 | - QPDF_POINTER_TRANSITION = 2 -- the QPDF constructor is private; all calls to std:: | ||
| 658 | - make_shared<QPDF> have to be replaced with QPDF::create | 657 | + can be backward compatible and use std::make_shared<QPDF> |
| 658 | + QPDF_POINTER_TRANSITION = 2 -- the QPDF constructor is private; all calls to | ||
| 659 | + std::make_shared<QPDF> have to be replaced with QPDF::create | ||
| 659 | 660 | ||
| 660 | If we were to do this, we'd have to look at each use of QPDF* in the interface and decide whether | 661 | If we were to do this, we'd have to look at each use of QPDF* in the interface and decide whether |
| 661 | to use a std::shared_ptr or a std::weak_ptr. The answer would almost always be to use a std:: | 662 | to use a std::shared_ptr or a std::weak_ptr. The answer would almost always be to use a std:: |