Re: Suggesting to cancel the bountiable status

----- Original Message -----
From: "Igor V. Melichev" <[email protected]>
To: "gs-code-review" <[email protected]>; "SaGS"
<[email protected]>
Cc: "Miles Jones" <[email protected]>
Sent: Friday, 26 November 2004 08:20
Subject: Suggesting to cancel the bountiable status (was Re:
[gs-code-review] Re: Bug 687560 "Invalid PDF if /BP pdfmarks withnon-unique
/_objdef") xefitra


> ...

> Thus you try to define a feature, which is not defined by Adobe or Jaws.

None FORMALLY defines it, but both implement it in a way or another. The
proposed patch includes all 3 implementations I found, to be able to choose
from. Of course, we can decide and keep only one of them.

> ...
> If you have no such writer, I'll close the bug with "wontfix".

Output PDFs will still be invalid... The initial bug report clearly states
there are 2 aspects of the patch: fix a bug + an enhancement (size
reduction). Even if you find the latter unimportant, there is still a
simple way to fix the former (see below).

>...
> A right semantics is either an error or a variable-like behavior.

A did agree with the variable-like semantics! In your message dated
November 24th, at point 3, you gave a C example of "variable-like"
behaviour, but you did not give its "PDF translation". Here is my
translation, if it does not match yours please give details of what
differs. It may be very well that you want in fact what I implemented
as PDF_NAMECOLLISION_BACKUP (and which does not need any "surgery").

- C identifier "a"                        distill-time name "{a}"
- values for variable "a"                 PDF objs created with name "{a}"

  a =                                     [/_objdef {a} ... /BP pdfmark
      1                                       (1) show
      ;                                   [/EP pdfmark

  b = &a;                                 [... /AP <</N {a}>> /ANN pdfmark
- pointer "b"                             "n 0 R" reference from the
appearance
                                          dictionary to object "{a}"

  a =                                     [/_objdef {a} ... /BP pdfmark
      2                                       (2) show
      ;                                   [/EP pdfmark
- new value "2" stored in the             "surgery" (cos_stream_move_all()
plus
  memory location for variable "a",       some technicalities to do this
operation
  replacing the old value "1"             at /BP time, since delaying until
/EP
                                          means many complications to store
some
                                          state information)

  c = &a;                                 [... /AP <</N {a}>> /ANN pdfmark
- value of pointer "c"                  - "n 0 R" reference from another
                                          appearance dict to "{a}"
- note that b == c                      - same "n" in both "n 0 R"s

  exit();                                 %%EOF
- at end of program, *b == *c == a      - Both appeareance dicts point to
the same
                                          XObject and both appearances
display "2"
                                        - Since the "value" that displays
"1" is not
                                          used (was "overwritten during a =
2") it
                                          is not written to the output PDF

I interpreted the "n 0 R"s as C pointers, that is they do not store the
actual value
"1" or "2". If you consider "n 0 R"s as "values", and suppose the "current
definition"
of the object is "logically copied" in those appearance dictionnaries, then
you get
what I implemented as PDF_NAMECOLLISION_BACKUP.

> ...
> After this discussion I see that we have not enough reasons to
> fix this bug, unless you bring new ones.

Proposed patch + the one for 687560 + complicated execforms = GhostScript
beats
Distiller at file size.

The parts of the patch you had objections on concerned the "enhancement"
aspect. You had no objections on PDF_NAMECOLLISION_BACKUP, and this one
alone solves the problem with the invalid output. So, the "bug" aspect
can still be fixed, despite our disagreements. I can do this change if
that will be OK with you.

> ...
> The "half" comes since you share the responsibility for opening this bug.
> Let me know if it is OK.

The initial bug report, dated July 7th, clearly states that it deals with
some undocumented behaviour and also the 2 aspects of the patch (fix +
enhancement). Also includes detailed explanations on the "enhancement"
part. The bounty was added on July 13th, with knowledge on what's there.
So, NO, that's not OK with me. (Anyway, if we reach an agreement on
keeping one of the possible fixes, this won't matter any more.)


mat. Gh Savulescu