libiptcdata-devel Mailing List for IPTC Metadata Library

Dear List,

I have just released libiptcdata version 1.0.3.  The changes consist of
relatively minor bug fixes and improvements contributed over the last
two years:

* Fix for python saving so it does not fail when /tmp is a different
filesystem.  From Chris Mayo.
* Fix python crash on unknown datasets.  From Ian Wienand.
* Clean up iptc_dataset_dump output.  From Roger Hakansson.
* Added German translation by Chris Leick.

Please let me know if you find any issues.

Regards,
David

On Tue, 2009-02-03 at 02:25 +0100, Roger Håkansson wrote:
> Whenever at tag without a known name is found, iptc_dataset_dump will 
> try to pass NULL to printf.
> This is how I solved it (maybe just printing whitespace is enough...)
> 

Hi Roger,

Sorry for the late response, but I have committed a fix to CVS now.  I
will do a new release shortly.

Thanks for the bug report.

-David

Whenever at tag without a known name is found, iptc_dataset_dump will 
try to pass NULL to printf.
This is how I solved it (maybe just printing whitespace is enough...)


*** libiptcdata-1.0.2/libiptcdata/iptc-dataset.c        Mon Aug 29 
04:27:41 2005
--- libiptcdata-1.0.2.new//libiptcdata/iptc-dataset.c   Wed Oct 22 
15:08:28 2008
***************
*** 589,595 ****
                 return;

         printf ("%sTag: %d:%d ('%s')\n", buf, e->record, e->tag,
!               iptc_tag_get_name (e->record, e->tag));
   /*    printf ("%s  Format: %i ('%s')\n", buf, e->format,
                 iptc_format_get_name (e->format)); */
         printf ("%s  Size: %i\n", buf, e->size);
--- 589,595 ----
                 return;

         printf ("%sTag: %d:%d ('%s')\n", buf, e->record, e->tag,
!               iptc_tag_get_name (e->record, e->tag) ? 
iptc_tag_get_name (e->record, e->tag) : "NULL");
   /*    printf ("%s  Format: %i ('%s')\n", buf, e->format,
                 iptc_format_get_name (e->format)); */
         printf ("%s  Size: %i\n", buf, e->size);

On Mon, Dec 8, 2008 at 11:19 PM, David Moore <dc...@mi...> wrote:
> Thanks, committed.

Thanks!

> It's been a while since a release of libiptcdata so I am happy to do
> another.  Do you have some more fixes planned, or shall I do the release
> ASAP?

I don't have anything else planned, unless you know of any other bugs :)

-i

Ian Wienand wrote:
> Hi,
> 
> This is a fix for Debian bug #508128, which is returning a null value
> and causing a segfault.  The wrapper functions correctly return a null
> *string*.
> 

Thanks, committed.

It's been a while since a release of libiptcdata so I am happy to do 
another.  Do you have some more fixes planned, or shall I do the release 
ASAP?

-David

Hi,

This is a fix for Debian bug #508128, which is returning a null value
and causing a segfault.  The wrapper functions correctly return a null
*string*.

-i

Index: ChangeLog
===================================================================
RCS file: /cvsroot/libiptcdata/libiptcdata/ChangeLog,v
retrieving revision 1.53
diff -u -d -u -r1.53 ChangeLog
--- ChangeLog	4 Sep 2007 06:25:08 -0000	1.53
+++ ChangeLog	9 Dec 2008 00:39:07 -0000
@@ -1,3 +1,8 @@
+2008-12-08  Ian Wienand  <ia...@de...>
+
+	* pyhton/pyiptcdataset.c: Don't poke around inside datastructures
+	for title/description info.
+
 2007-09-04  David Moore  <dc...@ac...>
 
 	* python/pyiptcdata.c: Fix for saving when /tmp is on different
