TIFF and LibTiff Mail List Archive


2005.03.16 10:33 "[Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Andrey Kiselev
2005.03.16 18:18 "Re: [Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Jeff Breidenbach
2005.03.16 18:27 "Re: [Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Frank Warmerdam
2005.03.17 01:00 "Re: [Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Ron
2005.03.17 01:41 "[Tiff] I/O support for FILE *", by Jeff Breidenbach
2005.03.19 17:58 "Re: [Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Thom DeCarlo

2005.03.17 01:00 "Re: [Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Ron

On Wed, Mar 16, 2005 at 01:27:03PM -0500, Frank Warmerdam wrote:

On Wed, 16 Mar 2005 10:18:07 PST, Jeff Breidenbach <> wrote:

I noticed 3.7.2 does not make the Win32 I/O change that would allow one to call:

   TiffFdOpen(fileno(fp), "foo.tif", "r")

Is that in the gameplan for a future release?

Would it help if I make a bugzilla entry?

Not being able to read a TIFF file from a file pointer in Win32 is a real portability drag, and I'm hoping to someday be able to stop patching libtiff for this capability every release.


I believe that Andrey has already made it easy to build libtiff this way by uncommenting the USE_WIN_CRT_LIB macro in the nmake.opt file. This causes tif_unix.c to be built in instead of tif_win32.c.

I personally am not convinced of the value of using the unix code by default on win32. Andrey might feel otherwise.

Sorry if this has been raised before, but would it be better to have TIFFFILEOpen( FILE*, char* ) instead? C stream I/O is portable, and that is an interface well supported by other free codec libs, which makes generalising code that needs to support eg. tiff and jpeg a bit more pleasant. I've done this already in my own code (no mmap support yet though), and can say it's trivial for people to do locally, but is there any reason not to provide it by default here?