1994.02.11 10:17 "Re: LIBTIFFW working on MS-Windows 3.1.", by Niles Ritter
Soren Dalsgaard writes,
The following changes has been made to the library:
- Errors and Warnings are reported in MessageBoxes - not via fprintf.
- TiffPrintDirectory is not available (right now) because it uses fprintf.
As others have mentioned, there are of course ways to override the default action. The real point, though, is that you would like to formulate the new way of performing an interface-action in such a way that it can be gracefully integrated with the libtiff proper. The reason isn't just for other host's sake; if your code remains compatible with the public libtiff, then when improvements/new compression schemes (such as the long-awaited JPEG-in-TIFF) become part of libtiff you will not have to deal with so much grief.
- Rationals were written as obnoxiously large fractions. They are not reduced before being written to file.
Actually, they only look large to humans; to the computer they're *all* pairs of 4-byte integers :-) Seriously, for some applications the issue of keeping high precision is important. The current implementation in libtiff is good, but in general gives an accuracy of order (N), where N is the size of the denominator. Mathematicians have known for some time that you can do much better, and there is a theorem that by representing the desired real number as a continued fraction expansion (ie, a+1/(b+1/(c+...))), where a,b,c, are integers) you can find a fraction differing by order (N**2). (recursive code left as an exercise). The nice part is that the continued fraction will automatically be in reduced form, so you don't have to look for common factors.
- Ability to write both II and MM type tiff images. Yes that's right you can write little and big endian images using the library.
This is one sure way to invite new flames about the TIFF spec's. A program which can only read a certain byte-order TIFF cannot claim to be a TIFF compliant program (and reveals a certain "endian-centric" orientation on the part of that programmer). This feature probably won't make it into the libtiff, although I don't speak for Sam Leffler.
I am of course assuming here that the reason one would want to be able to write foreign was to accomodate brain-damaged TIFF readers. The only other time I can imagine that this would be a desirable feature is if you were writing a HUGE TIFF image (say, 600Megs or so) which was going to go onto a archive run on a foreign-byte-order machine, in which case you'd like to avoid the byte-swapping overhead. But even then, if this was a networked environment some of the client machines may not be in the same byte-order, so we're back to square one.
BUT: where can I put these files for the public?
You should e-mail the changes (preferable in "diff" format) to Sam Leffler, rather than posting the changes to the group. Sam's been on sabbatical (I didn't know SGI was a university :-), but should be around soon.
His last posting on this list was on 17 Nov, and read as follows:
From firstname.lastname@example.org Wed Nov 17 07:46:55 1993
Date: Wed, 17 Nov 93 01:21:33 -0800
From: email@example.com (Sam Leffler)
Subject: I am away
I am away on sabbatical until February. If your mail is about:
flexfax send it to the flexfax mailing list (firstname.lastname@example.org)
tiff send it to the tiff mailing list (email@example.com)
mailing list send mail to firstname.lastname@example.org
Otherwise, I'll read your mail when I return.