Hi Andreas & all,
I downloaded exiv2 v0.18 and I wanted to build a dll in windows using
MinGW/msys.
I'd like to share my results, hoping that someone more fluent in
autotools & company would be able to spot my errors or make the
process more "streamlined".

here's some packages I have installed:
gcc-core-4.2.1-sjlj-2
gcc-g++-4.2.1-sjlj-2
w32api-3.10
binutils-2.17.50-20060824-1
mingw32-make-3.81-2
mingw-runtime-3.13

So I opened an msys shell and configured exiv2 with:
./configure  --disable-xmp  --disable-visibility

It seems like I have to use --disable-visibility to avoid warning
messages (output by g++) like these:
warning: visibility attribute not supported in this configuration; ignored
Are gcc's visibility attributes an ELF exclusive or are those
available also for PE targets?
My g++ was built like this:
$ g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc
--enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32
--program-suffix=-sjlj --with-arch=i486 --with-tune=generic
--disable-werror --prefix=/mingw --with-local-prefix=/mingw
--enable-threads --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++,ada
--disable-win32-registry --enable-sjlj-exceptions
--enable-libstdcxx-debug --enable-cxx-flags=-fno-function-sections
-fno-data-sections --enable-version-specific-runtime-libs
--disable-bootstrap
Thread model: win32
gcc version 4.2.1-sjlj (mingw32-2)


I then built exiv2 with:
make LDFLAGS="-no-undefined  -L/usr/local/lib"
the -no-undefined switch was required so that libtool would be able to
build the dll. Without it libtool complains with:
libtool: link: warning: undefined symbols not allowed in
i686-pc-mingw32 shared libraries
and builds only the static lib of exiv2.
the -L/usr/local/lib switch was required because otherwise libtool
wasn't able to find the libraries for libz (aka zlib): in
C:\msys\1.0\local\lib (mounted in /usr/local/lib) I have the following
files from the GnuWin32 package of zlib:
libz.a
libz.dll (renamed from the zlib1.dll)
libz.dll.a

The build process completes and I have a working libexiv2-5.dll file
which I am able to link against.
Why does libtool appends -5 btw?

happy new year to y'all
Giuseppe

I can compile and run the exiv examples, but I've been trying to get
exiv to work in a simple Windows Forms Application, but I'm getting
the same errors:

1>------ Build started: Project: exiv test2, Configuration: Debug
Win32 ------
1>Linking...
1>exiv test2.obj : error LNK2028: unresolved token (0A00000E) "public:
virtual void __clrcall Exiv2::Image::clearMetadata(void)"
(?clearMetadata@Image@Exiv2@@$$FUAMXXZ) referenced in function "void
__clrcall `dynamic initializer for 'const
Exiv2::Image::`vftable'''(void)"
(???__E??_7Image@Exiv2@@6B@@@YMXXZ@?A0x914732b6@@$$FYMXXZ)
1>exiv test2.obj : error LNK2028: unresolved token (0A00000F) "public:
virtual void __clrcall Exiv2::Image::setMetadata(class Exiv2::Image
const &)" (?setMetadata@Image@Exiv2@@$$FUAMXABV12@@Z) referenced in
function "void __clrcall `dynamic initializer for 'const
Exiv2::Image::`vftable'''(void)"
(???__E??_7Image@Exiv2@@6B@@@YMXXZ@?A0x914732b6@@$$FYMXXZ)

: much more similar errors and then a lot of LNK2019 errors :

1>exiv test2.obj : error LNK2019: unresolved external symbol "public:
virtual void __clrcall Exiv2::Image::clearExifData(void)"
(?clearExifData@Image@Exiv2@@$$FUAMXXZ) referenced in function "void
__clrcall `dynamic initializer for 'const
Exiv2::Image::`vftable'''(void)"
(???__E??_7Image@Exiv2@@6B@@@YMXXZ@?A0x914732b6@@$$FYMXXZ)
1>exiv test2.obj : error LNK2019: unresolved external symbol "public:
virtual void __clrcall Exiv2::Image::setExifData(class Exiv2::ExifData
const &)" (?setExifData@Image@Exiv2@@$$FUAMXABVExifData@2@@Z)
referenced in function "void __clrcall `dynamic initializer for 'const
Exiv2::Image::`vftable'''(void)"
(???__E??_7Image@Exiv2@@6B@@@YMXXZ@?A0x914732b6@@$$FYMXXZ)
1>E:\programming\visual c++\tests\exiv test2\Debug\exiv test2.exe :
fatal error LNK1120: 112 unresolved externals
1>Build log was saved at "file://e:\programming\visual c++\tests\exiv
test2\exiv test2\Debug\BuildLog.htm"
1>exiv test2 - 113 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
==========

