1997.01.11 02:04 "Re: libtiff to write EPS preview", by Phillip Crews

Sounds bad in either case, although the header-relative approach seems like the "better" alternative. A minimally hacked libtiff file in "a" mode would probably generate absolute offsets, unfortunately, since it uses seeks to compute the locations of things.

Just out of curiosity, which approach is specified in EPS?

I agree. It's a mangled mess, especially since EPS files are usually vector information (which scales well), and TIFF files are raster, which doesn't. Makes the screen appearance of the EPS quite a bit less than optimal...

In any case, the TIFF file is appended with _relative_ pointers, so using the "a" flag is not going to work. (I say this not from having viewed any specification for EPS, but instead from having written code to handle the EPS TIFF previews.)

The simplest approach for writing the TIFF preview is to generate a completely separate TIFF file, then append it to the end of the EPS file (or at the place where an existing TIFF preview lies). Likewise, the simplest approach to reading the preview would be to extract it to a temporary file, then process that normally.

Not being one to take the easy approach (and always trying to avoid temporary files, which seem particularly ugly to me as they introduce the possibility of more & different error conditions), my TIFF preview reader adjusts _tiffSeekProc to provide a fixed offset when seeking relative to the beginning of the file.

[Well, actually, I didn't do this until recently. When compiling libtiff on Win32, I use file mapping, which means the TIFF data is relative to the position of the fd when the TIFF file is opened -- so the problem magically takes care of itself, as long as you use TiffFdOpen and position the fd correctly. However, now that I'm working on a Macintosh port, I had to write code to make it work with _seek.]

One minor unfortunateness, in my opinion, is that _tiffSeekProc (and the similar routines) provide no means to store any TIFF-specific data; the fd is the arument, rather the the TIFF structure itself, which I would prefer. As it stands, my offset hack is stored as a static variable -- which means my implementation can only have a single TIFF open at a time. I considered implementing an array of seek offsets, indexed by fd; however, since I can't predict the maximum value of 'fd' on all platforms, and since I have no real requirement to open multiple TIFFs simultaneously, I've decided to be lazy until the issue rears its head again. When it does, I'll probably maintain my own table and put a fake fd (index into a table containing real fds and seek offsets) into the TIFF.

If anyone has any interest in this idea, I'll be happy to write the code and share it.

BTW, there are other file formats which specify that TIFF files may be embedded in them, including WordPerfect Graphics and Sun Raster files. I don't know how the offsets are handled in these other formats, as my program doesn't process embedded TIFF files in them (I don't even have any examples). And, other files may be encountered with header information that has to be skipped, such as files with MacBinary headers (which my software does handle).

Kind regards,

Phillip Crews
http://www.cerious.com