[NTG-pdftex] [pdftex-Patches][1812] Patch for bug report 1751

pdftex-patches at sarovar.org pdftex-patches at sarovar.org
Wed Jun 25 17:43:23 CEST 2008


Patches item #1812, was opened at 2008-06-24 22:29
Status: Open
Priority: 3
Submitted By: Heiko Oberdiek (oberdiek)
Assigned to: The Thanh Han (hanthethanh)
Summary: Patch for bug report 1751 
>Resolution: Accepted
Group: v1.40.0
Category: PDF inclusion


Initial Comment:
Hello,

this patch fixes bug report 1751 "bounding box ignored?".
The source of the problem is pdftoepdf.cc: the contents
stream is copied with *all* entries, but only Length, Filter,
DecodeParms must be copied.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>

----------------------------------------------------------------------

Comment By: Heiko Oberdiek (oberdiek)
Date: 2008-06-25 08:59

Message:
Martin wrote:

> While this probably works, I prefer a different
> approach: Propagate all keys from the stream dict,
> but check for name collisons.

I disagree strongly:
"Table 3.27 Entries in a page object"
  (latest doc for PDF 1.7)
  "Contents:  stream or array
  A content stream describing the contents of this page"
Only the stream data are of interest.
Adding keys apart from generic stream keys (Filter,
DecodeParms, Length, ...) into a dictionary of a
probably different type is asking for trouble only
without having any benefit.
In contrary, the size of the PDF file increases.

> Your patch limits us to some (already known) keys
> and doesn't even handle all keys in table 3.4.
> And who knows which keys will be added in
> future PDF versions or if the PDF contains keys
> with application data? "Be liberal in what you
> accept."

In this case bug reports are more likely and have
happend already (bug #1751). Anyway, in case of
future PDF versions you will not know, what you
have to copy, too. Perhaps you also must add something
to the Catalog or adding something in name trees, ...

In case you expect some additions in the generic
stream keys (Filter, ...), switch to variant A
and wait for xpdf to implement this additions.
(I haven't checked xpdf to handle external streams.
In case it can handle them, variant A is better,
because it supports this feature indirectly.)
I had implented variant B for speed only, it
avoids uncompressing and recompressing the stream data.

> The input PDF in #1751 is broken.

AFAIK no:
| H.2 Feature Compatibility
| Many PDF features are introduced simply by add
| tionaries. Earlier versions of viewer applications
| such entries and behave as if they were not there.
| Such new features are therefore both forward- and
| backward-compatible. Likewise, adding entries not
| described in the PDF specification to dictionary
| objects does not affect the viewers' behavior.

Therefore it is even bug (#1751), if pdfTeX copies
unknown entries.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>

----------------------------------------------------------------------

Comment By: Martin Schröder (oneiros)
Date: 2008-06-25 06:59

Message:
While this probably works, I prefer a different approach: Propagate all keys from the stream dict, but check for name collisons. Not hard to do (just use an avl), but probably not worth it for pdfTeX anymore.
But see http://tracker.luatex.org/view.php?id=56

Your patch limits us to some (already known) keys and doesn't even handle all keys in table 3.4. And who knows which keys will be added in future PDF versions or if the PDF contains keys with application data? "Be liberal in what you accept."

The input PDF in #1751 is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sarovar.org/tracker/?func=detail&atid=495&aid=1812&group_id=106


More information about the ntg-pdftex mailing list