libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] Question about JPG file access and Exif Header access

[Benny S. <ich...@pa...>]

I am trying to use libexif for the first time.

I am working in an embedded environment and I want to read from and write to
Exif headers in JPG files stored on a compact flash card.

I have not done any of this before.

I have looked at the test programs (test-mem.c , test-value.c, etc.)
included with the libexif package.

I do not see any file access commands in these programs, wherein a JPG file
is opened or closed.

Also, I am trying to understand how libexif will know about and be able to
write to/read from the memory on my microcontroller module ((I have 128K of
RAM available).

I would appreciate any help you can give me.

Benny Smith
Santa Rosa, CA

[Libexif-devel] New Vietnamese PO file for 'libexif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/vi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Vietnamese PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/exif/vi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [Libexif-devel] Using libexif: Question about exif-data.h

[Marcus M. <ma...@je...>]

> #ifdef __cplusplus
> extern "C" {
> #endif /* __cplusplus */
> 
> If __cpluplus is defined, then extern "C" is declared, { is opened, and then
> there is an #endif.  What do these three statements accomplish?
> 
> 
> Near the bottom of the file, another #ifdef __cplusplus statement appears,
> then the } is closed, and another #endif /* __cplusplus */ statement
> appears.
> 
> I do not understand the function of the second #ifdef __cplusplus statement
> just before the }. 
> 
> What is the purpose of the declaration (made somewhere else in the library)
> of __cplusplus?  Where (in what file) is that declaration made?
> 
> All of the other statements in the file exif-data.h are contained between {
> and  } , therefore, apparently controlled by the #ifdef __cplusplus
> statement at the beginning.  Why?

libexif imports functions as "C" functions.

For using libexif in a C++ program you of course need the prototypes, but
the prototypes need to be marked as "C" functions, otherwise they are imported
using C++ mangling of function names.

The extern "C" { ... }; wrapper around the prototypes accomplishes exact that.
The prototypes are visible to C++ code, but as C imports.

Ciao, Marcus

[Libexif-devel] Using libexif: Question about exif-data.h

[Benny S. <ich...@pa...>]

In the file exif-data.h, I am confused by some statements.

The file starts with:

*******************************************************

#ifndef __EXIF_DATA_H__
#define __EXIF_DATA_H__

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

..... many other statements......

#ifdef __cplusplus
}
#endif /* __cplusplus */

#endif /* __EXIF_DATA_H__ */

*******************************************************

I understand the statements containing __EXIF_DATA_H__.

Regarding the statements:

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

If __cpluplus is defined, then extern "C" is declared, { is opened, and then
there is an #endif.  What do these three statements accomplish?


Near the bottom of the file, another #ifdef __cplusplus statement appears,
then the } is closed, and another #endif /* __cplusplus */ statement
appears.

I do not understand the function of the second #ifdef __cplusplus statement
just before the }. 

What is the purpose of the declaration (made somewhere else in the library)
of __cplusplus?  Where (in what file) is that declaration made?

All of the other statements in the file exif-data.h are contained between {
and  } , therefore, apparently controlled by the #ifdef __cplusplus
statement at the beginning.  Why?

Thanks,

Benny Smith
Santa Rosa, CA

Re: [Libexif-devel] Using libexif

[Dan F. <da...@co...>]

On Sun, Dec 14, 2008 at 11:15:06PM -0800, Benny Smith wrote:
> Your answers make me appreciate the cleverness of the camera manufacturers,
> whose digital cameras write to nearly every tag location in the Exif header.
> 
> Do you suppose that the controllers in those cameras are Linux-based?

Writing EXIF tags is a different problem from reading them, and a much easier
one, IMHO.  I know some digital cameras are Linux-based, but certainly
not the cheaper ones.

> Can you point me to a WEB site where I can learn how to tackle my
> application (specifically, reading and writing to Exif headers in JPG files)
> from the Linux hardware and software direction?

The libexif web site contains a few pointers to EXIF specifications and of
course the API.  libexif makes design decisions that assume a reasonable
amount of RAM is available.  You could write an EXIF parser that requires
much less RAM if you wanted to, but it would have other trade offs.  You
still haven't said what you're trying to accomplish, so it's hard to give
more specific suggestions.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Using libexif

[Benny S. <ich...@pa...>]

Dan,

Your answers make me appreciate the cleverness of the camera manufacturers,
whose digital cameras write to nearly every tag location in the Exif header.

Do you suppose that the controllers in those cameras are Linux-based?

