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

----- Original Message ----- 
From: "Igor V. Melichev" <[email protected]>
To: "SaGS" <[email protected]>; "gs-code-review" <[email protected]>
Sent: Wednesday, November 24, 2004 8:15 AM
Subject: Re: Bug 687560 "Invalid PDF if /BP pdfmarks with non-unique /_objdef"


> Dear SaGS,
> 
>> Well, I don't think this properly solves (or solves at all) the problem.
> 
> First of all I would clarify, what kind of demandics is wanted.
> 
> Suppose we have 2 consequtive objdef with same name.
> The question is how to intrerpret it.
> Lets look how various programming landuages do.
> 
> 1. An unscoped definition-like interpretation.
> An example is C language, global static definitions :
> 
>    struct mystruct1 a;
>    struct mystruct2 a;
> 
> The interpretation result is syntax error.
> 
> 2. A scoped definition-like interpretation.
> An example is C language, local definitions :
> 
>    struct mystruct1 a;
>    { struct mystruct2 a;
>       ......
>     }
> 
> The interpretation result is 2 objects with different life times.
> 
> 3. A variable-like interpretation.
> An example is C language, variables :
> 
>   int a, *b, *c;
> 
>    a = 1;
>    b = &a;
>    a = 2;
>    c = &a;
> 
> The interpretation result is a varying referent, same for b and c.
> 
> 4. A pointer-like interpretation.
> An example is C++ language, pointers :
> 
>   int *a, *b;
> 
>    a =  new int;
>    b = a;
>    a = new int;
>    c = a;
> 
> The interpretation result is two different referents for b and c.
> 
> 5. An merge-like interpretation.
> An example may be taken from G.Tseytin's puplications about "associative nets"
> (let me know if you need an exact reference).
> 
>   let a be new NULL
>   let Nicolo be new child (father = new NULL, mother = "Tanya")
>   a += A.father
>   let Alex be new child (father = new NULL, mother = "Olga");
>   a += B.father
> 
> (note that here I used a different syntax than G.Tseytin;
> NULL is an object with no properties).
> The result is 2 children with same father, and we have no 
> information about the father besides he has the 2 children.
> 
> So now we need to choose one of variants above.
> IMO (5) is out of our interest, because PS/PDF is not so advanced
> (at least there are no other places with a merge-like semantics).
> My old vote is either (1) or (4), but now I'm not sure whether we can
> ignore (2).
> 
> As to you vote, I still can't classify it for sure.
> Please clarify.
> 
> Igor.
>    
> 
> ----- Original Message ----- 
> From: "SaGS" <[email protected]>
> To: "Igor Melichev" <[email protected]>; "gs-code-review" <[email protected]>
> Sent: Wednesday, November 24, 2004 12:13 AM
> Subject: 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.
>>