Index: python/pyiptcdataset.c
===================================================================
RCS file: /cvsroot/libiptcdata/libiptcdata/python/pyiptcdataset.c,v
retrieving revision 1.2
diff -u -d -u -r1.2 pyiptcdataset.c
--- python/pyiptcdataset.c	28 Jan 2007 22:32:55 -0000	1.2
+++ python/pyiptcdataset.c	9 Dec 2008 00:39:07 -0000
@@ -64,7 +64,7 @@
 get_title(DataSetObject *self, void *closure)
 {
 	check_valid(self, NULL);
-	return Py_BuildValue("s", self->ds->info->title);
+	return Py_BuildValue("s", iptc_tag_get_title(self->ds->record, self->ds->tag));
 }
 
 /* DESCRIPTION */
@@ -72,7 +72,7 @@
 get_description(DataSetObject *self, void *closure)
 {
 	check_valid(self, NULL);
-	return Py_BuildValue("s", self->ds->info->description);
+	return Py_BuildValue("s", iptc_tag_get_description(self->ds->record, self->ds->tag));
 }
 
 /* VALUE */

I've just released version 1.0.2 of libiptcdata.  The changes are:

- Improved compatibility with Picasa.  Older versions of libiptcdata
would produce valid files, but Picasa would not read the captions in
these files.
- Minor Python compile fix from Ian Wienand

Please download it from the website:
http://libiptcdata.sourceforge.net/

Regards,

David

Today, libiptcdata 1.0.1 has been released with some minor bug fixes:

- Fixed build on systems without Python installed (reported by Jens
Granseuer)
- Fixed a possible crash in the Python wrapper code caused by a buffer
overflow.

As usual, it is available at the website:

http://libiptcdata.sourceforge.net/

Enjoy,

David

I am happy to announce version 1.0.0 of libiptcdata, available
immediately:

http://libiptcdata.sourceforge.net/

The one major change in this release is the addition of Python bindings,
which have been kindly provided by Ian Wienand.  Mostly, this release is
just to bump the version number to 1.0.0 since the API has been very
stable over many months.

If anyone has suggestions for what they want to see in Version 2 of
libiptcdata, please feel free to make suggestions.

Regards,

David

Sorry for the slow response.  I have updated this in CVS now.  Thanks
for finding this fix.

-David

