Bug 690318 - -dFillOrder does not work for color tiff output devices
Summary: -dFillOrder does not work for color tiff output devices
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 0.00
Hardware: PC Windows 2000
: P4 enhancement
Assignee: Ray Johnston
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2009-03-05 12:41 UTC by Mike
Modified: 2011-09-18 21:47 UTC (History)
0 users

See Also:
Customer: 631
Word Size: ---


Attachments
Patch to add BigEndian option to TIFF devices (25.77 KB, patch)
2009-03-15 14:15 UTC, wendyst2
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2009-03-05 12:41:02 UTC
We have a requirement to produce color TIFF documents with Lsb2Msb fill order.
Unfortunately in GS -dFillOrder work only with B&W tiff output devices.
It would be nice to have this parameter work for all tiff output devices since 
Libtiff fully supports it.
Comment 1 Alex Cherepanov 2009-03-08 09:52:36 UTC
According to TIFF 6 spec:
> FillOrder = 2 should be used only when BitsPerSample = 1 and the data is
> either uncompressed or compressed using CCITT 1D or 2D compression, to
> avoid potentially ambiguous situations.

Currently, Ghostscript produces either monochrome 1 bit/pixel TIFF that
already honors FillOrder or 8 bit/sample TIFF where this flag is not applicable.

Please provide more information about the desired TIFF format or attach a sample
TIFF file with the required properties.

Perhaps, you just need to generate big endian format (aka 'MM') on a little
endian host ?
Comment 2 Mike 2009-03-09 13:16:30 UTC
Alex, you are correct that is what is needed: generating big endian format 
(aka 'MM') on a little endian host. 
Comment 3 wendyst2 2009-03-15 14:15:55 UTC
Created attachment 4844 [details]
Patch to add BigEndian option to TIFF devices

Attached please find a patch to add "BigEndian" option to the TIFF devices. 

Use "-dBigEndian=true" to generate TIFF files with big-endian byte order
("MM"), and "-dBigEndian=false" to generate TIFF files with little-endian byte
order ("II").

When this option is not specified, native byte order will be used.
Comment 4 Ray Johnston 2009-05-01 19:09:01 UTC
I guess there are TIFF readers that may not be able to handle MM vs. II
endian issues, but since we didn't reject this request immediately, I have
committed this patch. Thanks (and bounty) to Wendy.

Since the MM/II order doesn't change the order of most of the raster data this
doesn't really seem like a worthwhile change, but the patch itself demonstrates
the correct method of adding parameters to a device, so it is a good example.

Change committed as rev 9719.
Comment 5 Marcos H. Woehrmann 2011-09-18 21:47:27 UTC
Changing customer bugs that have been resolved more than a year ago to closed.