2000.11.24 04:17 "Re: Using libtiff without reading from a file", by Joris Van Damme

TIFFClientOpen() is not perfect.

By some reason it takes pointers to all file access functions except Open, i.e a function that takes a file spec and returns a handle. I wish somebody fix this bug in LibTiff interface.

Why is that such a bad thing? In fact, what would be the 'file spec' if you want to read from memory? The one and only complete spec that is always suitable is a 32bit 'handle', which you can supply. If you want to work with open files, just open them first. You can assume they need to be opened anyway if LibTiff is to do something on their data, can you not?

TIFFClientOpen() is bad because it is incomplete. It suffices for TIFF data in core but fails for TIFF files embedded in archives, databases, resource forks, EPS files and OLE objects. We cannot assume that Open is trivial in all cases.

I do tend to believe that a 32bit client 'handle' is sufficient to identify just about everything in just about every possible environment. I myself use it to identify a reading wrapper object that can be inherited from to wrap anything that can be read, be it a file, a memory block, linked list of memory block, a segment of a file, or whatever. OK, that means you'll have to code up some reading wrapper logic, but LibTiff is a TIFF library, not an IO library, that part is up to you. And whether this 'Open' is trivial or not, doing it before calling TIFFClientOpen or per LibTiff request is not going to change that, is it?

There are computers with segmented memory or separate address spaces for every process. The memory spec may need the process handle besides the address. Even in the single flat address space one can use ROT13 to convert address to a handle. MS Windows does it all the time to ensure the separation between the client and system code.

Talking about windows... isn't it custom in windows to supply things like eg enumeration functions with a single 32bit cookie? Segmented memory? Was addressed with two 16bit values, making a 32bit address, if I remember correctly. Seperate address spaces for processes? Are you saying your single call to TIFFClientOpen is done simultaniously from within multiple processes or something? Please do explain.

It is possible to open the file outside but it will be closed inside the library. This design obscures the program workflow and requires separate error handling for Open and other LibTiff functionws.

It's up to you to close it whenever you feel like it. If you choose to ignore the LibTiff call to your close routine, and handle 'closing' in the wrapper afterwards, where the stuff was 'opened' in the first place, that's up to you, in my opinion.

Seperate error handling? Is it that hard to use your error handler from withing your opening/closing routines if it is useable per LibTiff request?

BTW, the use of a static variable for the error handler is another interface problem. The error handler function must be another parameter of TIFFClientOpen(). It cannot be set later because the error can happen during the call to TIFFClientOpen().

I agree that does need some work. I have rewritten the error and warning functions to include... the single 32bit client cookie. In my case, that's enough to know what exactly shows errors or warnings (sorry, really). And I simply dumped the static variables and hard-wired my own error handlers. It's easy enough to do that. Just about all calls to the error or warning functions are withing functions that have access to a tiff structure with the client cookie.

The few cases where you might get calls to the error functions without a complete TIFF structure available in the caller is when you run out of memory. But if that ever happens, I guess you're in a total and unrecoverable mess anyway - I can even hardly see windows surviving such a situation - so I chose to just ignore it - though it probably would have been very feasable to handle it properly.

Joris