Can you point me to a WEB site where I can learn how to tackle my
application (specifically, reading and writing to Exif headers in JPG files)
from the Linux hardware and software direction?

Benny 

-----Original Message-----
From: Dan Fandrich [mailto:da...@co...] 
Sent: Sunday, December 14, 2008 10:51 PM
To: lib...@li...
Subject: Re: [Libexif-devel] Using libexif

On Sun, Dec 14, 2008 at 10:01:53PM -0800, Benny Smith wrote:
> The reason I cannot compile libexif into a library as you instructed is
that
> Rabbit's Dynamic C is not an ANSI C language.  For instance, instead of
> #include, it requires #use.  There are other subtle differences that I
have
> to deal with in order for Dynamic C to accept and compile the libexif
files.
> 
> I have turned to the Rabbit embedded modules and Dynamic C because I
cannot
> find an 8-bit microcontroller with 64KB of onboard RAM to allow storage of
a
> complete Exif header, if necessary.  The Rabbit RCM2300 has 128K of RAM.

Hubert is right--it's hard to imagine an application that processes JPEG
images that will do anything useful in less than a few MB of memory.
The RAM you have left over from the EXIF table isn't enough for holding
a FAT table for reading an image from a memory card, or running gphoto2
(or something similar) to retrieve an image from serial/USB/Ethernet.
I don't know what your application is, but you'll certainly have plenty
of fun cramming it into a Rabbit!

> I asked about the internals of the libexif/exif-data.h because I am trying
> to understand exactly which libexif files (in the list of over 30) that I
> have to convert to Dynamic C in order for the library to compile and work
> properly.

It all depends on what you're trying to accomplish. You can get away with
just compiling exif-loader.c, exif-utils.c and exif-mem.c (there may be
one or two more) if you want the minimal functionality of loading EXIF
data from an image. If you want to look at individual tags, you'll need just
about the whole thing (minus the MakerNote handlers).  The entire library
(minus the verbose strings) compiles down to a 66 KiB shared library
on i386 Linux, which isn't much by Linux standards but is huge for a
Commodore 64 :^)

> Surely I am not the first person to use libexif for an embedded
application
> where memory is limited and where ANSI C may not be fully supported?

The kinds of embedded applications I'm aware of using libexif are embedded
Linux devices with 32 MB of RAM and an ARM processor.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

----------------------------------------------------------------------------
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Using libexif

[Dan F. <da...@co...>]

On Sun, Dec 14, 2008 at 10:01:53PM -0800, Benny Smith wrote:
> The reason I cannot compile libexif into a library as you instructed is that
> Rabbit's Dynamic C is not an ANSI C language.  For instance, instead of
> #include, it requires #use.  There are other subtle differences that I have
> to deal with in order for Dynamic C to accept and compile the libexif files.
> 
> I have turned to the Rabbit embedded modules and Dynamic C because I cannot
> find an 8-bit microcontroller with 64KB of onboard RAM to allow storage of a
> complete Exif header, if necessary.  The Rabbit RCM2300 has 128K of RAM.

Hubert is right--it's hard to imagine an application that processes JPEG
images that will do anything useful in less than a few MB of memory.
The RAM you have left over from the EXIF table isn't enough for holding
a FAT table for reading an image from a memory card, or running gphoto2
(or something similar) to retrieve an image from serial/USB/Ethernet.
I don't know what your application is, but you'll certainly have plenty
of fun cramming it into a Rabbit!

> I asked about the internals of the libexif/exif-data.h because I am trying
> to understand exactly which libexif files (in the list of over 30) that I
> have to convert to Dynamic C in order for the library to compile and work
> properly.

It all depends on what you're trying to accomplish. You can get away with
just compiling exif-loader.c, exif-utils.c and exif-mem.c (there may be
one or two more) if you want the minimal functionality of loading EXIF
data from an image. If you want to look at individual tags, you'll need just
about the whole thing (minus the MakerNote handlers).  The entire library
(minus the verbose strings) compiles down to a 66 KiB shared library
on i386 Linux, which isn't much by Linux standards but is huge for a
Commodore 64 :^)

> Surely I am not the first person to use libexif for an embedded application
> where memory is limited and where ANSI C may not be fully supported?

The kinds of embedded applications I'm aware of using libexif are embedded
Linux devices with 32 MB of RAM and an ARM processor.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Using libexif

[Hubert F. <hfi...@te...>]