On Thu, 2007-03-01 at 01:37 -0800, Michael Dillon wrote:
> I believe the problem is with the stdint.h file that is currently used
> in the Windows build of the library.  I don't think it's compatible
> with newer versions of Visual Studio.  The example below seems to work
> nicely, and the errors no longer occur.
> 
> http://msinttypes.googlecode.com/svn/trunk/stdint.h
> 
> Mike
> 
> ----- Forwarded Message ----
> From: Michael Dillon 
> To: David Moore <dc...@MI...>
> Sent: Sunday, January 28, 2007 9:16:27 PM
> Subject: Re: [Libiptcdata-devel] Problem with Nikon pictures
> 
> Hi David,
> 
> I'm still getting familiar with the code, and I haven't had to dive
> this deep into JPEGs in quite a while, so please bear with me! 
> 
> I compared things in CVS, and the critical code appear to be
> identical.  So, I'm just going to use the packaged download that's on
> SourceForge.
> 
> When using the D200 sample image, I make a call to
> iptc_jpeg_save_with_ps3().  In that routine, the call to
> iptc_jpeg_seek_to_ps3() is returning -1.
> 
> When I dig deeper into iptc_jpeg_seek_to_ps3(), the first call to
> iptc_get_short() returns a fairly large negative number (-26980).
> This eventually makes 'i' a negative number. The while() loop tries a
> couple more times, and returns -1 when buf[i] != JPEG_MARKER.
> 
> Tracing down to the bottom into iptc_get_sshort(), the IptcByteOrder
> is passed in as IPTC_BYTE_ORDER_MOTOROLA, and the buffer that is
> passed in contains:
> 
> 0x96,0x9c,E,x,i,f (and so on)
> 
> So, 
> 
> ((buf[0] << 8) | buf[1])
> 
> is returned to iptc_get_short() and then applied with a bitwise '&'
> against 0xffff to get the negative which seems to throw things off...
> 
> Any ideas?
> 
> Mike
> 
> ----- Original Message ----
> From: David Moore <dc...@MI...>
> To: Michael Dillon 
> Cc: lib...@li...
> Sent: Sunday, January 28, 2007 3:45:06 PM
> Subject: Re: [Libiptcdata-devel] Problem with Nikon pictures
> 
> I just tried modifying your Nikon_D200.jpg on my Linux machine, and it
> worked fine.  I'm using the latest CVS version of libiptcdata, so
> could
> you give that a try also?
> 
> If that still doesn't work, this is probably a Windows-only bug.  If
> you're willing, I'd really appreciate it if you could track it down in
> the code since I don't have access to a Windows machine.
> 
> Thanks,
> 
> David
> 
> On Sun, 2007-01-28 at 14:29 -0800, Michael Dillon wrote:
> > Hello,
> > 
> > I'm encountering a problem with writing IPTC to pictures from Nikon
> > cameras.  
> > 
> > The details:
> > 
> > I'm using the windows port of version 0.2.1.
> > If I attempt operations on any Nikon images (from D200, D80, or 970
> > models) I'm unable to write any data.
> > If I use the iptctool on the images to read them, it crashes.
> > In the debugger, iptc_jpeg_read_ps3() returns a massive value,
> almost
> > the size of the entire image.
> > When I call iptc_jpeg_save_with_ps3(), it always returns -1.
> > If I use Irfanview to save some IPTC data, then the library works
> fine
> > on the picture.
> > My code seems to work fine for other images, but not Nikon...
> > 
> > Some sample images can be found here:
> > 
> > http://www.fileshack.us/v/4494380/Nikon_D200.jpg.html
> > http://www.fileshack.us/v/1295234/Nikon_D70.JPG.html
> > http://www.fileshack.us/v/1763376/Nikon_D80.JPG.html
> > 
> > Does anyone have a suggested fix or workaround for this?   I haven't
> > started to dig into the library code yet...
> > 
> > Mike
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Libiptcdata-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel

I believe the problem is with the stdint.h file that is currently used in t=
he Windows build of the library.  I don't think it's compatible with newer =
versions of Visual Studio.  The example below seems to work nicely, and the=
 errors no longer occur.=0A=0Ahttp://msinttypes.googlecode.com/svn/trunk/st=
dint.h=0A=0AMike=0A=0A----- Forwarded Message ----=0AFrom: Michael Dillon =
=0ATo: David Moore <dc...@MI...>=0ASent: Sunday, January 28, 2007 9:16:27 P=
M=0ASubject: Re: [Libiptcdata-devel] Problem with Nikon pictures=0A=0AHi Da=
vid,=0A=0AI'm still getting familiar with the code, and I haven't had to di=
ve this deep into JPEGs in quite a while, so please bear with me! =0A=0AI c=
ompared things in CVS, and the critical code appear to be identical.  So, I=
'm just going to use the packaged download that's on=0A SourceForge.=0A=0AW=
hen using the D200 sample image, I make a call to iptc_jpeg_save_with_ps3()=
.  In that routine, the call to iptc_jpeg_seek_to_ps3() is returning -1.=0A=
=0AWhen I dig deeper into iptc_jpeg_seek_to_ps3(), the first call to iptc_g=
et_short() returns a fairly large negative number (-26980).  This eventuall=
y makes 'i' a negative number. The while() loop tries a couple more times, =
and returns -1 when buf[i] !=3D JPEG_MARKER.=0A=0ATracing down to=0A the bo=
ttom into iptc_get_sshort(), the IptcByteOrder is passed in as IPTC_BYTE_OR=
DER_MOTOROLA, and the buffer that is passed in contains:=0A=0A0x96,0x9c,E,x=
,i,f (and so on)=0A=0ASo, =0A=0A((buf[0] << 8) | buf[1])=0A=0Ais returned t=
o iptc_get_short() and then applied with a bitwise '&' against 0xffff to ge=
t the negative which seems to throw things off...=0A=0AAny ideas?=0A=0AMike=
=0A=0A----- Original Message ----=0AFrom: David Moore <dc...@MI...>=0ATo: M=
ichael Dillon =0ACc: lib...@li...=0ASent: Sunday=
, January 28, 2007 3:45:06 PM=0ASubject: Re: [Libiptcdata-devel] Problem wi=
th Nikon pictures=0A=0AI just tried modifying your Nikon_D200.jpg on my Lin=
ux machine, and it=0Aworked fine.  I'm using the latest CVS version of libi=
ptcdata, so could=0Ayou give that a try also?=0A=0AIf that=0A still doesn't=
 work, this is probably a Windows-only bug.  If=0Ayou're willing, I'd reall=
