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
TODO.md
| ... | ... | @@ -46,14 +46,14 @@ Possible future JSON enhancements |
| 46 | 46 | |
| 47 | 47 | * Consider not including unreferenced objects and trimming the trailer in the same way that |
| 48 | 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 | 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 | 78 | |
| 79 | 79 | * How do we chain jobs? The idea would be that the input and/or output of a QPDFJob could be a QPDF |
| 80 | 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 | 83 | sent off to QPDFWriter would be used as the input to the next QPDFJob. For the job json, I think |
| 85 | 84 | we can have the output be an identifier that can be used as the input for another QPDFJob. For a |
| 86 | 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 | 151 | then remove anything that's unreferenced. We have all the code required for that in ResourceFinder |
| 153 | 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 | 158 | horizontally with Tz. For single line, squeeze horizontally with Tz. If we use Tz, issue a |
| 160 | 159 | warning. |
| 161 | 160 | |
| ... | ... | @@ -164,9 +163,8 @@ This is a list of known issues with text appearance streams and things we might |
| 164 | 163 | to unicode to the width. See misc/character-encoding/ (not on github) |
| 165 | 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 | 169 | Fuzz Errors |
| 172 | 170 | =========== |
| ... | ... | @@ -240,8 +238,11 @@ For qpdf 12, see https://github.com/qpdf/qpdf/discussions/785 |
| 240 | 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 | 247 | Page splitting/merging |
| 247 | 248 | ====================== |
| ... | ... | @@ -653,9 +654,9 @@ Rejected Ideas |
| 653 | 654 | |
| 654 | 655 | QPDF_POINTER_TRANSITION = 0 -- no warnings around calling the QPDF constructor |
| 655 | 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 | 661 | If we were to do this, we'd have to look at each use of QPDF* in the interface and decide whether |
| 661 | 662 | to use a std::shared_ptr or a std::weak_ptr. The answer would almost always be to use a std:: | ... | ... |