Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail6.b-one.net (Postfix) with ESMTP id 80F228015020E
	for <filtered@awaresystems.be>; Thu, 26 Jul 2012 05:11:20 +0200 (CEST)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-k: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.212.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
	by mx-k.one.com (Postfix) with ESMTP id 26FDF216D7A1
	for <filtered@awaresystems.be>; Thu, 26 Jul 2012 03:11:20 +0000 (UTC)
Received: by vbjk17 with SMTP id k17so1571243vbj.21
        for <filtered@awaresystems.be>; Wed, 25 Jul 2012 20:11:19 -0700 (PDT)
Received: by 10.220.9.10 with SMTP id j10mr20135210vcj.7.1343271939982;
        Wed, 25 Jul 2012 20:05:39 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.58.208.231 with SMTP id mh7csp22184vec;
        Wed, 25 Jul 2012 20:05:39 -0700 (PDT)
Received: by 10.221.12.81 with SMTP id ph17mr20040226vcb.47.1343271938658;
        Wed, 25 Jul 2012 20:05:38 -0700 (PDT)
Received-SPF: temperror (google.com: error in processing during lookup of tiff-bounces@lists.maptools.org: DNS timeout) client-ip=91.198.169.57;
Received: by 10.230.202.193 with POP3 id ff1mf1161732vbb.23;
        Wed, 25 Jul 2012 20:05:36 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.one.com (mx-j.one.com [91.198.169.57])
	by mail6.b-one.net (Postfix) with ESMTP id E46D78015020E
	for <info@awaresystems.be>; Thu, 26 Jul 2012 04:52:51 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-j.one.com (Postfix) with ESMTP id DB8E21CB86A5
	for <info@awaresystems.be>; Thu, 26 Jul 2012 02:52:50 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 12DC91EDB4B;
	Wed, 25 Jul 2012 21:51:16 -0500 (EST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by lists.maptools.org (Postfix) with ESMTP id 79C791EDB03
	for <tiff@lists.maptools.org>; Wed, 25 Jul 2012 21:50:22 -0500 (EST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6Q2oMG8009468
	for <tiff@lists.maptools.org>; Wed, 25 Jul 2012 22:50:22 -0400 (EDT)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tiff@lists.maptools.org
Date: Wed, 25 Jul 2012 22:50:21 -0400
Message-ID: <9467.1343271021@sss.pgh.pa.us>
Subject: [Tiff] Confused about 4.0 API changes: TIFFField vs TIFFFieldInfo
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

I was trying to fix the freeimage source code to work with libtiff 4.0,
and ran into an API compatibility issue that I don't understand the
rationale for, nor how to work around what seems like loss of
functionality.

TIFFFieldWithTag() and related functions used to return
const TIFFFieldInfo*, and you could look into the struct and do
something with the information.  Now they return const TIFFField*,
which so far as I can see is an opaque type for which no operations
are provided in tiffio.h.  So these functions have been lobotomized
into mere boolean probes: you can find out whether the TIFF file
contains such a tag, but you can't learn anything else about it.
What was the intention here?

What the freeimage source code is doing with the TIFFFieldInfo stuff is
determining the tag data type and the number of values, so that it can
figure out how to call TIFFGetField to copy the data, without needing
bespoke code for every possible tag.  I suppose I could replace that
with hard-wired code for each tag they care about, but that surely does
not seem like an improvement.

Can anyone explain to me how to do this with the 4.0 API?  If it's
not possible, isn't that a rather serious functionality regression?

			regards, tom lane
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