y appreciate it if you could track it down in=0Athe code since I don't have=
 access to a Windows machine.=0A=0AThanks,=0A=0ADavid=0A=0AOn Sun, 2007-01-=
28 at 14:29 -0800, Michael Dillon wrote:=0A> Hello,=0A> =0A> I'm encounteri=
ng a problem with writing IPTC to pictures from Nikon=0A> cameras.  =0A> =
=0A> The details:=0A> =0A> I'm using the windows port of version 0.2.1.=0A>=
 If I attempt operations on any Nikon images (from D200, D80, or 970=0A> mo=
dels) I'm unable to write any data.=0A> If I use the iptctool on the images=
 to read them, it crashes.=0A> In the debugger, iptc_jpeg_read_ps3() return=
s a massive value, almost=0A> the size of the entire image.=0A> When I call=
 iptc_jpeg_save_with_ps3(), it always returns -1.=0A> If I use Irfanview to=
 save some IPTC data, then the library works fine=0A> on=0A the picture.=0A=
> My code seems to work fine for other images, but not Nikon...=0A> =0A> So=
me sample images can be found here:=0A> =0A> http://www.fileshack.us/v/4494=
380/Nikon_D200.jpg.html=0A> http://www.fileshack.us/v/1295234/Nikon_D70.JPG=
.html=0A> http://www.fileshack.us/v/1763376/Nikon_D80.JPG.html=0A> =0A> Doe=
s anyone have a suggested fix or workaround for this?   I haven't=0A> start=
ed to dig into the library code yet...=0A> =0A> Mike=0A=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A

=0A----- Forwarded Message ----=0AFrom: Michael Dillon <michael_d_dillon@ya=
hoo.com>=0ATo: David Moore <dc...@MI...>=0ASent: Sunday, January 28, 2007 9=
:16:27 PM=0ASubject: Re: [Libiptcdata-devel] Problem with Nikon pictures=0A=
=0AHi David,=0A=0AI'm still getting familiar with the code, and I haven't h=
ad to dive this deep into JPEGs in quite a while, so please bear with me! =
=0A=0AI compared things in CVS, and the critical code appear to be identica=
l.  So, I'm just going to use the packaged download that's on SourceForge.=
=0A=0AWhen using the D200 sample image, I make a call to iptc_jpeg_save_wit=
h_ps3().  In that routine, the call to iptc_jpeg_seek_to_ps3() is returning=
 -1.=0A=0AWhen I dig deeper into iptc_jpeg_seek_to_ps3(), the first call to=
 iptc_get_short() returns a fairly large negative number (-26980).  This ev=
entually makes 'i' a negative number. The while() loop tries a couple more =
times, and returns -1 when buf[i] !=3D JPEG_MARKER.=0A=0ATracing down to=0A=
 the bottom into iptc_get_sshort(), the IptcByteOrder is passed in as IPTC_=
