2
1
mirror of https://github.com/qpdf/qpdf.git synced 2024-06-02 02:10:52 +00:00

TODO: Remove fixed item, move item into ABI section

This commit is contained in:
Jay Berkenbilt 2019-12-30 08:56:06 -05:00
parent 1e0b1025f3
commit 0ae19c375e

51
TODO
View File

@ -16,6 +16,18 @@ Comments appear in the code prefixed by "ABI"
* QPDFPageObjectHelper::placeFormXObject: name should be std::string
const& (issue #374)
* (Source compatibiliy) As somewhat discussed in issue 219, the
original pipeStreamData in QPDF_Stream has various logic for
reporting warnings and letting the caller retry. This logic is not
implemented for stream data providers. When copying foreign streams,
qpdf uses a stream data provider (QPDF::CopiedStreamDataProvider) to
read the stream data from the original file. While a warning is
issued for that case, there is no way to actually propagate failure
information back through because
StreamDataProvider::provideStreamData doesn't take the
suppress_warnings or will_retry options, and adding them would break
source compatibility.
C++-11
======
@ -392,45 +404,6 @@ I find it useful to make reference to them in this list
logic error and what could happen because of malformed user input.
See also ../misc/linearization-errors.
* There are a few known limitations of copying foreign streams. These
are somewhat discussed in github issue 219. They are most likely
not worth fixing.
* The original pipeStreamData in QPDF_Stream has various logic for
reporting warnings and letting the caller retry. This logic is
not implemented for stream data providers. When copying foreign
streams, qpdf uses a stream data provider
(QPDF::CopiedStreamDataProvider) to read the stream data from the
original file. While a warning is issued for that case, there is
no way to actually propagate failure information back through
because StreamDataProvider::provideStreamData doesn't take the
suppress_warnings or will_retry options, and adding them would
break source compatibility.
* When copying streams that use StreamDataProvider provider, the
original QPDF object must still be kept around. This is the case
of where QPDF q1 has a stream for which replaceStreamData was
called to provide a StreamDataProvider, and then that stream from
q1 was subsequently copied to q2. In that case, q1 must be kept
around until q2 is written. That is a pretty unusual case as,
most of the time, people could just attach the stream data
provider directly to the q2. That said, it actually appears in
qpdf itself. qpdf allows you to combine the --pages and --split
options. In that case, a merged file, which uses
StreamDataProvider to access the original stream, is subsequently
copied to the final split output files. Solving this restriction
is difficult and would probably require breaking source
compatibility because QPDF_Stream doesn't have enough information
to know whether the original QPDF object is needed by the
stream's data provider. Also, the interface is designed to pass
the object ID and generation of the object whose data is being
provided so the provider can use it for lookup or any other
purpose. As such, copying a stream data provider to a new stream
potentially changes the meaning of the parameters passed to the
provider. This happens with CopiedStreamDataProvider, which uses
the object ID and generation of the new stream to locate the
parameters of the old stream.
* If I ever decide to make appearance stream-generation aware of
fonts or font metrics, see email from Tobias with Message-ID
<5C3C9C6C.8000102@thax.hardliners.org> dated 2019-01-14.