- ntg-pdftex - NTG Mailing Lists

[pdftex-Feature Requests][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-featurerequests＠sarovar.org 28 Jun '08

28 Jun '08

Feature Requests item #1242, was opened at 2008-06-06 12:53 Status: Open Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: Group: Category: Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2008-06-07 07:39 Message: I can see this is can easily be a problem everywhere, especially in networked environments, so will reopen the report, but file locking is probably not the best way to fix the symptoms. Locking files (and detecting locks) on a local harddisk is already quite hard to implement in a portable manner, never mind attempting todo the same over a network share. So if you really want file locking, you probably should talk to the miktex maintainer, as that is not likely to make it into pdftex (or luatex)'s core distribution. However, it would be pretty easy to make pdftex create a PDF file with a temporary name and rename it only at the end of a succesful run. As a side bonus, that would also prevent the existance of partial == broken pdfs. I believe that is something to consider for 1.50 or luatex. ---------------------------------------------------------------------- Comment By: William Blum (wblum) Date: 2008-06-06 21:20 Message: > We don't support MikTeX-pdfTeX; please discuss this with the > MikTeX maintainer. This bug does not affect only MikTex! I have just tried with teTeX on cygwin and the same problem occurs. I suspect that all TeX distributions suffer from the same bug since there is no reason for them to change the way the files are opened by pdftex. Since all distributions derive from the pdftex code maintained here, I though it would make more sense to patch the bug at the source... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-06 13:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=1242&group_id=106

1 0

[pdftex-Bugs][1751] bounding box ignored?
by pdftex-bugs＠sarovar.org 28 Jun '08

28 Jun '08

Bugs item #1751, was opened at 2008-06-23 09:28 >Status: Closed Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: The Thanh Han (hanthethanh) Summary: bounding box ignored? Resolution: Accepted Group: v1.40.3 Category: PDF inclusion Initial Comment: Hello, I've got a problem with a pdf inclusion using includegraphics. I've made a screendump with Firefox using the "Print to File" option and selected pdf as format. Using Acrobat, I've cropped the figure. In kpdf or acroread the result (attached) looks ok. However, when I create a LaTeX document containing this figure, the output depends on the viewer...: correct output shown in kpdf, incorrect output shown in acroread since cropping is ignored. I also get the following message: PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it. I don't know whether it's related to the above problem. Best regards Stefan ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-28 13:58 Message: fixed by Heiko, patch is in 1.40.8-rc2 ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2008-06-25 11:57 Message: The non standard page content stream dictionary produced by cairo (and hence Firefox 3) is my fault. The reason I did that is due to the way cairo handles fallback images for Porter-Duff operations not supported by PDF (ie all of them except Source OVER Destination). When one or more fallback images are required, cairo puts a knockout group in the page content. The first thing in the knockout group is another group containing the natively supported content. The rest of the knockout group contains the fallback images. The knockout group is required to ensure the fallback images do not composite with any native content underneath the image. The problem is at the time the page content stream is streamed out to the file it is not known whether any fallback images are required. I did not want to include a knockout group unless it is actually required. The content stream has an XObject dictionary because at the time the content is written it is not known whether the content stream will be belong to the page or be an XObject in a knockout group. As far as I can tell from reading the PDF Reference this is not incorrect but I agree that this is not standard practice in PDF files. As it is causing problems I will work on a fix for cairo to ensure that the page content stream does not include an XObject dictionary. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 09:52 Message: the pdf looks a bit weird, but after a few tests using all applications I have access to, I could not find any application that complains that this pdf is broken or invalid. This includes acrobat 8 preflight/pdf analysis/Report PDF syntax issues and a few more preflight tests. The only thing that failed is that when I converted the pdf to ps using acrobat reader (4.05 on linux), then gs fails to display that ps. But this happens very often (ie printing from pdf to ps using acrobat reader, then checking the ps by gs). On the other hand, printing to pdf using pdftops and checking the ps with gs went ok, too. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 09:05 Message: Martin wrote: > This file is IMHO broken: Object 3 is an XObject dict, > but is used for the Contents of page 1 (object 23). In this case the application is a little too sloppy and can be fixed. But there is an counter example: the same "contents" stream could be shared between a Page and an XObject. This decreases the file size, because it avoids duplication of streams. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 08:33 Message: I am of the same opinion as Heiko. The reason why content streams are copied entirely is that I didn't expect those streams to contain anything else apart from entries commond for all streams (eg those listed in table 3.4 in pdf spec). However, I also could not find anything explicitly saying that additional entries are not allowed. Heiko's patch looks good to me. So, here is my vote for that patch. Better to copy only what is required, than to copy everything including what is undefined. Variant A looks simple and clean, but it will slow down pdf inclusion, since the streams must be uncompressed and re-compressed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 08:28 Message: Thanks. This file is IMHO broken: Object 3 is an XObject dict, but is used for the Contents of page 1 (object 23). Can you please file a bug report against FireFox at https://bugzilla.mozilla.org/ and report the bug url here, so that I can chime in there? ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-25 08:05 Message: I've attached the original output from Firefox 3. Regards Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 07:02 Message: Of course the stream dict may contain arbitrary keys; but the input PDF here is IMHO broken; at least it's a borderline case (who needs a /BBox or /Group in a stream dict?). ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-24 22:34 Message: The /Contents stream object may contain additional entries, I haven't found something in the PDF specification that would forbid this. Therefore the PDF inclusion code needs fixing. Instead of copying the whole dictionary, this should be limited to /Length, /Filter, and /DecodeParms. (I assume external streams aren't supported.) Patch 1812 contains a patch for pdftoepdf.cc. The commented variant A recompresses the stream, controlled by \pdfcompresslevel. Variant B is more complicate, it copies the needed entries manually and copies the stream without recompressing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 20:21 Message: right, Martin. Now i see: the page /Contents stream object no. 3 in crop_problem.pdf looks like an /XObject, but only /Filter and /Length should be there (or the ones in Table 3.4 of the PDFRef.) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 18:32 Message: hmm, there are /BBox entries and /Resources in the many /Pattern objects, both of which are ok and even required by the PDF Spec. Also, having the same /Resources in the /Page and the /XObject dict. should be ok. The crop_problem.pdf just looks a little weird, but not wrong. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 14:20 Message: Can you attach the original PDF from FF? The content stream dict of crop_problem.pdf has some keys that don't belog there (BBox, Resources)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 22:54 Message: Confirmed. We get two BBoxes... :-( ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 13:37 Message: Confirmed. I'm tempted to call it a bug in AR; I'll talk to Adobe. ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-23 10:58 Message: I have attached test2-sb.pdf and test2-sb.log. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 10:20 Message: The page group bug is fixed in 1.40.6, btw. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 10:19 Message: It works for me. :-) Can you try the attached test2.tex and attach your pdf and log, please? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1751&group_id=106

1 0

[pdftex-Bugs][1866] problem with handling some TrueType fonts
by pdftex-bugs＠sarovar.org 28 Jun '08

28 Jun '08

Bugs item #1866, was opened at 2008-06-27 07:11 >Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: problem with handling some TrueType fonts Resolution: Accepted Group: v1.40.6 Category: Fonts Initial Comment: during a thorough test on all large TrueType fonts listed at http://en.wikipedia.org/wiki/Unicode_typefaces, 2 problems were discovered: 1. pdftex segfaults with fonts having very high number of glyphs. 2. font names were not handled properly in some border case, resulted in an invalid pdf. Fix will be included in 1.40.8-rc2. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1866&group_id=106

1 0

pdftex-1.40.8-rc2
by The Thanh Han 27 Jun '08

27 Jun '08

Hi, another RC version is available for testing: http://sarovar.org/frs/download.php/1236/pdftex-1.40.8-rc2.tar.bz2 - Bugfixes: - some large TrueType fonts caused pdftex to segfault (1866) - fix for copying contents streams of included pdf (1751) Thanh

1 0

[pdftex-Bugs][1866] problem with handling some TrueType fonts
by pdftex-bugs＠sarovar.org 27 Jun '08

27 Jun '08

Bugs item #1866, was opened at 2008-06-27 07:11 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: problem with handling some TrueType fonts Resolution: Accepted Group: v1.40.6 Category: Fonts Initial Comment: during a thorough test on all large TrueType fonts listed at http://en.wikipedia.org/wiki/Unicode_typefaces, 2 problems were discovered: 1. pdftex segfaults with fonts having very high number of glyphs. 2. font names were not handled properly in some border case, resulted in an invalid pdf. Fix will be included in 1.40.8-rc2. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1866&group_id=106

1 0

[pdftex-Patches][1812] Patch for bug report 1751
by pdftex-patches＠sarovar.org 25 Jun '08

25 Jun '08

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(a)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(a)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

1 0

[pdftex-Patches][1812] Patch for bug report 1751
by pdftex-patches＠sarovar.org 25 Jun '08

25 Jun '08

Patches item #1812, was opened at 2008-06-25 00:29 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) >Assigned to: The Thanh Han (hanthethanh) Summary: Patch for bug report 1751 Resolution: None 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(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 10: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(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 08: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

1 0

[pdftex-Bugs][1751] bounding box ignored?
by pdftex-bugs＠sarovar.org 25 Jun '08

25 Jun '08

Bugs item #1751, was opened at 2008-06-23 11:28 Status: Open Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) >Assigned to: The Thanh Han (hanthethanh) Summary: bounding box ignored? Resolution: Accepted Group: v1.40.3 Category: PDF inclusion Initial Comment: Hello, I've got a problem with a pdf inclusion using includegraphics. I've made a screendump with Firefox using the "Print to File" option and selected pdf as format. Using Acrobat, I've cropped the figure. In kpdf or acroread the result (attached) looks ok. However, when I create a LaTeX document containing this figure, the output depends on the viewer...: correct output shown in kpdf, incorrect output shown in acroread since cropping is ignored. I also get the following message: PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it. I don't know whether it's related to the above problem. Best regards Stefan ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2008-06-25 13:57 Message: The non standard page content stream dictionary produced by cairo (and hence Firefox 3) is my fault. The reason I did that is due to the way cairo handles fallback images for Porter-Duff operations not supported by PDF (ie all of them except Source OVER Destination). When one or more fallback images are required, cairo puts a knockout group in the page content. The first thing in the knockout group is another group containing the natively supported content. The rest of the knockout group contains the fallback images. The knockout group is required to ensure the fallback images do not composite with any native content underneath the image. The problem is at the time the page content stream is streamed out to the file it is not known whether any fallback images are required. I did not want to include a knockout group unless it is actually required. The content stream has an XObject dictionary because at the time the content is written it is not known whether the content stream will be belong to the page or be an XObject in a knockout group. As far as I can tell from reading the PDF Reference this is not incorrect but I agree that this is not standard practice in PDF files. As it is causing problems I will work on a fix for cairo to ensure that the page content stream does not include an XObject dictionary. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 11:52 Message: the pdf looks a bit weird, but after a few tests using all applications I have access to, I could not find any application that complains that this pdf is broken or invalid. This includes acrobat 8 preflight/pdf analysis/Report PDF syntax issues and a few more preflight tests. The only thing that failed is that when I converted the pdf to ps using acrobat reader (4.05 on linux), then gs fails to display that ps. But this happens very often (ie printing from pdf to ps using acrobat reader, then checking the ps by gs). On the other hand, printing to pdf using pdftops and checking the ps with gs went ok, too. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 11:05 Message: Martin wrote: > This file is IMHO broken: Object 3 is an XObject dict, > but is used for the Contents of page 1 (object 23). In this case the application is a little too sloppy and can be fixed. But there is an counter example: the same "contents" stream could be shared between a Page and an XObject. This decreases the file size, because it avoids duplication of streams. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 10:33 Message: I am of the same opinion as Heiko. The reason why content streams are copied entirely is that I didn't expect those streams to contain anything else apart from entries commond for all streams (eg those listed in table 3.4 in pdf spec). However, I also could not find anything explicitly saying that additional entries are not allowed. Heiko's patch looks good to me. So, here is my vote for that patch. Better to copy only what is required, than to copy everything including what is undefined. Variant A looks simple and clean, but it will slow down pdf inclusion, since the streams must be uncompressed and re-compressed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 10:28 Message: Thanks. This file is IMHO broken: Object 3 is an XObject dict, but is used for the Contents of page 1 (object 23). Can you please file a bug report against FireFox at https://bugzilla.mozilla.org/ and report the bug url here, so that I can chime in there? ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-25 10:05 Message: I've attached the original output from Firefox 3. Regards Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 09:02 Message: Of course the stream dict may contain arbitrary keys; but the input PDF here is IMHO broken; at least it's a borderline case (who needs a /BBox or /Group in a stream dict?). ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 00:34 Message: The /Contents stream object may contain additional entries, I haven't found something in the PDF specification that would forbid this. Therefore the PDF inclusion code needs fixing. Instead of copying the whole dictionary, this should be limited to /Length, /Filter, and /DecodeParms. (I assume external streams aren't supported.) Patch 1812 contains a patch for pdftoepdf.cc. The commented variant A recompresses the stream, controlled by \pdfcompresslevel. Variant B is more complicate, it copies the needed entries manually and copies the stream without recompressing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 22:21 Message: right, Martin. Now i see: the page /Contents stream object no. 3 in crop_problem.pdf looks like an /XObject, but only /Filter and /Length should be there (or the ones in Table 3.4 of the PDFRef.) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 20:32 Message: hmm, there are /BBox entries and /Resources in the many /Pattern objects, both of which are ok and even required by the PDF Spec. Also, having the same /Resources in the /Page and the /XObject dict. should be ok. The crop_problem.pdf just looks a little weird, but not wrong. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 16:20 Message: Can you attach the original PDF from FF? The content stream dict of crop_problem.pdf has some keys that don't belog there (BBox, Resources)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 00:54 Message: Confirmed. We get two BBoxes... :-( ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 15:37 Message: Confirmed. I'm tempted to call it a bug in AR; I'll talk to Adobe. ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-23 12:58 Message: I have attached test2-sb.pdf and test2-sb.log. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 12:20 Message: The page group bug is fixed in 1.40.6, btw. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 12:19 Message: It works for me. :-) Can you try the attached test2.tex and attach your pdf and log, please? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1751&group_id=106

1 0

[pdftex-Bugs][1751] bounding box ignored?
by pdftex-bugs＠sarovar.org 25 Jun '08

25 Jun '08

Bugs item #1751, was opened at 2008-06-23 18:58 Status: Open Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Martin Schröder (oneiros) Summary: bounding box ignored? Resolution: Accepted Group: v1.40.3 Category: PDF inclusion Initial Comment: Hello, I've got a problem with a pdf inclusion using includegraphics. I've made a screendump with Firefox using the "Print to File" option and selected pdf as format. Using Acrobat, I've cropped the figure. In kpdf or acroread the result (attached) looks ok. However, when I create a LaTeX document containing this figure, the output depends on the viewer...: correct output shown in kpdf, incorrect output shown in acroread since cropping is ignored. I also get the following message: PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it. I don't know whether it's related to the above problem. Best regards Stefan ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2008-06-25 21:27 Message: The non standard page content stream dictionary produced by cairo (and hence Firefox 3) is my fault. The reason I did that is due to the way cairo handles fallback images for Porter-Duff operations not supported by PDF (ie all of them except Source OVER Destination). When one or more fallback images are required, cairo puts a knockout group in the page content. The first thing in the knockout group is another group containing the natively supported content. The rest of the knockout group contains the fallback images. The knockout group is required to ensure the fallback images do not composite with any native content underneath the image. The problem is at the time the page content stream is streamed out to the file it is not known whether any fallback images are required. I did not want to include a knockout group unless it is actually required. The content stream has an XObject dictionary because at the time the content is written it is not known whether the content stream will be belong to the page or be an XObject in a knockout group. As far as I can tell from reading the PDF Reference this is not incorrect but I agree that this is not standard practice in PDF files. As it is causing problems I will work on a fix for cairo to ensure that the page content stream does not include an XObject dictionary. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 19:22 Message: the pdf looks a bit weird, but after a few tests using all applications I have access to, I could not find any application that complains that this pdf is broken or invalid. This includes acrobat 8 preflight/pdf analysis/Report PDF syntax issues and a few more preflight tests. The only thing that failed is that when I converted the pdf to ps using acrobat reader (4.05 on linux), then gs fails to display that ps. But this happens very often (ie printing from pdf to ps using acrobat reader, then checking the ps by gs). On the other hand, printing to pdf using pdftops and checking the ps with gs went ok, too. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 18:35 Message: Martin wrote: > This file is IMHO broken: Object 3 is an XObject dict, > but is used for the Contents of page 1 (object 23). In this case the application is a little too sloppy and can be fixed. But there is an counter example: the same "contents" stream could be shared between a Page and an XObject. This decreases the file size, because it avoids duplication of streams. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 18:03 Message: I am of the same opinion as Heiko. The reason why content streams are copied entirely is that I didn't expect those streams to contain anything else apart from entries commond for all streams (eg those listed in table 3.4 in pdf spec). However, I also could not find anything explicitly saying that additional entries are not allowed. Heiko's patch looks good to me. So, here is my vote for that patch. Better to copy only what is required, than to copy everything including what is undefined. Variant A looks simple and clean, but it will slow down pdf inclusion, since the streams must be uncompressed and re-compressed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 17:58 Message: Thanks. This file is IMHO broken: Object 3 is an XObject dict, but is used for the Contents of page 1 (object 23). Can you please file a bug report against FireFox at https://bugzilla.mozilla.org/ and report the bug url here, so that I can chime in there? ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-25 17:35 Message: I've attached the original output from Firefox 3. Regards Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 16:32 Message: Of course the stream dict may contain arbitrary keys; but the input PDF here is IMHO broken; at least it's a borderline case (who needs a /BBox or /Group in a stream dict?). ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 08:04 Message: The /Contents stream object may contain additional entries, I haven't found something in the PDF specification that would forbid this. Therefore the PDF inclusion code needs fixing. Instead of copying the whole dictionary, this should be limited to /Length, /Filter, and /DecodeParms. (I assume external streams aren't supported.) Patch 1812 contains a patch for pdftoepdf.cc. The commented variant A recompresses the stream, controlled by \pdfcompresslevel. Variant B is more complicate, it copies the needed entries manually and copies the stream without recompressing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-25 05:51 Message: right, Martin. Now i see: the page /Contents stream object no. 3 in crop_problem.pdf looks like an /XObject, but only /Filter and /Length should be there (or the ones in Table 3.4 of the PDFRef.) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-25 04:02 Message: hmm, there are /BBox entries and /Resources in the many /Pattern objects, both of which are ok and even required by the PDF Spec. Also, having the same /Resources in the /Page and the /XObject dict. should be ok. The crop_problem.pdf just looks a little weird, but not wrong. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 23:50 Message: Can you attach the original PDF from FF? The content stream dict of crop_problem.pdf has some keys that don't belog there (BBox, Resources)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 08:24 Message: Confirmed. We get two BBoxes... :-( ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 23:07 Message: Confirmed. I'm tempted to call it a bug in AR; I'll talk to Adobe. ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-23 20:28 Message: I have attached test2-sb.pdf and test2-sb.log. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 19:50 Message: The page group bug is fixed in 1.40.6, btw. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 19:49 Message: It works for me. :-) Can you try the attached test2.tex and attach your pdf and log, please? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1751&group_id=106

1 0

[pdftex-Bugs][1751] bounding box ignored?
by pdftex-bugs＠sarovar.org 25 Jun '08

25 Jun '08

Bugs item #1751, was opened at 2008-06-23 09:28 Status: Open Priority: 3 Submitted By: Stefan Becuwe (sbecuwe) Assigned to: Martin Schröder (oneiros) Summary: bounding box ignored? Resolution: Accepted Group: v1.40.3 Category: PDF inclusion Initial Comment: Hello, I've got a problem with a pdf inclusion using includegraphics. I've made a screendump with Firefox using the "Print to File" option and selected pdf as format. Using Acrobat, I've cropped the figure. In kpdf or acroread the result (attached) looks ok. However, when I create a LaTeX document containing this figure, the output depends on the viewer...: correct output shown in kpdf, incorrect output shown in acroread since cropping is ignored. I also get the following message: PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it. I don't know whether it's related to the above problem. Best regards Stefan ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 09:52 Message: the pdf looks a bit weird, but after a few tests using all applications I have access to, I could not find any application that complains that this pdf is broken or invalid. This includes acrobat 8 preflight/pdf analysis/Report PDF syntax issues and a few more preflight tests. The only thing that failed is that when I converted the pdf to ps using acrobat reader (4.05 on linux), then gs fails to display that ps. But this happens very often (ie printing from pdf to ps using acrobat reader, then checking the ps by gs). On the other hand, printing to pdf using pdftops and checking the ps with gs went ok, too. ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-25 09:05 Message: Martin wrote: > This file is IMHO broken: Object 3 is an XObject dict, > but is used for the Contents of page 1 (object 23). In this case the application is a little too sloppy and can be fixed. But there is an counter example: the same "contents" stream could be shared between a Page and an XObject. This decreases the file size, because it avoids duplication of streams. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-06-25 08:33 Message: I am of the same opinion as Heiko. The reason why content streams are copied entirely is that I didn't expect those streams to contain anything else apart from entries commond for all streams (eg those listed in table 3.4 in pdf spec). However, I also could not find anything explicitly saying that additional entries are not allowed. Heiko's patch looks good to me. So, here is my vote for that patch. Better to copy only what is required, than to copy everything including what is undefined. Variant A looks simple and clean, but it will slow down pdf inclusion, since the streams must be uncompressed and re-compressed. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 08:28 Message: Thanks. This file is IMHO broken: Object 3 is an XObject dict, but is used for the Contents of page 1 (object 23). Can you please file a bug report against FireFox at https://bugzilla.mozilla.org/ and report the bug url here, so that I can chime in there? ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-25 08:05 Message: I've attached the original output from Firefox 3. Regards Stefan ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-25 07:02 Message: Of course the stream dict may contain arbitrary keys; but the input PDF here is IMHO broken; at least it's a borderline case (who needs a /BBox or /Group in a stream dict?). ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2008-06-24 22:34 Message: The /Contents stream object may contain additional entries, I haven't found something in the PDF specification that would forbid this. Therefore the PDF inclusion code needs fixing. Instead of copying the whole dictionary, this should be limited to /Length, /Filter, and /DecodeParms. (I assume external streams aren't supported.) Patch 1812 contains a patch for pdftoepdf.cc. The commented variant A recompresses the stream, controlled by \pdfcompresslevel. Variant B is more complicate, it copies the needed entries manually and copies the stream without recompressing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 20:21 Message: right, Martin. Now i see: the page /Contents stream object no. 3 in crop_problem.pdf looks like an /XObject, but only /Filter and /Length should be there (or the ones in Table 3.4 of the PDFRef.) Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-06-24 18:32 Message: hmm, there are /BBox entries and /Resources in the many /Pattern objects, both of which are ok and even required by the PDF Spec. Also, having the same /Resources in the /Page and the /XObject dict. should be ok. The crop_problem.pdf just looks a little weird, but not wrong. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-24 14:20 Message: Can you attach the original PDF from FF? The content stream dict of crop_problem.pdf has some keys that don't belog there (BBox, Resources)... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 22:54 Message: Confirmed. We get two BBoxes... :-( ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 13:37 Message: Confirmed. I'm tempted to call it a bug in AR; I'll talk to Adobe. ---------------------------------------------------------------------- Comment By: Stefan Becuwe (sbecuwe) Date: 2008-06-23 10:58 Message: I have attached test2-sb.pdf and test2-sb.log. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 10:20 Message: The page group bug is fixed in 1.40.6, btw. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-23 10:19 Message: It works for me. :-) Can you try the attached test2.tex and attach your pdf and log, please? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1751&group_id=106

1 0