BYTE_ORDER_MOTOROLA, and the buffer that is passed in contains:=0A=0A0x96,0=
x9c,E,x,i,f (and so on)=0A=0ASo, =0A=0A((buf[0] << 8) | buf[1])=0A=0Ais ret=
urned to iptc_get_short() and then applied with a bitwise '&' against 0xfff=
f to get the negative which seems to throw things off...=0A=0AAny ideas?=0A=
=0AMike=0A=0A----- Original Message ----=0AFrom: David Moore <dc...@MI...>=
=0ATo: Michael Dillon <mic...@ya...>=0ACc: libiptcdata-devel@=
lists.sourceforge.net=0ASent: Sunday, January 28, 2007 3:45:06 PM=0ASubject=
: Re: [Libiptcdata-devel] Problem with Nikon pictures=0A=0AI just tried mod=
ifying your Nikon_D200.jpg on my Linux machine, and it=0Aworked fine.  I'm =
using the latest CVS version of libiptcdata, so could=0Ayou give that a try=
 also?=0A=0AIf that=0A still doesn't work, this is probably a Windows-only =
bug.  If=0Ayou're willing, I'd really appreciate it if you could track it d=
own in=0Athe code since I don't have access to a Windows machine.=0A=0AThan=
ks,=0A=0ADavid=0A=0AOn Sun, 2007-01-28 at 14:29 -0800, Michael Dillon wrote=
:=0A> Hello,=0A> =0A> I'm encountering a problem with writing IPTC to pictu=
res from Nikon=0A> cameras.  =0A> =0A> The details:=0A> =0A> I'm using the =
windows port of version 0.2.1.=0A> If I attempt operations on any Nikon ima=
ges (from D200, D80, or 970=0A> models) I'm unable to write any data.=0A> I=
f I use the iptctool on the images to read them, it crashes.=0A> In the deb=
ugger, iptc_jpeg_read_ps3() returns a massive value, almost=0A> the size of=
 the entire image.=0A> When I call iptc_jpeg_save_with_ps3(), it always ret=
urns -1.=0A> If I use Irfanview to save some IPTC data, then the library wo=
rks fine=0A> on=0A the picture.=0A> My code seems to work fine for other im=
ages, but not Nikon...=0A> =0A> Some sample images can be found here:=0A> =
=0A> http://www.fileshack.us/v/4494380/Nikon_D200.jpg.html=0A> http://www.f=
ileshack.us/v/1295234/Nikon_D70.JPG.html=0A> http://www.fileshack.us/v/1763=
376/Nikon_D80.JPG.html=0A> =0A> Does anyone have a suggested fix or workaro=
und for this?   I haven't=0A> started to dig into the library code yet...=
=0A> =0A> Mike=0A> =0A> =0A> ----------------------------------------------=
---------------------------=0A> Take Surveys. Earn Cash. Influence the Futu=
re of IT=0A> Join SourceForge.net's Techsay panel and you'll get the chance=
 to=0A share your=0A> opinions on IT & business topics through brief survey=
s - and earn cash=0A> http://www.techsay.com/default.php?page=3Djoin.php&p=
=3Dsourceforge&CID=3DDEVDEV=0A> ___________________________________________=
____ Libiptcdata-devel mailing list Lib...@li...=
 https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A

I just tried modifying your Nikon_D200.jpg on my Linux machine, and it
worked fine.  I'm using the latest CVS version of libiptcdata, so could
you give that a try also?

If that still doesn't work, this is probably a Windows-only bug.  If
you're willing, I'd really appreciate it if you could track it down in
the code since I don't have access to a Windows machine.

Thanks,

David