I've specified the Additional Library Directories (Configuration
properties > Linker > General).
"D:\c++\exiv2-0.18\msvc\xmpsdk\Debug"
"D:\c++\zlib123\lib"
"D:\c++\exiv2-0.18\msvc\exifcomment\Debug"
"D:\c++\exiv2-0.18\msvc\bin\DebugDLL"
"D:\c++\exiv2-0.18\msvc\bin\Debug"

And the following Additional Dependencies (Configuration properties >
Linker > Input)
exiv2.lib
libexpatMT.lib
zlib1.lib
xmpsdk.lib

Any ideas pointers to why it's not working for me?

Happy new year!

Marijn.

> - Video metadata support (AVI, MPEG, MOV, etc). Read only on the
first time.
As long as the type of metadata is Exif, IPTC or XMP, this requires
new Image classes only and can go into the trunk, i.e., in 0.18.x
For new types of metadata, it depends on the "unified metadata container".

> - As my wife has a new Sony camera, added Sony Makernotes (based on
Minolta)
Great, the Sony makernote implementation has been totally neglected.
The kids have just ruined our Sony camera and I'm looking at one from
Panasonic to replace it. Goes in the trunk

> - Cmake port. I'm very familiarized with CMake since digiKam & co
are based
> on it.
There are working cmake config files in the unstable branch, have a
look! But I foresee a substantial amount of work before I can remove
the old build system. I'll definitely need help to complete this one.
Eventually 0.19 will build with cmake.

-ahu.

Now that 0.18 is out of the door, what's next with Exiv2?

To recap: 0.18 finally brought the long awaited TIFF support. Under
the hood, a totally new TIFF parser has replaced the old one. The new
engine is highly configurable and takes care of many makernote
oddities in passing, which means that it is now much easier to add
support for new makernotes and more complete makernote implementations
are possible without extra code. At the same time, just updating
makernote (or any other) tags and adding pretty-print functions is now
something that can be done with almost no C++ knowledge.
Architecturally, I feel the design in the areas image, parser and tags
is sound now.

The remaining part of the system that needs attention are the
metadatum containers and related classes. Currently we have three
different but very similar container, key and metadatum classes, one
set for each supported metadata type. This design doesn't allow the
addition of metadata of a new type without writing a new set of
container, key and metadatum classes. Applications would need to be
aware of these new classes before they could use any such newly
supported metadata type. Several metadata types are waiting: ICC
profiles, PrintIM, "generic image info" for example.

The main goal for 0.19 is to introduce a single "unified metadata
container", for metadata of all types, which will replace the three
existing container classes. Along with that, the key and metadatum
classes will be re-designed/simplified.
The issue tracker has a more complete list of items on the roadmap for
0.19: http://dev.exiv2.org/projects/roadmap/exiv2

After 0.19 I am looking at a 1.0 release, not only to proof the myth
wrong that Open Source software never reaches stable status, but more
importantly, to officially declare that the API is stable and will
subsequently only change in a very controlled manner.

In the meantime, development for 0.19 will be done in the unstable
branch in SVN. Bugfixes and features which don't introduce any API
incompatibility will go into the trunk so we will be able to release
0.18.x whenever it is appropriate.

Finally, we will shortly have a new "community website". Brad has
installed Redmine (www.redmine.org) and migrated all the Mantis issues
and SVN commits to that application. I've been using this in parallel
with the existing issue tracker for a while and I think it works very
well. For a sneak-preview, have a look at http://dev.exiv2.org and
feel free to comment here, but please wait for my announcement before
making changes on that site.

Andreas

Hi Andreas,

> The functionality is in *Parser classes: ExifParser, TiffParser,
> XmpParser, IptcParser. Their job is to decode and encode metadata
> from/to a binary form. But in a standard use case you usually only
> deal with classes Image and the metadata containers and don't need
to
> deal with the parsers directly.
Ah thanks ! No wonder I haven't found them, it's not available in
exiv2 0.17... I have never expressed how happy I was with the API of
exiv2, it's from far the nicest API to access low level image
related data I have ever used. But, if I have one little wish, it
would be a stronger commitment to API stability, or at
least "overlapping" between removed functions and their replacement.