On Sun, 2008-12-14 at 22:01 -0800, Benny Smith wrote:
> 
> Surely I am not the first person to use libexif for an embedded
> application
> where memory is limited and where ANSI C may not be fully supported?

Here, memory limitation are more in the neighborhood of 4 or 8MB of RAM.
And that's perfectly doable. I don't even see anything worth doing in
128KB even more when it comes to digital photography.


Hub

Re: [Libexif-devel] Using libexif

[Benny S. <ich...@pa...>]

Dan,

Thanks for the reply.

The reason I cannot compile libexif into a library as you instructed is that
Rabbit's Dynamic C is not an ANSI C language.  For instance, instead of
#include, it requires #use.  There are other subtle differences that I have
to deal with in order for Dynamic C to accept and compile the libexif files.

I have turned to the Rabbit embedded modules and Dynamic C because I cannot
find an 8-bit microcontroller with 64KB of onboard RAM to allow storage of a
complete Exif header, if necessary.  The Rabbit RCM2300 has 128K of RAM.

I asked about the internals of the libexif/exif-data.h because I am trying
to understand exactly which libexif files (in the list of over 30) that I
have to convert to Dynamic C in order for the library to compile and work
properly.

Surely I am not the first person to use libexif for an embedded application
where memory is limited and where ANSI C may not be fully supported?

Benny   

-----Original Message-----
From: Dan Fandrich [mailto:da...@co...] 
Sent: Sunday, December 14, 2008 9:29 PM
To: lib...@li...
Subject: Re: [Libexif-devel] Using libexif

On Sun, Dec 14, 2008 at 06:24:53PM -0800, Benny Smith wrote:
> I am a new user of libexif and am trying to apply it to an embedded
> application.
> 
> Unfortunately, I am having to tailor the library to the environment
(Rabbit
> Semiconductor?s Dynamic C) that I have chosen.

libexif is quite portable, so you shouldn't have any problem.  If you can
cross compile from a POSIX environment, then it should happen automagically.

> On the main page for libexif (http://libexif.sourceforge.net/internals/
> main.html), it appears that in order to use the library ?libexif?, one
need
> only insert the statement:   #include <libexif/libexif-data.h> .
> 
> Scanning through the code for libexif-data.h, I see lots of #include
statements
> for other libexif header files, but no #include statements for function
files
> such as exif-data.c  or exif-utils.c.  And, the header files that are
#included
> within exif-data.h seem not to contain any invocation of the function
files
> (*.c).
> 
> I expected that #including exif-data.h would, directly and indirectly,
cause
> all files of libexif to be included.
> 
> So, does an application program have to #include the *.c function files
from
> the libexif library separately?
> 
> What am I missing?

It sounds like you're missing the "lib" in "libexif". libexif is designed to
be compiled into a library which is then linked to your application.  The
standard build process creates a libexif.a and/or libexif.so file which
contains all the compiled binaries from the .c files.  When you add the
option "-lexif" to your app's link line (assuming a UNIX-like environment),
the code from the libexif library is added to your application.

You could compile all the .c files yourself, at the same time as your
application, but doing it separately as a library is a cleaner approach.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

----------------------------------------------------------------------------
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel

Re: [Libexif-devel] Using libexif

[Dan F. <da...@co...>]

On Sun, Dec 14, 2008 at 06:24:53PM -0800, Benny Smith wrote:
> On the main page for libexif (http://libexif.sourceforge.net/internals/
> main.html), it appears that in order to use the library ?libexif?, one need
> only insert the statement:   #include <libexif/libexif-data.h> .

One other point--if you're just using libexif in your application, you
shouldn't care about its internals.  The (much simpler) documentation at
http://libexif.sourceforge.net/api/ is all you need.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Using libexif

[Dan F. <da...@co...>]

On Sun, Dec 14, 2008 at 06:24:53PM -0800, Benny Smith wrote:
> I am a new user of libexif and am trying to apply it to an embedded
> application.
> 
> Unfortunately, I am having to tailor the library to the environment (Rabbit
> Semiconductor?s Dynamic C) that I have chosen.

libexif is quite portable, so you shouldn't have any problem.  If you can
cross compile from a POSIX environment, then it should happen automagically.

