Re: Bug 687560 "Invalid PDF if /BP pdfmarks with non-unique /_objdef"

Hello again,

----- Original Message -----
From: "Igor Melichev" <[email protected]>
To: "SaGS" <[email protected]>; "gs-code-review"
<[email protected]>
Sent: Monday, 22 November 2004 13:14
Subject: Re: Bug 687560 "Invalid PDF if /BP pdfmarkswithnon-unique /_objdef"
xefitra


> ...
> If I remove "2.4. Cancel and free the old object"
> from my suggestion above, could it work ?
> ...

Well, I don't think this properly solves (or solves at all) the problem.
Indeed a "C-ptr" to this XObject will survive. From the point of view of "n
0 Refs" and FUTURE "C-ptrs", the XObject gets replaced, but from the point
of view of objects that ALREADY contain "C-ptrs", the XObject has NOT been
replaced. This is definitely not what PDF_NAMECOLLISION_REBUILD is intended
to achieve, the old copy being supposed to disappear. Plus, if the XObject
is later modified, the changes go to one or the other of the copies,
depending on which access path is used. Extra complications arrive because
of the risk of getting both copies written to the output file, getting a
damaged PDF (duplicate object number and/or dangling PDF object, depending
on how the "half lost" copy is treated).

Since you absolutely don't want pdf_alloc_aside() changed, I'd go with the
"surgery". At least that properly solves all problems, it's compact and
clear enough. Also, we don't risk future bugs caused by hidden assumptions
on how "half lost" objects are processed. The most "strange" of the 2 added
functions, cos_write_stream_redir(), is 99% a copy of its neighbour
cos_stream_from_pipeline(), so if it ever needs changes it cannot be
overlooked.