That's said, keep going on the great work.

Cyrille Berger

Hi Cyrille,

> I heard that the function copy and load have been removed recently
> in Exiv2

That's right, they have been moved from the metadata containers to
dedicated parser classes.

> and I didn't find a proper replacement for them.

The functionality is in *Parser classes: ExifParser, TiffParser,
XmpParser, IptcParser. Their job is to decode and encode metadata
from/to a binary form. But in a standard use case you usually only
deal with classes Image and the metadata containers and don't need to
deal with the parsers directly.

> And no
> loading the full image in a buffer and then giving that buffer to
> Image::open is not a good option, our file loading relies on using
> stream,

Can you elaborate on that file loading mechanism? Using
ImageFactory::open with a memory buffer or a file path is just one way
to instantiate an Exiv2::Image. There is a more interesting method:
ImageFactory::open (BasicIo::AutoPtr io)
http://www.exiv2.org/doc/classExiv2_1_1ImageFactory.html#b5634be654818fe1ad9d991\
1ef04ffe3
which can be used with your own implementation of BasicIo. See this
post http://uk.groups.yahoo.com/group/exiv2/message/1224 and Marco's
reply for an example.

Andreas

Hi,

I heard that the function copy and load have been removed recently
in Exiv2, and I didn't find a proper replacement for them. And no
loading the full image in a buffer and then giving that buffer to
Image::open is not a good option, our file loading relies on using
stream, which means at no point of time we have the full image file
in memory, and we do wish to keep it that way for a couple of reason
that are out of topic for this list. So I was wondering, have I miss
it, and is there an other way to load exif data without having an
image ?

Cyrille Berger (from the KOffice/Krita team)

> I think it would be better to preserve whatever types the tags in the
> image already have. I don't see why gthumb should change any tag type.

Thanks for all the suggestions, Andreas!

I've patched my code so that the original metadata is copied from a
backup of the original file, to preserving typing. The modified
metadata is then written from the string pairs. And everyone is happy :-)

- Mike

> (*) One can argue that there is an inconsistency in Exiv2 itself with
> regards to these array tag types and that they should default to the
> correct type, since it is known. I'll open a bug for this, but I
> consider this a detail.

http://dev.robotbattle.com/bugs/view.php?id=593

Hi Matěj,

The API changed. See
http://uk.groups.yahoo.com/group/exiv2/message/1335 and
http://www.exiv2.org/doc/classExiv2_1_1ExifThumbC.html

For sample code to help with the transition, look for ExifThumb in
actions.cpp (code of exiv2 utility), e.g.,
http://uk.groups.yahoo.com/group/exiv2/message/1339

HTH
Andreas

