Hand-fix formatting issues in TODO.md

This commit is contained in:
m-holger 2023-06-27 15:50:10 +01:00
parent 9ae7bdea96
commit 607345d00d
2 changed files with 25 additions and 23 deletions

View File

@ -15,3 +15,4 @@ d740c6ccced02147f84a39d5e5f0984d12bac6cb
# Reflow comments and strings to 100 columns # Reflow comments and strings to 100 columns
698a70e6a84cf7c0db667e9d9e021b4c34c85a3e 698a70e6a84cf7c0db667e9d9e021b4c34c85a3e
3c5700c255f4603b5df9c6d183d13dd71a083cc3 3c5700c255f4603b5df9c6d183d13dd71a083cc3
9ae7bdea966102f9621b22192747a891078e7470

47
TODO.md
View File

@ -46,14 +46,14 @@ Possible future JSON enhancements
* Consider not including unreferenced objects and trimming the trailer in the same way that * Consider not including unreferenced objects and trimming the trailer in the same way that
QPDFWriter does (except don't remove `/ID`). This means excluding the linearization dictionary and QPDFWriter does (except don't remove `/ID`). This means excluding the linearization dictionary and
hint stream, the encryption dictionary, all keys from trailer that are removed by QPDFWriter:: hint stream, the encryption dictionary, all keys from trailer that are removed by
getTrimmedTrailer except `/ID`, any object streams, and the xref stream as long as all those QPDFWriter::getTrimmedTrailer except `/ID`, any object streams, and the xref stream as long as all
objects are unreferenced. (They always should be, but there could be some bizarre case of someone those objects are unreferenced. (They always should be, but there could be some bizarre case of
creating a PDF file that has an indirect reference to one of those, in which case we need to someone creating a PDF file that has an indirect reference to one of those, in which case we need
preserve it.) If this is done, make to preserve it.) If this is done, make `--preserve-unreferenced` preserve unreference objects and
`--preserve-unreferenced` preserve unreference objects and also those extra keys. Search for " also those extra keys. Search for "linear" and "trailer" in json.rst to update the various places
linear" and "trailer" in json.rst to update the various places in the documentation that discuss in the documentation that discuss this. Also update the help for --json and
this. Also update the help for --json and --preserve-unreferenced. --preserve-unreferenced.
* Add to JSON output the information available from a few additional informational options: * Add to JSON output the information available from a few additional informational options:
@ -78,9 +78,8 @@ good -- just things to consider.
* How do we chain jobs? The idea would be that the input and/or output of a QPDFJob could be a QPDF * How do we chain jobs? The idea would be that the input and/or output of a QPDFJob could be a QPDF
object rather than a file. For input, it's pretty easy. For output, none of the output-specific object rather than a file. For input, it's pretty easy. For output, none of the output-specific
options options (encrypt, compress-streams, objects-streams, etc.) would have any affect, so we would have
(encrypt, compress-streams, objects-streams, etc.) would have any affect, so we would have to to treat this like inspect for error checking. The QPDF object in the state where it's ready to be
treat this like inspect for error checking. The QPDF object in the state where it's ready to be
sent off to QPDFWriter would be used as the input to the next QPDFJob. For the job json, I think sent off to QPDFWriter would be used as the input to the next QPDFJob. For the job json, I think
we can have the output be an identifier that can be used as the input for another QPDFJob. For a we can have the output be an identifier that can be used as the input for another QPDFJob. For a
json file, we could the top level detect if it's an array with the convention that exactly one has 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
then remove anything that's unreferenced. We have all the code required for that in ResourceFinder then remove anything that's unreferenced. We have all the code required for that in ResourceFinder
except TfFinder also gets the font size, which ResourceFinder doesn't do. except TfFinder also gets the font size, which ResourceFinder doesn't do.
* There are things we are missing because we don't look at font metrics. The code from TextBuilder ( * There are things we are missing because we don't look at font metrics. The code from TextBuilder
work) has almost everything in it that is required. Once we have knowledge of character widths, we (work) has almost everything in it that is required. Once we have knowledge of character widths,
can support quadding and multiline text fields (/Ff 4096), and we can potentially squeeze text to we can support quadding and multiline text fields (/Ff 4096), and we can potentially squeeze text
fit into a field. For multiline, first squeeze vertically down to the font height, then squeeze to fit into a field. For multiline, first squeeze vertically down to the font height, then squeeze
horizontally with Tz. For single line, squeeze horizontally with Tz. If we use Tz, issue a horizontally with Tz. For single line, squeeze horizontally with Tz. If we use Tz, issue a
warning. warning.
@ -164,9 +163,8 @@ This is a list of known issues with text appearance streams and things we might
to unicode to the width. See misc/character-encoding/ (not on github) to unicode to the width. See misc/character-encoding/ (not on github)
and font metric information for the 14 standard fonts in my local pdf-spec directory. and font metric information for the 14 standard fonts in my local pdf-spec directory.
* Once we know about character widths, we can correctly support auto-sized variable text fields (0 * Once we know about character widths, we can correctly support auto-sized variable text fields
Tf). If this is fixed, search for (0 Tf). If this is fixed, search for "auto-sized" in cli.rst.
"auto-sized" in cli.rst.
Fuzz Errors Fuzz Errors
=========== ===========
@ -240,8 +238,11 @@ For qpdf 12, see https://github.com/qpdf/qpdf/discussions/785
C++ Version Changes C++ Version Changes
=================== ===================
Use // C++NN: ... to mark places in the code that should be updated when we require at least that Use
version of C++. ```
// C++NN: ...
```
to mark places in the code that should be updated when we require at least that version of C++.
Page splitting/merging Page splitting/merging
====================== ======================
@ -653,9 +654,9 @@ Rejected Ideas
QPDF_POINTER_TRANSITION = 0 -- no warnings around calling the QPDF constructor QPDF_POINTER_TRANSITION = 0 -- no warnings around calling the QPDF constructor
QPDF_POINTER_TRANSITION = 1 -- calls to QPDF() are deprecated, but QPDF is still available so code QPDF_POINTER_TRANSITION = 1 -- calls to QPDF() are deprecated, but QPDF is still available so code
can be backward compatible and use std::make_shared<QPDF> can be backward compatible and use std::make_shared<QPDF>
QPDF_POINTER_TRANSITION = 2 -- the QPDF constructor is private; all calls to std:: QPDF_POINTER_TRANSITION = 2 -- the QPDF constructor is private; all calls to
make_shared<QPDF> have to be replaced with QPDF::create std::make_shared<QPDF> have to be replaced with QPDF::create
If we were to do this, we'd have to look at each use of QPDF* in the interface and decide whether If we were to do this, we'd have to look at each use of QPDF* in the interface and decide whether
to use a std::shared_ptr or a std::weak_ptr. The answer would almost always be to use a std:: to use a std::shared_ptr or a std::weak_ptr. The answer would almost always be to use a std::