1994.06.23 21:03 "Think C Libtiff ???", by David W. Leland

1994.06.24 18:23 "Re: Think C Libtiff ???", by Dan McCoy

A lot depends on which version of libtiff, and which version of Think/Symantec C. Are you using the new 3.3 ANSI-compliant version of libtiff? Think 5.0? 6.0? Symantec C++ 7.0+? They all have to be tweeked differently.

For the sake of argument, I will assume you are on the bleeding edge and using the latest and greatest of both. If you want lzw compression, a few changes need to be made because of the large static arrays that make it gag.

????
lzw?
static arrays?

We use the libtiff 3.3 tif_lzw.c unchanged, it works with Think 5,6,7,... tif_lzw.c hasn't had any static arrays since libtiff 3.0, even then there were two arrays of nine bytes each. There is a data structure malloc'ed by tif_lzw.c that is about 72k bytes, but Think can handle that just fine.

Also,the fax3 fax4 and g3states stuff wont work at all, so leave out the fax compressions. You can disable these either by editing "tiffconf.h" directly, or by defining COMPRESSION_SUPPORT in the "Prefix" preferences.

I agree here.

We can just leave the fax stuff out because it would be dumb to put the output of a photorealistic renderer into a fax file. Others may not have that option. Personally, it mystifies me why otherwise sane people put up with a toy compiler like Think.

Basically, all you have to do to make independent libraries is to split it up into two projects (so you wont have to worry about 32K limitations). Then in the Think C Preferences, turn on the "ANSI" button, and then activate the "Think C" checkbox, the "4-byte int" checkbox (it might work with two-byte ints, but you can't be too careful).

I believe libtiff 3.3 does work with 16-bit int's, but I also think 16-bit int's are a lame idea.

You can optionally turn on the 68020 box for speed, but if you turn on the 68881 box your code will no longer be PowerPC compatible.

I have heard that you can run the soft 68881 emulator (name escapes me at the moment) on the PowerMac.

(I'm pretty sure that Sam has integrated the lzw changes into his next release of libtiff, so there's nothing in these archives that he would care about).

The fixed version of the LZW code

Again, what's this about lzw changes. We use 3.3 tif_lzw.c unchanged with no problems.

and a little more "maclike" tiffinfo utility project is provided as an example. Good luck!

The mac-tiffinfo sounds like it might be a good addition to the library tools. I'm always having to tell the mac users to move their problem tiff files over to a unix box so I can look at them and tell them what's wrong.

Dan McCoy        Pixar      mccoy@pixar.com