Created attachment 6055 [details] Test input file I've begun testing 8.71 in our conversion chain and the exact same ghostscript arguments and input file used with 8.70 for PDF->TIFFG3 output result in TIFFs that are rejected by our T.37 gateway. config line (used for both, prefix modified): ./configure --prefix=/usr/local/gs87x --disable-cups --disable-gtk --disable-cairo --disable-fontconfig --without-libpaper --without-pdftoraster --without-ijs --without-jbig2dec --without-jasper --without-omni --without-x --with-drivers=FILES conversion args: gs -dNOPAUSE -dBATCH -sDEVICE=tiffg3 -dPDFFitPage -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile=out.tif in.pdf
Created attachment 6056 [details] 8.70 tiffg3 output accepted by our T.37 gateway
Created attachment 6057 [details] 8.71 tiffg3 output rejected by our T.37 gateway
Without an error message or further analysis as to why the 'T.37 gateway' rejects the TIFF file, we cannot work on this. Note that the 8.71 changes to use 'libtiff' with a default MaxStripSize=8192, so if the T.37 gateway cannot handle multi-strip TIFF files (as some fax software cannot) this may be the source of the error (just a guess). Multi-strip TIFF files are part of the TIFF spec and any reader that cannot handle them is flawed. To revert to the 8.70 behavior, try -dMaxStripSize=0 (unlimited strip size, so only a single strip will be produced per page). This can also be built into the binary by changing base/gdevtifs.h line 53 from: #define TIFF_DEFAULT_STRIP_SIZE 8192 to #define TIFF_DEFAULT_STRIP_SIZE 0 and rebuilding. If this is the issue, it is a duplicate of bug 691166 http://bugs.ghostscript.com/show_bug.cgi?id=691166 Resolving as INVALID for now until the problem with the T.37 gateway can be identified. If it is not the multi-strip issue described above, please re-open this bug.
-dMaxStripSize=0 did not fix the issue. Here is a tiffdump/tiffinfo of each of the images: gs 8.70 TIFF Directory at offset 0x8 (8) Subfile Type: multi-page document (2 = 0x2) Image Width: 1728 Image Length: 2156 Resolution: 204, 196 pixels/inch Bits/Sample: 1 Compression Scheme: CCITT Group 3 Photometric Interpretation: min-is-white FillOrder: msb-to-lsb Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 2156 Planar Configuration: single image plane Page Number: 0-0 Software: GPL Ghostscript 8.70 DateTime: 2010:03:12 10:23:14 Group 3 Options: EOL padding (4 = 0x4) Magic: 0x4949 <little-endian> Version: 0x2a Directory 0: offset 8 (0x8) next 0 (0) SubFileType (254) LONG (4) 1<2> ImageWidth (256) LONG (4) 1<1728> ImageLength (257) LONG (4) 1<2156> BitsPerSample (258) SHORT (3) 1<1> Compression (259) SHORT (3) 1<3> Photometric (262) SHORT (3) 1<0> FillOrder (266) SHORT (3) 1<1> StripOffsets (273) LONG (4) 1<338> Orientation (274) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<1> RowsPerStrip (278) LONG (4) 1<2156> StripByteCounts (279) LONG (4) 1<38204> XResolution (282) RATIONAL (5) 1<204> YResolution (283) RATIONAL (5) 1<196> PlanarConfig (284) SHORT (3) 1<1> Group3Options (292) LONG (4) 1<4> ResolutionUnit (296) SHORT (3) 1<2> PageNumber (297) SHORT (3) 2<0 0> Software (305) ASCII (2) 21<GPL Ghostscript 8.70\0> DateTime (306) ASCII (2) 20<2010:03:12 10:23:14\0> gs 8.71 (this is with -dMaxStripSize=0) TIFF Directory at offset 0x954a (38218) Subfile Type: multi-page document (2 = 0x2) Image Width: 1728 Image Length: 2156 Resolution: 204, 196 pixels/inch Bits/Sample: 1 Compression Scheme: CCITT Group 3 Photometric Interpretation: min-is-white FillOrder: msb-to-lsb Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 2156 Planar Configuration: single image plane Page Number: 0-0 Software: GPL Ghostscript 8.71 DateTime: 2010:03:12 14:10:32 Group 3 Options: EOL padding (4 = 0x4) Magic: 0x4949 <little-endian> Version: 0x2a Directory 0: offset 38218 (0x954a) next 0 (0) SubFileType (254) LONG (4) 1<2> ImageWidth (256) SHORT (3) 1<1728> ImageLength (257) SHORT (3) 1<2156> BitsPerSample (258) SHORT (3) 1<1> Compression (259) SHORT (3) 1<3> Photometric (262) SHORT (3) 1<0> FillOrder (266) SHORT (3) 1<1> StripOffsets (273) LONG (4) 1<8> Orientation (274) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<1> RowsPerStrip (278) SHORT (3) 1<2156> StripByteCounts (279) LONG (4) 1<38209> XResolution (282) RATIONAL (5) 1<204> YResolution (283) RATIONAL (5) 1<196> PlanarConfig (284) SHORT (3) 1<1> Group3Options (292) LONG (4) 1<4> ResolutionUnit (296) SHORT (3) 1<2> PageNumber (297) SHORT (3) 2<0 0> Software (305) ASCII (2) 21<GPL Ghostscript 8.71\0> DateTime (306) ASCII (2) 20<2010:03:12 14:10:32\0> Differences seem to be the directory offset is later in the file (it's at the end, specifically) with 8.71 rather than directly after the header. The debug information I can get out of our T.37 gateway (Cisco AS5400) is: context(0x64F04374), state=10TIFF Writer: tiff_writer_engine called with a NULL context pointer. I viewed the raw IFD and also noticed that XResolution and YResolution differ between 8.70 and 8.71: With 8.70 XResolution is 0xCC / 0x1, where 8.71 it is 0x19800000 / 0x200000. With 8.70 YResolution is 0xC4 / 0x1, where 8.71 it is 0x18800000 / 0x200000. Hex editing a tiffg3 generated by 8.71 to move the IFD directly after the header, and modifying the X/Y res tags to more reasonable numbers resulted in a file accepted by the gateway. I assume there's no way to control the IFD position, or to force XRes/YRes to be written out as more reasonable rational fields?
I should also add that I now know that the generated file is up to spec and that it's not necessarily an issue with ghostscript/libtiff but rather compatibility with a broken TIFF reader implementation. Unfortunately it looks like Cisco has known about this issue since 2002 so it's unlikely that they will fix it on their end.
Can you please try the two changes separately ? 1) move the IFD 2) change the X/Y res to smaller numbers We can look into libtiff to see if it would be possible to do this. Note that the 8.70 gdevtfax.c can be used (with some makefile adjustments) to revert to the old way of writing the tiff files. I haven't done this to know what all is involved, but it is not like we removed the internal CCITT filters (these are needed anyway for PDF). Pretty frustrating considering Cisco is a great big company with LOTS of paid programmers on staff and they are clearly a deficient TIFF reader. I'll also try some contacts I have at Cisco to see if I can shake something loose.
Created attachment 6060 [details] Patch fixing the writing of TIFF resolution tags Brent, thanks to your investigation, I have found a bug when writing the x and y resolutions. This has not surfaced in any regression tests because these tags seem to be pretty much optional (according to [1]) and are discarded by both tiffinfo and tiffcmp. A patch is attached, maybe it already fixes your problem. [1] http://www.awaresystems.be/imaging/tiff/tifftags/xresolution.html
Additionally, it shouldn't be a problem to write the IFD at the beginning of a page in the file. Brent, if this turns out to be your problem I can do this tonight (european). Ray, or is there a specific reason why we're now writing the ifd after the page data?
I have no idea why the changes to use libtiff resulted in writing the IFD at the end. I had just assumed that this is a default more, allowing writing to a FILE * that does not allow fseek, but I see a comment in base/gdevtifs.c: * Open the output seekable, because libtiff doesn't support writing to * non-positionable streams. If this is easy to change, I have no objection. The old code obviously relied on seekable as well in order to write the IFD at the beginning.
Created attachment 6062 [details] Patch: Write page directories before page data
I have just attached a second patch which changes all TIFF devices to write the page directories before the page data. This is also commited to head as r10927. Brent, I hope this fixes your problem.
I will be able to test the patches tomorrow hopefully. Thank you Lars and Ray, I will let you know how it goes
Brent, did everything work out or are you still experiencing problems with the generated TIFF files?
(In reply to comment #13) > Brent, did everything work out or are you still experiencing problems with the > generated TIFF files? Had to put it on the backburner, but I'll be wrapping up a project this week that will let me put some time back into this. I'll followup before Friday with results.
I have a similiar problem with old GammaFax cards. It's more insidious, though, as the faxes are sent without signalling errors - but with blank pages. I did notice one thing, though: 8.70 output: Tag 282 (011a: X Resolution), RATIONAL × 1, 204/1 (000000cc/00000001) Tag 283 (011b: Y Resolution), RATIONAL × 1, 98/1 (00000062/00000001) 8.71 output: Tag 282 (011a: X Resolution), RATIONAL × 1, 427819008/2097152 (19800000/00200000) Tag 283 (011b: Y Resolution), RATIONAL × 1, 1644167168/16777216 (62000000/01000000) My first assumption was that these insane fractions were a byte order problem affecting Intel implementations, but the X resolution clearly has the right byte order within the word even though the word order is wrong. So I changed the resolutions to more sensible fractions using a hex editor. Still blank pages.
Hi Lars, First let me apologize for the delay in getting to this. I've finally been able to test the two patches. I first applied "Patch fixing the writing of TIFF resolution tags" to 8.71, it did not resolve the issue. I backed out the patch and applied "Patch: Write page directories before page data", and the issue is resolved, so it looks like that was the problem. What's your opinion on this? Will this behavior be applied to the official distribution?
Mats, does applying the attached patches help (especially the second one)? The resolutions are written wrong in 8.71: as ints instead of floats. Brent, I applied both patches to trunk back when I wrote them. So they will be part of the next release.
Assuming this is not reproducible in the current release, if it is please reopen.