> On the main page for libexif (http://libexif.sourceforge.net/internals/
> main.html), it appears that in order to use the library ?libexif?, one need
> only insert the statement:   #include <libexif/libexif-data.h> .
> 
> Scanning through the code for libexif-data.h, I see lots of #include statements
> for other libexif header files, but no #include statements for function files
> such as exif-data.c  or exif-utils.c.  And, the header files that are #included
> within exif-data.h seem not to contain any invocation of the function files
> (*.c).
> 
> I expected that #including exif-data.h would, directly and indirectly, cause
> all files of libexif to be included.
> 
> So, does an application program have to #include the *.c function files from
> the libexif library separately?
> 
> What am I missing?

It sounds like you're missing the "lib" in "libexif". libexif is designed to
be compiled into a library which is then linked to your application.  The
standard build process creates a libexif.a and/or libexif.so file which
contains all the compiled binaries from the .c files.  When you add the
option "-lexif" to your app's link line (assuming a UNIX-like environment),
the code from the libexif library is added to your application.

You could compile all the .c files yourself, at the same time as your
application, but doing it separately as a library is a cleaner approach.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] How to get gps information from JPG File? Does anyone know how?

[yunwu y. <zhu...@ya...>]

thank you very much.I have solved this problem through reading some source code.
very thank you for your response.

8年12月13日，周六, Dan Fandrich <da...@co...> 写道：

发件人: Dan Fandrich <da...@co...>
主题: Re: [Libexif-devel] How to get gps information from JPG File? Does anyone know how?
收件人: lib...@li...
日期: 2008,1213,周六,7:00上午

On Mon, Dec 01, 2008 at 10:09:32AM +0800, yunwu yunwu wrote:
> Hi,folks:
>      Now I will want to use libexif to get gps information such as
> (latitude,longitude) from jpg file. I don't know how to realize the
function. I
> know  using  exif_entry_get_value can  get other information, but it seems
that
> this function can not get latitude and longitude contained in jpg. Does
any one
> know how to solve the problem? Thanks in advance.

You should be able to get an ExifEntry using exif_content_get_entry() then
access the raw data from that structure directly.  But the latest libexif
should also retrieve them as floats using exif_entry_get_value().

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
libexif-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libexif-devel



      ___________________________________________________________ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/

[Libexif-devel] Using libexif

[Benny S. <ich...@pa...>]

I am a new user of libexif and am trying to apply it to an embedded
application.

 

Unfortunately, I am having to tailor the library to the environment (Rabbit
Semiconductor's Dynamic C) that I have chosen.

 

On the main page for libexif
(http://libexif.sourceforge.net/internals/main.html), it appears that in
order to use the library "libexif", one need only insert the statement:
#include <libexif/libexif-data.h> .

 

Scanning through the code for libexif-data.h, I see lots of #include
statements for other libexif header files, but no #include statements for
function files such as exif-data.c  or exif-utils.c.  And, the header files
that are #included within exif-data.h seem not to contain any invocation of
the function files (*.c).

 

I expected that #including exif-data.h would, directly and indirectly, cause
all files of libexif to be included.

 

So, does an application program have to #include the *.c function files from
the libexif library separately?

 

What am I missing?

 

Benny Smith

Re: [Libexif-devel] How to get gps information from JPG File? Does anyone know how?

[Dan F. <da...@co...>]

On Mon, Dec 01, 2008 at 10:09:32AM +0800, yunwu yunwu wrote:
> Hi,folks:
>      Now I will want to use libexif to get gps information such as
> (latitude,longitude) from jpg file. I don't know how to realize the function. I
> know  using  exif_entry_get_value can  get other information, but it seems that
> this function can not get latitude and longitude contained in jpg. Does any one
> know how to solve the problem? Thanks in advance.

You should be able to get an ExifEntry using exif_content_get_entry() then
access the raw data from that structure directly.  But the latest libexif
should also retrieve them as floats using exif_entry_get_value().

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] A few little API changes

[Jan P. <pa...@pi...>]

Hi Dan,

I fully agree with your proposals. All are reasonable and have been
asked via the sf.net trackers. Please go ahead, if you have enough time
and energy!

 -- Jan

> There are a few little changes I think should be made to the libexif
> API. They should be fully backwards compatible (source and binary), but
> I thought I'd run them by everyone just in case I missed something.
>
> 1) There's no "official" way to give access to the raw EXIF data types--
> there's only exif_entry_get_value() which returns a text string.  I say
> official because the exif command-line accesses the raw tag, format,
> etc. members of the private _ExifEntry struct in order to do this.  What
> should be done is make this official by moving those members into
> ExifEntry directly, leaving only the remaining members (parent and priv)
> as private in _ExifEntry.
>
> I'm assuming that the split between ExifEntry and _ExifEntry is that the
> former are part of the API and the latter is supposed to be internal.
> Someone correct me if I'm wrong, and I suspect I might be because in
> addition to _ExifEntry there's also an ExifEntryPrivate.
>
> This will also require making exif_entry_alloc and exif_entry_realloc
> public in order to allow users to allocate their own ExifEntry->data
> members.
>
> 2) There's no way to indicate a failure on many of the API functions
> (e.g. failure to write to a file in exif_loader_write_file(), or an out
> of memory condition in exif_entry_initialize()). Making these functions
> return an error code should be backwards compatible since current
> applications will just ignore the returned value.
>
> 3) Several functions would benefit from making a parameter const.  Since
> this is on an input parameter, it should be fully backwards compatible.
>
>>>> Dan
> --
> http://www.MoveAnnouncer.com              The web change of address
> service
>           Let webmasters know that your web site has moved

