Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA04436; Fri, 18 Feb 94 19:27:58 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA04428; Fri, 18 Feb 94 11:27:54 -0800
Received: from relay.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA00972; Fri, 18 Feb 94 11:27:50 -0800
Received: from oxford.chez.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA05516; Fri, 18 Feb 94 11:27:31 -0800
Received: by oxford.chez.sgi.com via SMTP (920330.SGI/921111.SGI.AUTO)
	for tiff@sgi.sgi.com id AA29218; Fri, 18 Feb 94 11:31:10 -0800
Message-Id: <9402181931.AA29218@oxford.chez.sgi.com>
To: tiff@sgi.sgi.com
Subject: Re: 'b' and 'l' versus 'M' and 'I' -- libtiff++?  (really what's up with libtiff)
Reply-To: Sam Leffler <sam@asd.sgi.com>
In-Reply-To: Your message of "Tue, 15 Feb 1994 12:28:57 +0800."
             <9402152028.AA00933@christmas.island.COM> 
Date: Fri, 18 Feb 1994 11:31:09 PST
From: Sam Leffler <sam@oxford.chez.sgi.com>
Sender: tiff-owner@sgi.sgi.com

    To:  tiff@sgi.sgi.com
    Subject:  Re: 'b' and 'l' versus 'M' and 'I'  --  libtiff++?
    Date: Tue, 15 Feb 1994 12:28:57 +0800
    From:  giraffe.asd.sgi.com!flake.asd.sgi.com!giraffe.asd.sgi.com!relay.sgi.com!whizzer.wpd.sgi.com!sgi.sgi.com!uunet.UU.NET!christmas!rtm (Richard Minner)

    > It has been pointed out that 'b' is used on some computers to signify binary
    > mode (as opposed to text mode). As a result is has been suggested that 'M' and
    > 'I' are used instead.
    > 
    > But since the mode string isn't actually passed to fopen but parsed by the
    > library it doesn't really matter if 'b' is used in another context. You can
    > ofcourse make your own private modifications and implement 'M' and 'I'
    > checking.
    
    Yes, I noted that it wasn't really all that important, and in retrospect
    I'm sorry I bothered to mention it.  "Never mind."
    
    > I was thinking of adding '#ifdef NO_READ_SUPPORT' and '#ifdef NO_WRITE_SUPPORT'
    > to all modules to make the library smaller in cases where only writing is
    > needed.  Any comments?
    
    I think that would be a nice feature, however I would rather see the
    library designed such that compile-time switches are not needed (at
    all); I don't like building library variants.  For separating
    read/write support this could be done by having different entry points,
    such that you only pull in the support you actually use.  Anyway, Sam
    commented a while back:
    
    	Date: Tue, 19 Oct 1993 08:46:28 PDT
    
    	... Right now the code
    	has reached its "life expectancy" and putting much effort into it is
    	not really worth it.  Any future major effort will almost certainly
    	be done in C++ ...
    
    I gather he is not likely to want to integrate even "simple" changes
    into a new master release.  Making diffs available through this list
    (posting if small else via ftp) may be a reasonable way for multiple
    people to maintain/extend/improve the existing library, but it could
    get messy.  Sam, what's up with you and libtiff?

	<...other stuff deleted...>

I am still working on libtiff.  I was tring to get a new version
together before I left on my sabbatical, but ran out of time.  I will
also work with the IJG to insure that the forthcoming JPEG-in-TIFF spec
is supported by libtiff as soon as possible.  As much as possible,
however, I am trying to avoid radically altering the library in its
present form because I neither have the time nor the interest in
working with the existing code.  My time restrictions also apply to
following the discussions that go on on this mailing list.  There's
been a lot of recent activity that looks to be good, but I haven't had
the time to carefully read most of it or to respond.

Folks may not realize it, but the TIFF software is unrelated to my
"real work" and as such it gets attention when I have spare time and
enough interest to delve into software that's over 6 years old.

	Sam