On Sun, 2007-01-28 at 14:29 -0800, Michael Dillon wrote:
> Hello,
> 
> I'm encountering a problem with writing IPTC to pictures from Nikon
> cameras.  
> 
> The details:
> 
> I'm using the windows port of version 0.2.1.
> If I attempt operations on any Nikon images (from D200, D80, or 970
> models) I'm unable to write any data.
> If I use the iptctool on the images to read them, it crashes.
> In the debugger, iptc_jpeg_read_ps3() returns a massive value, almost
> the size of the entire image.
> When I call iptc_jpeg_save_with_ps3(), it always returns -1.
> If I use Irfanview to save some IPTC data, then the library works fine
> on the picture.
> My code seems to work fine for other images, but not Nikon...
> 
> Some sample images can be found here:
> 
> http://www.fileshack.us/v/4494380/Nikon_D200.jpg.html
> http://www.fileshack.us/v/1295234/Nikon_D70.JPG.html
> http://www.fileshack.us/v/1763376/Nikon_D80.JPG.html
> 
> Does anyone have a suggested fix or workaround for this?   I haven't
> started to dig into the library code yet...
> 
> Mike
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ Libiptcdata-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel

Hello,=0A=0AI'm encountering a problem with writing IPTC to pictures from N=
ikon cameras.  =0A=0AThe details:=0A=0AI'm using the windows port of versio=
n 0.2.1.=0AIf I attempt operations on any Nikon images (from D200, D80, or =
970 models) I'm unable to write any data.=0AIf I use the iptctool on the im=
ages to read them, it crashes.=0AIn the debugger, iptc_jpeg_read_ps3() retu=
rns a massive value, almost the size of the entire image.=0AWhen I call ipt=
c_jpeg_save_with_ps3(), it always returns -1.=0AIf I use Irfanview to save =
some IPTC data, then the library works fine on the picture.=0AMy code seems=
 to work fine for other images, but not Nikon...=0A=0ASome sample images ca=
n be found here:=0A=0Ahttp://www.fileshack.us/v/4494380/Nikon_D200.jpg.html=
=0Ahttp://www.fileshack.us/v/1295234/Nikon_D70.JPG.html=0Ahttp://www.filesh=
ack.us/v/1763376/Nikon_D80.JPG.html=0A=0ADoes anyone have a suggested fix o=
r workaround for this?   I haven't started to dig into the library code yet=
...=0A=0AMike=0A=0A

libiptcdata 0.2.1 has just been released.  The changes are as follows:

library:
* Added function iptc_data_set_version() to make it easy to set the version
number of the IPTC IIM spec being used.
* Added new convenience functions iptc_data_add_dataset_with_value() and
iptc_data_add_dataset_with_contents().

iptc utility:
* New capability to modify/delete/print specific datasets when more than one
of the same type exists, by appending the number to the end of the tag name.
For example, "Keywords:1" or "2:25:1" refer to keyword tag number 1 (the 2nd
keyword tag).
* New capability to modify/delete/print all datasets of a specific type when
more than one exists.  For example, "Keywords:all" or "2:25:all" will
execute the operation on all keyword tags.
* Dataset numbers (for duplicates) are now printed when the IPTC contents
are displayed to the user.
* Changed the semantics of the program's return value:  Success whenever at
least one operation succeeds and failure if no operation succeeds.
* Whenever a file is saved, datasets are now sorted by default unless the
--no-sort option is specified.
* Mac OS X compile fixes.


The latest version of libiptcdata can be downloaded from the webpage at:
http://libiptcdata.sourceforge.net


Regards,

David

Right now, the expected behavior when there is more than one tag of the
same type is that iptc will operate on the first one.  Note that this is
a limitation of only the command-line utility and not the full
libiptcdata library.

Naturally, this is less than ideal -- I was mostly waiting for someone
to notice the omission before implementing it.  And you just noticed!

So now the question is, what is the ideal interface to make iptc work
with multiple tags of the same type?  One possibility with the '-p'
option is to just print all matching tags.  However, I don't like this
solution because it makes it difficult to write shell scripts that run
unattended.  Such a script might think that all the printed data is
actually part of just one tag, when it really came from several.

Here's my proposed solution:

