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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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