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

[Libexif-devel] New German PO file for 'libexif' (version 0.6.21)

[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 German team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/de.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 'libexif' (version 0.6.21)

[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 Spanish PO file for 'libexif' (version 0.6.21)

[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 Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/es.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 Spanish PO file for 'libexif' (version 0.6.21)

[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 Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/es.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] [PATCH] exif-entry.c triggers MSVC warning C4018

[Peter K. <pka...@go...>]

diff --git a/libexif/exif-entry.c b/libexif/exif-entry.c
index 81d41d6..92ae07f 100644
--- a/libexif/exif-entry.c
+++ b/libexif/exif-entry.c
@@ -988,8 +988,8 @@ exif_entry_get_value (ExifEntry *e, char *val, unsigned int maxlen)
 		if (e->size && e->data) {
 			const unsigned char *tagdata = memchr(e->data, 0, e->size);
 			if (tagdata++) {
-				int editor_ofs = tagdata - e->data;
-				int remaining = e->size - editor_ofs;
+				size_t editor_ofs = (size_t)(tagdata - e->data);
+				size_t remaining = e->size - editor_ofs;
 				if (match_repeated_char(tagdata, ' ', remaining)) {
 					strncat (val, (const char*)tagdata, MIN (maxlen - strlen (val), remaining));
 					++k;

[Libexif-devel] New Malay PO file for 'exif' (version 0.6.21)

[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 Malay team of translators.  The file is available at:

    http://translationproject.org/latest/exif/ms.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 Russian PO file for 'exif' (version 0.6.21)

[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 Russian team of translators.  The file is available at:

    http://translationproject.org/latest/exif/ru.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 Spanish PO file for 'libexif' (version 0.6.21)

[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 Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/es.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 German PO file for 'libexif' (version 0.6.21)

[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 German team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/de.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] bug in exif_entry_get_value()

[<jc...@gm...>]

Hi all,

First, thanks for the library.

I recent debugged a bizarre problem in libexif. This image:

http://www.rollthepotato.net/~john/test.jpg

would cause my program to hang.

The cause turned out to be a corrupt exif field: the image has a
shutterspeed tag set to -2147483648 / 1. exif-entry.c does:

1103:
                d = (double) v_srat.numerator / (double) v_srat.denominator;
                snprintf (val, maxlen, _("%.02f EV"), d);
                d = 1. / pow (2, d);

And on some platforms, the pow() raises a math exception. This wasn't
caught by the runtime I was using, triggering a hang. I'm
cross-compiling to Windows from Linux with mingw, if that helps.

I'm not sure what the best solution is. Negative shutterspeed would
seem like a range error, so how about just cutting off all negatives?

Photoshop seems to hide fields that fail simple range tests, that's
probably another possible solution, but maybe harder to implement.

John

[Libexif-devel] New Spanish PO file for 'libexif' (version 0.6.21)

[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 Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/es.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...>

Re: [Libexif-devel] Problem editing GPS tags

[Lucía D. R. <ld...@gr...>]

Thank you so much for your help!

It's working nicely now. I was doing exactly as you said buuut (and I
should kick myself for that!) I was mishandling the value associated with
the tags :((.

Thanks again, and thanks for the library too!


2014-06-04 23:19 GMT+02:00 Dan Fandrich <da...@co...>:

> On Wed, Jun 04, 2014 at 10:41:52PM +0200, Lucía Díaz Rodríguez wrote:
> > Thank for your answer!!
> >
> > I've tried doing what exif_entry_initialize() does but I get a compiler
> error
> > at:
> >      exifentry->data = exif_entry_alloc (exifentry, exifentry->size);
> > because that is a private function on exif-entry.c. So I've tried doing
> what
> > that function does, that is:
> > exifentry->data = exif_mem_alloc (exifentry->priv->mem, exifentry->size);
> > but this also fails, because the compiler doesn't know
> exifentry->priv->mem
> > (error: invalid use of incomplete type ‘ExifEntryPrivate {aka struct
> > _ExifEntryPrivate}’).
> > And I could find where that is to give some reference to the compiler.
>
> IIRC, the right solution is to create an ExifEntry using
> exif_entry_new_mem,
> passing in an allocator of your own choosing. Then, you can use that
> allocator
> instead of the private one.
>
> > That's why I tried the write.exif.c bit:
> > buf = exif_mem_alloc(mem, exifentry->size);
> > assert(buf != NULL);
> > /* Fill in the entry */
> > exifentry->data = (unsigned char *)buf;
> > But the firs line results in segmentation fault, so that doesn't work
> either.
>
> It depends on where you got that mem pointer. Using exif_entry_new_mem,
> you can
> pass in your own (created from exif_mem_new_default) and it will be
> internally
> consistent.
>
> > So I really don't know what to do to make it work like it is supposed
> to, that
> > why I asked if is true that it works :))
> >
> > Thanks again,
> >
> > Lucía
> >
> >
> >
> >
> > 2014-06-04 21:07 GMT+02:00 Dan Fandrich <da...@co...>:
> >
> >     On Wed, Jun 04, 2014 at 04:33:51PM +0200, Lucía Díaz Rodríguez wrote:
> >     > I'm trying to add Exif information to a JPEG file. I've tried the
> exif
> >     command
> >     > line tool (v0.6.21) and the libexif API (v0.6.21-1).
> >     > Everything works fine until I get to the GPS information (Latitude,
> >     > LatitudeRef, Longitude and LongitudeRef). I'm able to read it if it
> >     already
> >     > exits but i'm not able to create or modify it.
> >     >
> >     > Using the exif command line tool (in Mint 16 64bits and also in
> Ubuntu
> >     12.04
> >     > 32-bits), like so:
> >     >       exif -c --ifd=GPS --tag=0x0001 --set-value="N"
> foto-exif.mjpg
> >     > I get this error:
> >     >       Setting a value for this tag is unsupported!
> >     > (Same result using --tag=GPSLatitudeRef).
> >
> >     That's a limitation in the command-line program that flows from
> missing
> >     tags in
> >     the library. There's no good reason for the tags to be missing,
> except that
> >     it's really a convenience function that most programs don't actually
> need.
> >     It would be possible to add command-line options to exif to support
> >     arbitrary
> >     tag data; I'm happy to review patches!
> >
> >     > Using the libexif API, when I try: exif_entry_initialize
> (exifentry,
> >     tag), the
> >     > tag is not listed in the switch cases so default it's used and the
> entry
> >     gets
> >     > FORMAT_UNDEFINED and components=0, which doesn't allocate any
> memory for
> >     the
> >     > associated data.
> >     > Even if I try to initialize the entry myself (like in the
> write-exif.c
> >     example)
> >     > I'm not able to do so for the data field (I get a segmentation
> fault on
> >     > exif_mem_alloc(mem, exifentry->size)).
> >
> >     That should work fine, except that write-exif.c relies on
> >     exif_entry_initialize
> >     to create the empty tag, so it's not a complete solution. Take a
> look at
> >     the code
> >     in exif_entry_initialize itself to figure out the rest.
> >
> >     > Now, I've found a bug report from 2005 (
> https://bugs.debian.org/cgi-bin/
> >     > bugreport.cgi?bug=309127) mentioning the GPS tags editing. In its
> >     response it's
> >     > stated that editing this sort of tags it's possible since exif
> 0.6.15.
> >     > Has anything changed since then? If not, would you be so kind as to
> >     explain to
> >     > me what am I doing wrong? I've already tried all I could think of
> and got
> >     > nowhere.
> >
> >     I don't recall what changes were made since then that would affect
> this,
> >     but
> >     libexif got more strict in a number of ways since then. I don't
> think any
> >     existing (working) functionality was removed.
> >
> >     >>> Dan
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel
>



--

Re: [Libexif-devel] Problem editing GPS tags

[Lucía D. R. <ld...@gr...>]

Thank for your answer!!

I've tried doing what exif_entry_initialize() does but I get a compiler
error at:
     exifentry->data = exif_entry_alloc (exifentry, exifentry->size);
because that is a private function on exif-entry.c. So I've tried doing
what that function does, that is:
exifentry->data = exif_mem_alloc (exifentry->priv->mem, exifentry->size);
but this also fails, because the compiler doesn't know
exifentry->priv->mem (error: invalid use of incomplete type
‘ExifEntryPrivate {aka struct _ExifEntryPrivate}’).
And I could find where that is to give some reference to the compiler.

That's why I tried the write.exif.c bit:
buf = exif_mem_alloc(mem, exifentry->size);
 assert(buf != NULL);
/* Fill in the entry */
 exifentry->data = (unsigned char *)buf;
But the firs line results in segmentation fault, so that doesn't work
either.

So I really don't know what to do to make it work like it is supposed to,
that why I asked if is true that it works :))

Thanks again,

Lucía




2014-06-04 21:07 GMT+02:00 Dan Fandrich <da...@co...>:

> On Wed, Jun 04, 2014 at 04:33:51PM +0200, Lucía Díaz Rodríguez wrote:
> > I'm trying to add Exif information to a JPEG file. I've tried the exif
> command
> > line tool (v0.6.21) and the libexif API (v0.6.21-1).
> > Everything works fine until I get to the GPS information (Latitude,
> > LatitudeRef, Longitude and LongitudeRef). I'm able to read it if it
> already
> > exits but i'm not able to create or modify it.
> >
> > Using the exif command line tool (in Mint 16 64bits and also in Ubuntu
> 12.04
> > 32-bits), like so:
> >       exif -c --ifd=GPS --tag=0x0001 --set-value="N" foto-exif.mjpg
> > I get this error:
> >       Setting a value for this tag is unsupported!
> > (Same result using --tag=GPSLatitudeRef).
>
> That's a limitation in the command-line program that flows from missing
> tags in
> the library. There's no good reason for the tags to be missing, except that
> it's really a convenience function that most programs don't actually need.
> It would be possible to add command-line options to exif to support
> arbitrary
> tag data; I'm happy to review patches!
>
> > Using the libexif API, when I try: exif_entry_initialize (exifentry,
> tag), the
> > tag is not listed in the switch cases so default it's used and the entry
> gets
> > FORMAT_UNDEFINED and components=0, which doesn't allocate any memory for
> the
> > associated data.
> > Even if I try to initialize the entry myself (like in the write-exif.c
> example)
> > I'm not able to do so for the data field (I get a segmentation fault on
> > exif_mem_alloc(mem, exifentry->size)).
>
> That should work fine, except that write-exif.c relies on
> exif_entry_initialize
> to create the empty tag, so it's not a complete solution. Take a look at
> the code
> in exif_entry_initialize itself to figure out the rest.
>
> > Now, I've found a bug report from 2005 (https://bugs.debian.org/cgi-bin/
> > bugreport.cgi?bug=309127) mentioning the GPS tags editing. In its
> response it's
> > stated that editing this sort of tags it's possible since exif 0.6.15.
> > Has anything changed since then? If not, would you be so kind as to
> explain to
> > me what am I doing wrong? I've already tried all I could think of and got
> > nowhere.
>
> I don't recall what changes were made since then that would affect this,
> but
> libexif got more strict in a number of ways since then. I don't think any
> existing (working) functionality was removed.
>
> >>> Dan
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel
>



--

Re: [Libexif-devel] Problem editing GPS tags

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

On Wed, Jun 04, 2014 at 04:33:51PM +0200, Lucía Díaz Rodríguez wrote:
> I'm trying to add Exif information to a JPEG file. I've tried the exif command
> line tool (v0.6.21) and the libexif API (v0.6.21-1). 
> Everything works fine until I get to the GPS information (Latitude,
> LatitudeRef, Longitude and LongitudeRef). I'm able to read it if it already
> exits but i'm not able to create or modify it.
> 
> Using the exif command line tool (in Mint 16 64bits and also in Ubuntu 12.04
> 32-bits), like so:
>       exif -c --ifd=GPS --tag=0x0001 --set-value="N" foto-exif.mjpg 
> I get this error:
>       Setting a value for this tag is unsupported!
> (Same result using --tag=GPSLatitudeRef).

That's a limitation in the command-line program that flows from missing tags in
the library. There's no good reason for the tags to be missing, except that
it's really a convenience function that most programs don't actually need.
It would be possible to add command-line options to exif to support arbitrary
tag data; I'm happy to review patches!

> Using the libexif API, when I try: exif_entry_initialize (exifentry, tag), the
> tag is not listed in the switch cases so default it's used and the entry gets
> FORMAT_UNDEFINED and components=0, which doesn't allocate any memory for the
> associated data.
> Even if I try to initialize the entry myself (like in the write-exif.c example)
> I'm not able to do so for the data field (I get a segmentation fault on
> exif_mem_alloc(mem, exifentry->size)).

That should work fine, except that write-exif.c relies on exif_entry_initialize
to create the empty tag, so it's not a complete solution. Take a look at the code
in exif_entry_initialize itself to figure out the rest.

> Now, I've found a bug report from 2005 (https://bugs.debian.org/cgi-bin/
> bugreport.cgi?bug=309127) mentioning the GPS tags editing. In its response it's
> stated that editing this sort of tags it's possible since exif 0.6.15. 
> Has anything changed since then? If not, would you be so kind as to explain to
> me what am I doing wrong? I've already tried all I could think of and got
> nowhere.

I don't recall what changes were made since then that would affect this, but
libexif got more strict in a number of ways since then. I don't think any
existing (working) functionality was removed.

>>> Dan

[Libexif-devel] Problem editing GPS tags

[Lucía D. R. <ld...@gr...>]

Hi,

I'm trying to add Exif information to a JPEG file. I've tried the exif
command line tool (v0.6.21) and the libexif API (v0.6.21-1).
Everything works fine until I get to the GPS information (Latitude,
LatitudeRef, Longitude and LongitudeRef). I'm able to read it if it already
exits but i'm not able to create or modify it.

Using the exif command line tool (in Mint 16 64bits and also in Ubuntu
12.04 32-bits), like so:
      exif -c --ifd=GPS --tag=0x0001 --set-value="N" foto-exif.mjpg
I get this error:
      Setting a value for this tag is unsupported!
(Same result using --tag=GPSLatitudeRef).

Using the libexif API, when I try: exif_entry_initialize (exifentry, tag),
the tag is not listed in the switch cases so default it's used and the
entry gets FORMAT_UNDEFINED and components=0, which doesn't allocate any
memory for the associated data.
Even if I try to initialize the entry myself (like in the write-exif.c
example) I'm not able to do so for the data field (I get a segmentation
fault on exif_mem_alloc(mem, exifentry->size)).

