Status: Read
Received: from [207.113.13.68] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Thu, 10 Jun 1999 22:38:42 -0400
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id WAA29296;
	Thu, 10 Jun 1999 22:25:22 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 10 Jun 1999 22:24:19 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id WAA29274
	for tiff-outgoing; Thu, 10 Jun 1999 22:24:18 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from mingus.lumisys.com (root@mingus.lumisys.com [204.153.44.5])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id WAA29271
	for <tiff@olympiakos.com>; Thu, 10 Jun 1999 22:24:15 -0400
Received: from porter.lumisys.com (porter.lumisys.com [204.153.47.67])
	by mingus.lumisys.com (8.8.7/8.8.7) with SMTP id SAA03506
	for <tiff@olympiakos.com>; Thu, 10 Jun 1999 18:48:54 -0700
Received: from lumisys.com (sfr-pci-pqr-vty179.as.wcom.net) by porter.lumisys.com (5.x/SMI-SVR4)
	id AA23148; Thu, 10 Jun 1999 18:50:14 -0700
Message-Id: <37606AEE.2CB8A756@lumisys.com>
Date: Thu, 10 Jun 1999 18:48:30 -0700
From: glen <glen@lumisys.com>
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
Mime-Version: 1.0
To: TIFF Mailing List <tiff@olympiakos.com>
Subject: Re: Large File Support
References: <AFF.ANV>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com

Yes and no.  (These comments also apply to your other comment regarding a library
interface.)

Your points are well taken, but they caused me to realize something VERY
fundamental:

    We really have _*_TWO_*_ TIFF specs!

Obviously, there is the core file spec itself, to which your comments apply.  But
even MORE so, there is an "interface standard" (API in effect) also.  Why more
so?  Look at the percentage of emails regarding the basic file format versus
regarding the libtiff interface!

So, yes we of course have to keep the implementation of a new version (or
concept!) of libtiff separate from the file format itself.  But let's not specify
a file format that does not lend itself to a good library implementation or
specify a good library implementation that is inconsistent with a good (smaller,
simpler, more extensive, etc.) file format.

Chris Hanson wrote:

> glen <glen@lumisys.com> wrote:
> > A nice way to handle it would be to add a layer to handle TIFF files like a
> > Microsoft "COM" object.  The idea is that you query the layer as to what
> > interface
> > (e.g., 64-bit vs. 32-bit) the object (i.e., TIFF file) supports.
>
> Please, let's keep the TIFF file format and the implementation of any
> particular library separate.  There are people who don't use libtiff to
> handle TIFF images.

