TODO: Remove fixed item, move item into ABI section

1 files changed, 12 insertions, 39 deletions

diff --git a/TODO b/TODO
index e6a72c6c..9654059d 100644
--- a/TODO
+++ b/TODO
@@ -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.