Now, I've found a bug report from 2005 (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309127) mentioning the
GPS tags editing. In its response it's stated that editing this sort of
tags it's possible since exif 0.6.15.
Has anything changed since then? If not, would you be so kind as to explain
to me what am I doing wrong? I've already tried all I could think of and
got nowhere.


​Thanks​,

Lucía

--

[Libexif-devel] New Galician PO file for 'exif' (version 0.6.21)

[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 Galician team of translators.  The file is available at:

    http://translationproject.org/latest/exif/gl.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 Latvian PO file for 'exif' (version 0.6.21)

[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 Latvian team of translators.  The file is available at:

    http://translationproject.org/latest/exif/lv.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] Standard dimension of thumbnail in jpeg

[n179911 <n1...@gm...>]

Hi,

Is 160x120 the standard dimension for thumbnail in jpeg? regardless of
the actual dimension of the image?
Does the thumbnail has a parameter to tell if the thumbnail is in
landscape or portrait?

Thank you.
Sam

Re: [Libexif-devel] Translations for the exif.1 man page

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

On Sun, Apr 20, 2014 at 12:20:29PM +0200, Mario Blättermann wrote:
> Any news about that? Do you need some more info? Unfortunately, I cannot help
> out with implementing this, besides to use my scripts. Even if it doesn't work
> yet in the build chain, the module on TP could be created to get man pages in
> more native languages. This gives translators some extra time to work on this.

I've just been too busy to get to the long list of libexif tasks I have on my
plate. If someone were to submit patches, it would definitely short-cut the
process :^)

>>> Dan

Re: [Libexif-devel] Translations for the exif.1 man page

[Mario B. <mar...@gm...>]

Hi all,

Am 03.04.2014 10:52, schrieb Mario Blättermann:
> Hi Dan,
> 
> Am 03.04.2014 09:02, schrieb Dan Fandrich:
>> On Tue, Mar 18, 2014 at 01:36:57PM +0100, Mario Blättermann wrote:
>>> both the libexif library and the exif command line tool are translatable
>>> at translationproject.org. But we should also internationalize the exif man
>>> page and publish the translation template there.
>>>
>>> Using po4a this is quite easy. Have a look at the attachment. There you'll
>>> find two scripts which generate the pot file and translate the po files
>>> back to the actual man page, respectively. For testing purposes, I've also
>>> added a German translation file.
>>
>> I've never seen manual pages translated using the .po mechanism like this.
> 
> Most of the (active) external translation projects like man-pages-de or
> man-pages-fr already use po4a. Moreover, the Debian folks uses it for almost all
> the dpkg and apt man pages.
> 
>> It makes good sense as the translation workflow is unaltered.
>>
> 
> The translation workflow...? I assume you mean the workflow on translators side.
> That's unaltered. Translators get a pot template from the TP robot, translate
> the messages and send it back. That's the greatest advantage of po4a: Nobody has
> to bother with plain text, which would include to figure out a way to track
> upstream changes accordingly. In other words, I wouldn't start on a translation
> without po files.
> 
>>> We need some glue code to install the files accordingly, but I don't know 
>>> anything about how the Autotools work, sorry. The translated files itself
>>> are already in the correct paths when using the scripts ($PREFIX/man still
>>> has to be preceded).
>>>
>>> In general, the generation of the translated man pages should happen before
>>> the release tarball will be created. That way packagers don't have to
>>> bother with po4a, especially if a po4a package is missing from certain
>>> distributions. Shouldn't be a problem, the man pages are arch-independent
>>> anyway.
>>>
>>> Besides that, the localized versions could be presented at the website,
>>> too. The English one is already present.
>>
>> I'll take a look at what it would take to integrate this. Thanks for
>> bringing it to our attention.
>>
> Thanks for your interest.
> 
Any news about that? Do you need some more info? Unfortunately, I cannot help
out with implementing this, besides to use my scripts. Even if it doesn't work
yet in the build chain, the module on TP could be created to get man pages in
more native languages. This gives translators some extra time to work on this.

Best Regards,
Mario

[Libexif-devel] How does libexif works with libjpeg to insert exif data in jpeg file?

[n179911 <n1...@gm...>]

How does libexif works with libjpeg to insert exif data in jpeg file?

I think libjpeg creates JPEG header and JPEG image data.
I think EXIF data is after JPEG header and before JPEG image data.

To create a jpeg image with EXIF header, do I need to

0. allocate a new buffer big enough for JPEG header + EXIF header +
JPEG image data
1. memcpy the JPEG header created by libjpeg
2. memcpy the EXIF header created by libexif
3. memcpy the JPEG image date created by libjpeg

Thank you.

Re: [Libexif-devel] Translations for the exif.1 man page

[Mario B. <mar...@gm...>]

Hi Dan,

Am 03.04.2014 09:02, schrieb Dan Fandrich:
> On Tue, Mar 18, 2014 at 01:36:57PM +0100, Mario Blättermann wrote:
>> both the libexif library and the exif command line tool are translatable
>> at translationproject.org. But we should also internationalize the exif man
>> page and publish the translation template there.
>> 
>> Using po4a this is quite easy. Have a look at the attachment. There you'll
>> find two scripts which generate the pot file and translate the po files
>> back to the actual man page, respectively. For testing purposes, I've also
>> added a German translation file.
> 
> I've never seen manual pages translated using the .po mechanism like this.

Most of the (active) external translation projects like man-pages-de or
man-pages-fr already use po4a. Moreover, the Debian folks uses it for almost all
the dpkg and apt man pages.

> It makes good sense as the translation workflow is unaltered.
> 

The translation workflow...? I assume you mean the workflow on translators side.
That's unaltered. Translators get a pot template from the TP robot, translate
the messages and send it back. That's the greatest advantage of po4a: Nobody has
to bother with plain text, which would include to figure out a way to track
upstream changes accordingly. In other words, I wouldn't start on a translation
without po files.

>> We need some glue code to install the files accordingly, but I don't know 
>> anything about how the Autotools work, sorry. The translated files itself
>> are already in the correct paths when using the scripts ($PREFIX/man still
>> has to be preceded).
>> 
>> In general, the generation of the translated man pages should happen before
>> the release tarball will be created. That way packagers don't have to
>> bother with po4a, especially if a po4a package is missing from certain
>> distributions. Shouldn't be a problem, the man pages are arch-independent
>> anyway.
>> 
>> Besides that, the localized versions could be presented at the website,
>> too. The English one is already present.
> 
> I'll take a look at what it would take to integrate this. Thanks for
> bringing it to our attention.
> 
Thanks for your interest.

Best Regards,
Mario

[Libexif-devel] Translations for the exif.1 man page

[Mario B. <mar...@gm...>]

Hi,

both the libexif library and the exif command line tool are translatable at
translationproject.org. But we should also internationalize the exif man page
and publish the translation template there.

Using po4a this is quite easy. Have a look at the attachment. There you'll find
two scripts which generate the pot file and translate the po files back to the
actual man page, respectively. For testing purposes, I've also added a German
translation file.

We need some glue code to install the files accordingly, but I don't know
anything about how the Autotools work, sorry. The translated files itself are
already in the correct paths when using the scripts ($PREFIX/man still has to be
preceded).

In general, the generation of the translated man pages should happen before the
release tarball will be created. That way packagers don't have to bother with
po4a, especially if a po4a package is missing from certain distributions.
Shouldn't be a problem, the man pages are arch-independent anyway.

Besides that, the localized versions could be presented at the website, too. The
English one is already present.

Best Regards,
Mario

[Libexif-devel] New Japanese PO file for 'exif' (version 0.6.21)

[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 Japanese team of translators.  The file is available at:

    http://translationproject.org/latest/exif/ja.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 Spanish PO file for 'libexif' (version 0.6.21)

[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 Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/es.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...>