LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 1994
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
1994.06.24 18:23 "Re: Think C Libtiff ???", by Dan Mccoy
"David W. Leland" <dleland@maroon.tc.umn.edu> writes: >Would anyone out there happen to have already created a Think C version of >Libtiff for the Mac? > >Well,I'm sure it's been done, so what I'm really asking is if if anyone reading >this would be willing to let me get my greedy little hands on it, so I can be >lazy. ndr@tazboy.JPL.NASA.GOV (Niles Ritter) writes: >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