AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.08.25 19:36 "[Tiff] GDAL Unofficial Private TIFF Tags", by Frank Warmerdam
2004.08.25 22:52 "Re: [Tiff] GDAL Unofficial Private TIFF Tags", by Joris
2004.08.25 23:48 "Re: [Tiff] GDAL Unofficial Private TIFF Tags", by Chris Cox
2004.08.26 00:18 "Re: [Tiff] GDAL Unofficial Private TIFF Tags", by Joris
2004.08.26 01:19 "Re: [Tiff] GDAL Unofficial Private TIFF Tags", by Chris Cox
2004.08.28 01:37 "[Tiff] JBIG and JPEG2000", by Joris
2004.08.29 02:34 "[Tiff] tif_fd and error handling", by Joris
2004.08.29 04:48 "Re: [Tiff] tif_fd and error handling", by Bob Friesenhahn
2004.08.29 10:26 "Re: [Tiff] tif_fd and error handling", by Joris
2004.08.29 19:50 "Re: [Tiff] tif_fd and error handling", by Andrey Kiselev
2004.08.29 20:04 "Re: [Tiff] tif_fd and error handling", by Bob Friesenhahn
2004.08.30 17:29 "Re: [Tiff] tif_fd and error handling", by Joris
2004.08.30 18:30 "Re: [Tiff] tif_fd and error handling", by Andrey Kiselev

2004.08.29 19:50 "Re: [Tiff] tif_fd and error handling", by Andrey Kiselev

Hi, Joris,

On Sun, Aug 29, 2004 at 04:34:29AM +0200, Joris wrote:

  1. For various reasons that I cannot elaborate upon, I need my equivalent of tif_win32 to treat TIFF* as opaque. Thus, I had this problem that I signalled with tif_fd while ago (http://www.asmail.be/msg0054799560.html). Frank made a kind comment, Ross investigated, but... how is this going to help me not changing LibTiff?

Well, you can go other way and change the library once and forever: just supply the patch and it will be integrated upstream :-)

Suggestions from you and Ross look reasonable for me, could you set up a Bugzilla entry related to this problem? I shall do the appropriate improvements fro the future library release.

  1. I find the TIFFError and related completely useless. It is feeded no context whatsoever, neither a TIFF*, nor a tif_clientdata, nor a tif_fd. This may be fine in the typical Unix command-line tool that handles a single TIFF or set of TIFFs and knows what the errors are about and simply feeds them to the console and exits. But anything beyond that, from file browser to image editor or whatever, needs an indication of context together with the warning and error messages. I could either revert to Photoshop-style meaningfull messages, like 'The TIFF file cannot be opened because there was an error opening the TIFF file', or I could make my LibTiff modifications all over again and add that context to all TIFFError and TIFFWarning calls... I find neither option acceptable. I cannot understand why any of you is not bitten by this problem that was signalled as early as 1994 (http://www.asmail.be/msg0054815913.html). Is there something I am missing? How do you folks deal with this?

Again, this sounds reasonable. Patches are welcome ;-) Or you can just fill the Bugzilla report, so the problem will be in our TODO list and will not be missed any more.

I think we can implement TIFFErrorExt() function which will take the three parameters: TIFF handler, module name and error message. TIFFError() should remains untouched for backword compatibility.

Andrey

--
Andrey V. Kiselev

Home phone: +7 812 5274898 ICQ# 26871517