2005.03.16 10:33 "[Tiff] [ANNOUNCE]: Libtiff 3.7.2 released", by Andrey Kiselev

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

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?