- Expand the syntax of the tag identifier.  Thus, instead of saying '-p
Keywords', you would say '-p Keywords:2' to print the 2nd keyword.  If
you omitted the ':2', it would just print the first (the current
behavior).
- You could also specify a wildcard, as in '-p Keywords:*' to indicate
that the command should be repeated for all tags of that type.  So with
the '-p' command, every tag of that name would be printed; with the '-d'
command, every tag of that name would be deleted; and with the '-m'
command, every tag of that name would be modified.

Does this sound acceptable?  If so, I'll implement it.

-David

On Wed, 2005-09-14 at 23:00 +0200, S=E9bastien Maerten wrote:
> Good evening,
>=20
> Maybe I'm missing something, but what is the expected behavior of the =20
> iptc tool, in case of multiple "identical" tags ?
> It seems to me that iptc should return a list of tags whose "name" =20
> are the same, in case they are several, but this seems not to be the =20
> case here :( (using your latest unreleased version).
> If my thoughts sounds good to you, I'd be more than happy to have a =20
> way to fix this, since I need to get the value of multiple "Keywords" =20
> tags RSN.
>=20
> Thank you for you patience.=20

Le 14 sept. 05 =E0 23:42, David Moore a =E9crit :

> Yes, that would be fine with me.  It's basically analogous to
> distributing binary packages ala Red Hat, etc.
>
> If you do make any changes to the sources before generating that =20
> binary,
> you'd have to provide the changes, but it sounds like you're not doing
> that.

Thank you for your clear answer.
You can be sure that if I was able to make changes that would make =20
sense, you would be the first to be "in the know", but, as you said, =20
this is not likely to occur.=20=

Yes, that would be fine with me.  It's basically analogous to
distributing binary packages ala Red Hat, etc.

If you do make any changes to the sources before generating that binary,
you'd have to provide the changes, but it sounds like you're not doing
that.

-David

On Wed, 2005-09-14 at 23:09 +0200, S=C3=A9bastien Maerten wrote:
> Another bothering question from the little frenchy ;)
>=20
> Having relatively few knowledge of licenses and juridical matters, =20
> I'd like to ask if it is possible to legaly "give" the iptc in binary =20
> form only, giving pointers to the sf project for the source.
>=20
> The reason I'm asking this is because I'm looking for feedback on a =20
> script I'm develloping and this script uses the iptc cli tool.
> I seem to loose many valuable testers because of their fear of =20
> building libiptcdata (Mac OS X users may be really far from command =20
> line tools and terminals).
>=20
> In case you wonder, there's no matter of money or closed source here, =20
> just a matter of simplifying life to "end users".
>=20
> Any opinion would be greatly appreciated.=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Dow=
nload
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Libiptcdata-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel

Another bothering question from the little frenchy ;)

Having relatively few knowledge of licenses and juridical matters,  
I'd like to ask if it is possible to legaly "give" the iptc in binary  
form only, giving pointers to the sf project for the source.

The reason I'm asking this is because I'm looking for feedback on a  
script I'm develloping and this script uses the iptc cli tool.
I seem to loose many valuable testers because of their fear of  
building libiptcdata (Mac OS X users may be really far from command  
line tools and terminals).

In case you wonder, there's no matter of money or closed source here,  
just a matter of simplifying life to "end users".

Any opinion would be greatly appreciated. 

Good evening,