When trying to build pyexiv2 on Fedora Rawhide, it crashed with this
(complete log is
http://mcepl.fedorapeople.org/tmp/build-0.1.2-6.fc11.log):

g++ -o build/libpyexiv2.os -c -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC
-I/usr/include/python2.6 src/libpyexiv2.cpp
src/libpyexiv2.cpp: In member function 'boost::python::tuple
LibPyExiv2::Image::getThumbnailData()':
src/libpyexiv2.cpp:312: error: 'Exiv2::Thumbnail' has not been declared
src/libpyexiv2.cpp:312: error: expected `;' before 'thumbnail'
src/libpyexiv2.cpp:313: error: 'thumbnail' was not declared in this scope
src/libpyexiv2.cpp:315: error: 'class Exiv2::ExifData' has no member
named 'thumbnailFormat'
src/libpyexiv2.cpp:322: error: 'class Exiv2::ExifData' has no member
named 'copyThumbnail'
src/libpyexiv2.cpp: In member function 'void
LibPyExiv2::Image::setThumbnailData(std::string)':
src/libpyexiv2.cpp:346: error: 'class Exiv2::ExifData' has no member
named 'setJpegThumbnail'
src/libpyexiv2.cpp: In member function 'void
LibPyExiv2::Image::deleteThumbnail()':
src/libpyexiv2.cpp:355: error: 'class Exiv2::ExifData' has no member
named 'eraseThumbnail'
src/libpyexiv2.cpp: In member function 'void
LibPyExiv2::Image::dumpThumbnailToFile(std::string)':
src/libpyexiv2.cpp:364: error: 'class Exiv2::ExifData' has no member
named 'writeThumbnail'
src/libpyexiv2.cpp: In member function 'void
LibPyExiv2::Image::setThumbnailFromJpegFile(std::string)':
src/libpyexiv2.cpp:376: error: 'class Exiv2::ExifData' has no member
named 'setJpegThumbnail'
scons: *** [build/libpyexiv2.os] Error 1

I had no problems with 0.17. Any ideas, what's wrong? When trying

[matej@hubmaier exiv2]$ grep -r Thumbnail *
exif.hpp:        void setJpegThumbnail(
exif.hpp:        void setJpegThumbnail(
exif.hpp:        void setJpegThumbnail(const std::string& path);
exif.hpp:        void setJpegThumbnail(const byte* buf, long size);
exif.hpp:                 Exif.%Thumbnail.*, i.e., Exif IFD1 tags.
xmp.hpp:            includeThumbnailPad = 0x0100UL,  //!< Include a
padding allowance for a thumbnail image.
[matej@hubmaier exiv2]$

I get no Thumbnail method. Any ideas? Did the method moved somewhere,
or it is a packaging bug?

Thanks for any reply,

Matěj Cepl

> Exif.CanonCs.0x002b shows up as "Ascii" before it is written, not
"Short".

Ok. That explains the error that you're seeing. Exif.CanonCs.* tags
are stored in an array of unsigned shorts (in the value of
Exif.Canon.CameraSettings), their type must be "Short".

> In other words, in this operation, nothing is loaded from
> image1->exifData(). It comes from the stored name/value string pairs,
> and we count on exiv2 to automagically handle the typing issues.

I'm still working on the magical bits ;) In the meantime, this is what
happens in a line like ed["Exif.CanonCs.0x002b"] = std::string(value):

1) op[] looks up the tag in ed and creates a new metadatum if it's not
there
2) op= sets the value. But first, if the metadatum has no value yet, a
new empty value is created. The type is taken from Exiv2's tag lookup
tables. If the tag is not found in the table, the type defaults to Ascii.

So when the tags are set from the stored name/value string in gthumb,
I believe this will reset the type of the tag to Exiv2's default type
for that tag and if Exiv2 doesn't know the tag, the type will become
"Ascii". Usually this happens quietly except for array element tags
which need to have a specific type(*).

To check if this hypothesis is correct, you could try this: Set an
unknown tag in an image (without a Canon makernote) to something other
than an Ascii string, process it with gthumb and check the tag
afterwards, eg:

    exiv2 -M"set Exif.Image.0x1234 Long 1234" image.jpg


I think it would be better to preserve whatever types the tags in the
image already have. I don't see why gthumb should change any tag type.
Eg, for some tags the Exif standard allows a choice of types, but
Exiv2 defaults to just one of them. There is really no reason to
change if the original tag happens to have another valid type.

One way to do this would be to store type information together with
tag names and values and create a value of that type explicitly
instead of letting Exiv2 determine the type. Another way could be to
keep the original ExifData (IptcData and XmpData) container instead of
converting it to a key/value string pair and build a C interface to
access it from other parts of gthumb.

> And it looks like the handling of Exif.CanonCs.0x002b goes wrong.

(*) One can argue that there is an inconsistency in Exiv2 itself with
regards to these array tag types and that they should default to the
correct type, since it is known. I'll open a bug for this, but I
consider this a detail.

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
> However, from experience, it is more efficient if we do this together
> and I refrain from debugging your application. Can you try this for a
> start, to check in particular, if the type of tag Exif.CanonCs.0x002b
> is "Short" before the Exif data is written:

Thanks Andreas!

Exif.CanonCs.0x002b shows up as "Ascii" before it is written, not "Short".

Just so you understand the code, we first read the file and store the
metadata in a basic name/value string pairs (metadatum->full_name,
metadatum->raw_value). Then the image is cropped and saved without
metadata. Then we try to re-insert the metadata from the saved
name/value pairs.

In other words, in this operation, nothing is loaded from
image1->exifData(). It comes from the stored name/value string pairs,
and we count on exiv2 to automagically handle the typing issues.

And it looks like the handling of Exif.CanonCs.0x002b goes wrong.

So... what next?

- Mike

Hi Mike,

The test image, error message and reference to your code are good
starting points.

However, from experience, it is more efficient if we do this together
and I refrain from debugging your application. Can you try this for a
start, to check in particular, if the type of tag Exif.CanonCs.0x002b
is "Short" before the Exif data is written:

In the method that you pointed out, insert code to print the Exif data
just after it is read and again, just before it is written, and post
that here. Something like this should do the job (from
samples/exifprint.cpp):

     Exiv2::ExifData::const_iterator end = ed.end();
     for (Exiv2::ExifData::const_iterator i = ed.begin(); i != end; ++i) {
         std::cout << std::setw(44) << std::setfill(' ') << std::left
                   << i->key() << " "
                   << "0x" << std::setw(4) << std::setfill('0') <<
std::right
                   << std::hex << i->tag() << " "
                   << std::setw(9) << std::setfill(' ') << std::left
                   << i->typeName() << " "
                   << std::dec << std::setw(3)
                   << std::setfill(' ') << std::right
                   << i->count() << "  "
                   << std::dec << i->value()
                   << "\n";
     }

Andreas

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
>
> > Anyway... I'm running into a different issue. My metadata copying code
> > isn't working. Is that expected with the new API?
>
> [...]
>
> > Anything obviously wrong here?
>
> No, this looks perfectly ok. Can you provide some more details or a
> reproducer for the issue?

Andreas,

I never resolved this issue due to a crippling lack of free time, and
now 0.18 is here... Could you take a peek at gthumb trunk? When I try
to write metadata during certain operations, it fails entirely with
this message:

TIFF array element tag 43 has wrong type

Here's how to reproduce:

1) Download the test image at
http://www.avtechpulse.com/downloads/test.jpg

2) Get gthumb trunk:

svn co http://svn.gnome.org/svn/gthumb/trunk
cd trunk
./autogen.sh --prefix=/usr CFLAGS="-Wall -ggdb"
make
make install
gthumb

3) Browse to the folder containing test.jpg. Select test.jpg. If the
metadata sidebar is not showing, press Ctrl+2. It should show lots of
metadata.

4) Press enter to open the image.

5) Press Alt+c to load the crop screen. Select an area, press "Crop",
then press "Save".

6) Click on "Close" to return to the browser view.

7) The metadata sidebar should show that no metadata is present. The
console output should show what was supposed to be written, and the
above-mentioned tiff error.


The relevant subroutine is here:
http://svn.gnome.org/viewvc/gthumb/trunk/libgthumb/gth-exiv2-utils.cpp?annotate=\
2459#l571

It's the "image2->writeMetadata();" that seems to fail.


- Mike

This is the final 0.18 release, with write-support for TIFF, DNG, NEF,
PEF, PNG and JP2 images, makernote updates and access to image
previews. On Windows, Exiv2 can now be built as a DLL. In addition to
the changes in the 0.18 pre-releases, the Exiv2 command line utility
has new options to show all (Exif, IPTC and XMP) metadata and to list
and extract preview images.

It's the work of many and marks a major milestone in the history of Exiv2.

Enjoy!

Andreas

http://www.exiv2.org/download.html

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
>
> Checked in your patch with r1703. I couldn't find an "svn patch" tool
> to deal with the property changes in the patch file, so this required
> some semi-automated work. Appreciate if you check carefully.
>

I updated my local copy that only had my patch changes. After updating
none of the files were modified anymore, so everything apparently went
fine. Thanks!

Regards,
Dimitri

Checked in your patch with r1703. I couldn't find an "svn patch" tool
to deal with the property changes in the patch file, so this required
some semi-automated work. Appreciate if you check carefully.

Thanks,
Andreas

--- In exiv2@..., "Brad Schick" <brad@...> wrote:
>
> --- In exiv2@..., "Andreas Huggel" <ahuggel@> wrote:
> >
> > Thanks for the patch, I'll work on this over the weekend.
> > There is something wrong with the bug tracker, I'll check that too.
> >
> > Andreas
> >
>
> Sorry about that. The upload directory setting was clobbered when I
> upgraded Mantis. It should work now.

Thanks, it works now! I didn't expect the issues to be created after
the failed upload, but they did. I only now noticed because I got 2
deletion notifications by email, my apologies for the duplicates.

Regards,
Dimitri

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
>
> Thanks for the patch, I'll work on this over the weekend.
> There is something wrong with the bug tracker, I'll check that too.
>
> Andreas
>

Sorry about that. The upload directory setting was clobbered when I
upgraded Mantis. It should work now.

-Brad

Thanks for the patch, I'll work on this over the weekend.
There is something wrong with the bug tracker, I'll check that too.

Andreas

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
>
>
> > > By convention, I try to keep the properties the same for similar
> files.
> > > I'll have a look and clean this up.
> >
> > OK, if you hadn't started yet I can do it, I already had a semi-patch
> > here but wanted to know beforehand what the convention is instead of
> > sending another patch later on. Otherwise I'll await your changes and
> > see if there's anything left for me.
>
> I haven't started yet. Would appreciate your patch.

I tried submitting a bug but upon submitting I get an error:

"APPLICATION ERROR #503

Invalid upload path. Directory either does not exist or not writable
to webserver.
"

I don't think my local path is wrong (the file is picked from a file
dialog requester, and I tried putting the file in the root of my home
as well), so perhaps there's something wrong with the server settings?
I'm using OS X.5.5 w/ Firefox 3.0.4 (with cookies and scripts globally
accepted).
Anyway, here's what I reported:

---

Summary: SVN property changes
Description:
Some newer files didn't have SVN properties set such as svn:eol-style
and svn:keywords, the attached patch fixes this [See Files section,
properties.patch]. I've also straightened some other properties:
* Most .hpp/.h files had only Rev set while some had Rev and Id, now
all .hpp files only have Rev (none need Id).
* Most .vcproj had svn:eol-style set to native, now they all do (and I
removed svn:keywords on the few that had them).
* Some properties were set to "'Id Rev'" (note the single quotes) or
"Rev Id", these were changed to "Id Rev".

Note that some files not only had their properties changed, but also
their content. In some cases this is because a file didn't have
keywords set yet, but did use them (perhaps before in a different
branch). But in other cases the entire file is changed and this
appears to be a side-effect of setting svn:eol-style to native
(probably those that used a different line-ending than whatever my
editor uses). I surely didn't do anything but change properties
(diffing while ignoring end-of-line/whitespace changes should show this).

---

Regards,
Dimitri

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:

> Doesn't this fix the problem quite elegantly:

Indeed it does, simple&effective. I've added a note to #586.

Regards,
Dimitri

Doesn't this fix the problem quite elegantly:

http://dev.robotbattle.com/cgi-bin/viewvc.cgi/exiv2/trunk/src/value.hpp?r1=1694&\
r2=1695

Dimitri, can you please try this and confirm if it works?

(The byte order argument remains there for now so that we don't
introduce an API incompatibility at this stage.)

Andreas

Bug #586 - http://dev.robotbattle.com/bugs/view.php?id=586

On Linux in a bash shell, I just noticed that this works:

ahuggel@mowgli> exiv2 -v -M 'set Exif.Image.Model Yet another fancy
> Olympus camera' IMAGE.JPG

i.e., just hitting return inside a quoted string (single or double
quotes) and continuing on the next line.

-ahu.

> > By convention, I try to keep the properties the same for similar
files.
> > I'll have a look and clean this up.
>
> OK, if you hadn't started yet I can do it, I already had a semi-patch
> here but wanted to know beforehand what the convention is instead of
> sending another patch later on. Otherwise I'll await your changes and
> see if there's anything left for me.

I haven't started yet. Would appreciate your patch.

Thanks,
Andreas

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:

> Do you actually have a fix for this which you could share? I'd like to
> stick to the principle mentioned above, maybe by re-writing the
> ValueType<> c'tor to not use the read() member which reads from a
> binary buffer.

I figured the endianness out at the level of my own code, and then
always pass that to the Value ctor. As mentioned a default parameter
of invalidByteOrder (as opposed to littleEndian) could be used
instead, and that's what I did. Please see byteorder.patch in the
Files section.
Some notes:
* Perhaps it's better to add another enum value for ByteOrder, for
example nativeByteOrder or defaultByteOrder and use that as default
parameter instead of (in this case) misnamed invalidByteOrder.
* Big endian is currently only detected when using Apple GCC, normally
it's common for configure to handle this (and define WORDS_BIGENDIAN),
but I have no idea how to do this.
* Types.hpp shouldn't have the endianness determination, but the
exv_conf.h file should I guess (related to the configure point above).
* More cases like this and a Exiv2::GetNativeByteOrder() would be
useful, I have kept the single occurring logic in the ValueType ctor
for now.

I have run the tests before and after patching and the results were
still the same.

Regards,
Dimitri

--- In exiv2@..., "Andreas Huggel" <ahuggel@...> wrote:
>
> By convention, I try to keep the properties the same for similar files.
> I'll have a look and clean this up.

OK, if you hadn't started yet I can do it, I already had a semi-patch
here but wanted to know beforehand what the convention is instead of
sending another patch later on. Otherwise I'll await your changes and
see if there's anything left for me.

Regards,
Dimitri