LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2004
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
2004.08.25 17:57 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Frank Warmerdam
2004.08.26 09:27 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Joris Van Damme2004.08.26 04:46 "Re: Not-a-bug report, TIFFFdOpen (tif_win32) - TIFFClientOpen", by Ross A Finlayson
Hello,
Please note that for some reason the tif_fd member is used by the
tiff2pdf program. I'd be happy to just use tif_clientdata instead, a fix
of a few lines.
[space:libtiffcvs-b/libtiff/tools] space% grep tif_fd *.c
fax2tiff.c: faxTIFF->tif_fd = fileno(in);
fax2tiff.c: faxTIFF->tif_clientdata = (thandle_t)
faxTIFF->tif_fd;
tiff2pdf.c: close(output->tif_fd);
tiff2pdf.c: output->tif_fd=(int)fileno(stdout);
tiff2pdf.c: CloseHandle((HANDLE) output->tif_fd);
tiff2pdf.c:
output->tif_fd=(int)GetStdHandle(STD_OUTPUT_HANDLE);
tiff2pdf.c: output->tif_clientdata=(thandle_t)output->tif_fd;
It is used in the fax2tiff program for the "smuggling of the file
descriptor" and in the tiff2pdf program for enabling TIFFWriteFile
functions to stdout.
In fax2tiff.c the lines are as so:
...
in = fopen(argv[optind], "r" BINMODE);
if (in == NULL) {
fprintf(stderr,
"%s: %s: Can not open\n", argv[0],
argv[optind]);
continue;
}
faxTIFF->tif_fd = fileno(in);
faxTIFF->tif_clientdata = (thandle_t) faxTIFF->tif_fd;
...
If the tif_fd is never otherwise addressed in the library code then it
should be a simple matter to remove it.
[space:libtiffcvs-b/libtiff/libtiff] space% grep -I tif_fd *.*
tif_acorn.c: tif->tif_fd = fd;
tif_apple.c: tif->tif_fd = fd;
tif_atari.c: tif->tif_fd = fd;
tif_msdos.c: tif->tif_fd = fd;
tif_open.c: return (tif->tif_fd);
tif_unix.c: tif->tif_fd = fd;
tif_vms.c: tif->tif_fd = fd;
tif_win3.c: tif->tif_fd = fd;
tif_win32.c: tif->tif_fd = ifd;
tiffiop.h: int tif_fd; /* open file descriptor */
Those are easy to remove if they have no side effects.
It can be presumed that other software uses the field.
/*
* Return open file's I/O descriptor.
*/
int
TIFFFileno(TIFF* tif)
{
return (tif->tif_fd);
}
What are the benefits of so doing besides the encapsulation of the type?
If the benefits of encapsulating the type, if that is the right notion,
outweigh breaking some existing programs which are easily updated if part
of libtiff, then it would be worth doing. Let us not be too hasty.
casual source code browsing does appear that it's OK to take it out.
I've made some progress on yet another tag viewer. I have a question
about how a DOUBLE type is stored in the file. Of the eight bytes, is it
stored as two 32-bit words in the file's byte order? I'm hoping I can
get a sample of an IPTC/NAA record, that is both Kodak and NAA/NSK or a
RichTIFF file, and also I'd like a sample TIFF/EP and Exif TIFF file, if
you happen to have one of those to test the software please let me
know. Basically I'm at the point where I'm trying to determine how to get
a separate little help window with different help for the field name and
enumerated value. Actually I've figured that out and am procrastinating.
Good luck, have fun, have a nice day, ...
Ross F.