Maybe I'm missing something, but what is the expected behavior of the  
iptc tool, in case of multiple "identical" tags ?
It seems to me that iptc should return a list of tags whose "name"  
are the same, in case they are several, but this seems not to be the  
case here :( (using your latest unreleased version).
If my thoughts sounds good to you, I'd be more than happy to have a  
way to fix this, since I need to get the value of multiple "Keywords"  
tags RSN.

Thank you for you patience. 

Le 8 sept. 05 =E0 02:33, David Moore a =E9crit :

> libiptcdata 0.2.0 has just been released.  The changes are as follows:
>
> * Mac OS X compile fixes.

Well thank you for having considered my remarks. However, it seems =20
that 0.2.0 does not build on my system (quasi stock Mac OS X 10.4.2) =20
at all :(

Attached are the output of a plain ./configure followed from make.

Hope this helps. Just ask if you need more information.

libiptcdata 0.2.0 has just been released.  The changes are as follows:

library:
* Improved internationalization support, including helper functions
iptc_data_get_encoding() and iptc_data_set_encoding().
* Added iptc_data_sort() and iptc_dataset_copy() functions.
* Mac OS X compile fixes.
* Fixed compile warnings with gcc 4.0.

iptc utility:
* Improved internationalization support.
* --modify command will create dataset if not already present.
* Allows running on multiple files at once.
* Added -l (list tags), -L (tag information), and -s (sort datasets)
options
* Improved handling of data sets containing more than 256 bytes

The latest version of libiptcdata can be downloaded from the webpage at:
http://libiptcdata.sourceforge.net

If you have a favorite feature that didn't make it into this release,
please email me and let me know so I can keep track of what's important
to people.  Also feel free to email me any comments, suggestions, or
bugs with this release.

In other news:  gthumb (http://gthumb.sf.net) has become the first major
application to use libiptcdata natively.  Support is currently in
gthumb's CVS version, and will be available with its next release.

Regards,

David

On 2005-08-01 15:51:49 +0200 Hubert Figuiere <hfi...@te...> 
wrote:

> Try configure with --disable-nls
> That's disable gettext.

Yes, thank you for the suggestion.

> Or install one the unix free software distributions like DarwinPorts 
> or Fink.
No, thank you, I'd really like to avoid that.

After a few tests, here are my conclusions :
Whatever the ./configure options are, iptc my-file-without-iptc.jpg 
produces the right ouput. But for a file with iptc data, I may get the 
crash previously reported.

--disable-nls and --enable-static --disable-shared lead to "good" 
executables
--with-included-gettext or nothing lead to "bad" executables.

I hope this may be usefull for you, I fear I can't investigate deeper 
by myself :( Just ask if you want something from me (config.log ?). 
However, maybe it could be a good idea to drop a note in the INSTALL 
file regarding this issue.

S=E9bastien Maerten wrote:
> On 2005-08-01 07:12:39 +0200 David Moore <dc...@MI...> wrote:
>=20
>> I have no experience with libiptcdata on Mac OS X, but this looks like=
 a
>> library incompatibility.  Perhaps Mac OS X ships with an older version
>> of gettext than is on my system.
>=20
>=20
> After thinking for a while I was suspecting gettext, nice to hear that=20
> you do so.


Try configure with --disable-nls
That's disable gettext.

Or install one the unix free software distributions like DarwinPorts or=20
Fink.


Hub

On 2005-08-01 07:12:39 +0200 David Moore <dc...@MI...> wrote:

> I have no experience with libiptcdata on Mac OS X, but this looks 
> like a
> library incompatibility.  Perhaps Mac OS X ships with an older version
> of gettext than is on my system.

After thinking for a while I was suspecting gettext, nice to hear that 
you do so. Well, I tried to look for my current gettext... I've 
searched my system for a few of what seems to be gettext installed 
libs or utils (from the page 
http://www.linuxfromscratch.org/lfs/view/development/chapter06/gettext.html#contents-gettext 
). Here is the result :
$ sudo find / -name libgettextlib* -type f -print

Nothing ! I'll have a look at this : is gettext installed ? This looks 
surprising to me.

> First of all, try running ./configure with the --with-included-gettext
> option.  Then 'make' and 'make install' again.  If that still fails, 
> you
> might try getting a newer version of gettext for your system.

I Will do. The offending iptc was build using a plain ./configure. 
Since then, I've tried a ./configure --enable-static --disable-shared 
and the resulting iptc worked as expected (BTW, no problem of utf-8 
encoding).

I will investigate this and keep you informed. If I can't give you 
more information in the next days, maybe dropping a note in the 
INSTALL file could help others ?