AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.02.10 19:32 "LibTIFF working on MS-Windows 3.1.", by Soren Pingel Dalsgaard
1994.02.11 09:39 "Re: LibTIFF working on MS-Windows 3.1.", by Bjorn P. Brox
1994.02.11 01:09 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 14:40 "Re: LibTIFF working on MS-Windows 3.1.", by Jie Yao
1994.02.11 01:16 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 10:17 "Re: LIBTIFFW working on MS-Windows 3.1.", by Niles Ritter
1994.02.14 11:03 "Error/warning handlers in libtiff", by Erik Corry
1994.02.16 22:38 "Re: Error/warning handlers in libtiff", by Sam Leffler
1994.02.11 18:27 "Re: LibTIFF working on MS-Windows 3.1.", by Francois Gauthier
1994.02.11 21:29 "Re: LibTIFF working on MS-Windows 3.1.", by Sam Leffler

1994.02.11 09:39 "Re: LibTIFF working on MS-Windows 3.1.", by Bjorn P. Brox

Good News! (for some, anyway :-)

I have been toying with LibTIFF for a long time, but three days ago I took a serious look at the problems in generating LZW compressed pictures and other possible obstructions. My boss i paying me to do so, and then we though we would let YOU be beta-testers if you would like.

The following changes has been made to the library:

You should check what the library offers you!

The DEFAULT is to use fprintf.

This is a library, not an application.

The application using the library are free to define it's own error and warnings functions without modifying the library!

RTFM TIFFSetWarningHandler() and TIFFSetErrorHandler() in man/man3/TIFFWarning.3t and man/man3/TIFFError.3t

Example below:

#include <stdarg.h>     /* ANSI variant of varargs */
#include <stdlib.h>

...

static void MY_tiffWarningHandler(const char *module, const char *fmt, ...)
{
    char buf[512];

    va_list args;
    va_start(args, fmt);
    vsprintf(buf, (const char *)fmt, args);
    va_end(args);

    DisplayMessage(WarnType, buf);
}

static void MY_tiffErrorHandler(const char *module, const char *fmt, ...)
{
    char buf[512];

    va_list args;
    va_start(args, fmt);
    vsprintf(buf, (const char *)fmt, args);
    va_end(args);

    DisplayMessage(ErrType, buf);
}

main(int argc, char *argv[])
{
    (void)TIFFSetWarningHandler(MY_tiffWarningHandler);
    (void)TIFFSetErrorHandler(MY_tiffErrorHandler);

...

}

Wrong again - this is a library.

The TiffPrintDirectory is used for debug purpose, and you are free to write your own variant - again without modifying the library.

Agree, small fractions looks nicer for the eye that read the dumps, but hould not have any effect. Using rationals is just a way to

Agree that it could be able to write both types. The code is able to write both types, but it insist to write the endian type the hardware reports.

However it does not have any practical use since the standard says that a product should be able to read both formats. If not, they should not be allowed to tell that they support TIFF...

I would however recommend that we add this function to the library:

tiffio.h:
extern  int TIFFSetByteOrder(int);

tif_open.c:
/*
 * Set the default byte order that should be used when writing TIFF files.
 * If magic is different from TIFF_BIGENDIAN or TIFF_LITTLEENDIAN the
 * byte order is not modified.
 */
int TIFFSetByteOrder(int magic)
{
    static int tiff_magic = 1;
    int old_tiff_magic;

    if (tiff_magic == 1) {
        char *cp = (char *)&tiff_magic;
        /*
         * This function is called for the first time, any we detect
         * the default byte order by checking if the 1 is stored in the
         * top-most byte of the int (little-endian) or not.
         */
        tiff_magic = (*cp == 0) ? TIFF_BIGENDIAN : TIFF_LITTLEENDIAN;
    }
    old_tiff_magic = tiff_magic.
    if (magic == TIFF_BIGENDIAN || magic == TIFF_LITTLEENDIAN)
        tiff_magic = magic;

    return(old_tiff_magic);
}

And modify the function TIFFClientOpen():

>         { int one = 1; char* cp = (char*)&one; bigendian = (*cp == 0); }
<         bigendian = TIFFSetByteOrder(0) == TIFF_BIGENDIAN;

I have the sources here, but would like them to be tested out before merging them with the original libtiff library. The last two changes would be nice to have in the original library as well.

BUT: where can I put these files for the public?

As far as I can see the changes necessary for compiling the code on a PC is if great interest (Makefile.win) since the question about compiling it on a PC very often comes up.

--
Bjorn Brox, CORENA A/S, P. O. Box 1024, N-3601 Kongsberg, NORWAY
E-mail: brox@corena.no, Phone: +47 32 73 74 35, Fax: +47 32 73 68 77