[Libexif-devel] How to get gps information from JPG File? Does anyone know how?

[yunwu y. <zhu...@ya...>]

Hi,folks:
     Now I will want to use libexif to get gps information such as (latitude,longitude) from jpg file. I don't know how to realize the function. I know  using  exif_entry_get_value can  get other information, but it seems that this function can not get latitude and longitude contained in jpg. Does any one know how to solve the problem? Thanks in advance.
 
wood


      ___________________________________________________________ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/

[Libexif-devel] New Danish PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Italian PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Italian team of translators.  The file is available at:

    http://translationproject.org/latest/exif/it.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [Libexif-devel] A few little API changes

[Stanislav B. <sb...@su...>]

Dan Fandrich wrote:
> There are a few little changes I think should be made to the libexif
> API. They should be fully backwards compatible (source and binary),
> but I thought I'd run them by everyone just in case I missed something.


4) ExifTag should not be enum. Using non-unique values and values which
are not members of the enum definition (as exif-tag.h defines), is
against spirit of enum and may break with compilers enabling strict
checking.

Proposal: Either change to integer type of the original enum size (ABI
compatible, may require some configure magic) or change to uint16_t and
increment soname (only API compatible, but logical). Use #define for all
EXIF_TAG_* definitions, not only for half of them.


5) exif_tag_get_name(), exif_tag_get_title() and
exif_tag_get_description() are broken by design and any application
using them will get broken GPS tag.

Proposal: Enable them only with #ifdef LIBEXIF_ENABLE_BROKEN.


6) There is no way to get all tags known to libexif. Applications often
scan all possible 65536 values to get such list. It's not only
non-effective, but it's also broken (tags are not unique, application
needs another scanning to guess IFD).

Proposal: Define public table listing all tag/ifd pairs known to the
current version of libexif or implement something like
exif_tag_forall_known.


-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sb...@su...
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

[Libexif-devel] A few little API changes

[Dan F. <da...@co...>]

There are a few little changes I think should be made to the libexif
API. They should be fully backwards compatible (source and binary),
but I thought I'd run them by everyone just in case I missed something.

1) There's no "official" way to give access to the raw EXIF data types--
there's only exif_entry_get_value() which returns a text string.  I say
official because the exif command-line accesses the raw tag, format, etc.
members of the private _ExifEntry struct in order to do this.  What should
be done is make this official by moving those members into ExifEntry
directly, leaving only the remaining members (parent and priv) as private
in _ExifEntry.

I'm assuming that the split between ExifEntry and _ExifEntry is that the
former are part of the API and the latter is supposed to be internal.
Someone correct me if I'm wrong, and I suspect I might be because in addition
to _ExifEntry there's also an ExifEntryPrivate.

This will also require making exif_entry_alloc and exif_entry_realloc public
in order to allow users to allocate their own ExifEntry->data members.

2) There's no way to indicate a failure on many of the API functions
(e.g. failure to write to a file in exif_loader_write_file(), or an out of
memory condition in exif_entry_initialize()). Making these functions return
an error code should be backwards compatible since current applications
will just ignore the returned value.

3) Several functions would benefit from making a parameter const.  Since
this is on an input parameter, it should be fully backwards compatible.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

[Libexif-devel] New Danish PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Slovak PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Slovak team of translators.  The file is available at:

    http://translationproject.org/latest/exif/sk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Slovak PO file for 'libexif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Slovak team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/sk.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Chinese (simplified) PO file for 'exif' (version 0.6.17)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Chinese (simplified) team of translators.  The file is available at:

    http://translationproject.org/latest/exif/zh_CN.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>