LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 1994
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1994.02.11 21:29 "Re: LibTIFF working on MS-Windows 3.1.", by Sam Leffler
To: tiff@sgi.sgi.com
Subject: Re: LibTIFF working on MS-Windows 3.1.
Date: Fri, 11 Feb 1994 13:27:54 EST
From: Francois Gauthier <fgauth@M3iSystems.QC.CA>
> From tiff-owner@whizzer.wpd.sgi.com Thu Feb 10 14:09:56 1994
> From: S|ren Pingel Dalsgaard <pingel@daimi.aau.dk>
> Subject: LibTIFF working on MS-Windows 3.1.
> To: tiff@ucbvax.Berkeley.EDU (Tiff mailing list)
> Date: Thu, 10 Feb 94 19:32:29 GMT
> X-Mailer: ELM [version 2.3 PL11]
> Sender: tiff-owner@sgi.com
> Content-Length: 1922
>
> Good News! (for some, anyway :-)
>
> I have been toying with LibTIFF for a long time,
... Part of message deleted...
>
> o Ability to write both II and MM type tiff images. Yes that's right you can
> write little and big endian images using the library.
I think this feature may prove useful when an application seeks to
append images to an existing TIFF file on a machine that has different
byte ordering than the original. This is not normally possible
since the byte ordering is file wide.
Providing this feature in libtiff would in my view increase it's
machine independence. It could make the append mode of TIFFOpen()
more robust.
<...unrelated stuff deleted...>
This is the only reason that I'd be willing to do byte-swapping when
writing a file. As was mentioned previously, the TIFF spec has
required readers to be able to handle both byte orders for MANY YEARS.
As best as I can determine the majority of the implementations that do
not support both big- and little-endian byte orders are on PC's. A
good version of my library for these machines would undoubtedly go a
long way toward eliminating this problem; much in the way that the free
availability of the software has helped insure interoperability on
other platforms.
The bottom line is that I am adamantly opposed to adding support to the
library that encourages the continued use of bogus TIFF
implementations. My preferred solution is to have available software
that can be freely incorporated into products so that these
incompatibilities can be avoided.
BTW, support for byte-swapped TIFF is *extremely* simple.
Sam