[Digikam-devel] [Bug 132244] New: Special Chars in Keywords decode wrong in IPTC

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         
           Summary: Special Chars in Keywords decode wrong in IPTC
           Product: digikam
           Version: 0.9.0-beta1
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: johann-nikolaus.andreae nacs de


Version:           0.9.0-beta1 (using KDE 3.5.4 Level "a" , unofficial build of SUSE )
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.16.21-0.13-default

If i view the IPTC keywords in the IPTC-tab the german spacial word are decode wrong. For the other IPTC-field i have it not testet.
The keywords are insert by the tag function from digikam.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles free fr  2006-08-17 00:26 -------
This is not a problem with digiKam. In fact IPTC metadata is limited to ASCII charactors !

This problem will be fixed when Exiv2 library will support XMP metadata witch support UTF8.

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Metadata
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles free fr  2006-10-04 10:12 -------
SVN commit 592268 by cgilles:

digikam from trunk : strings from Exiv2 to render metadata content are ascii, not local 8 bits formated. If we use a linux dist using UTF8 encoding (like Suse 10.1 for ex.), some characters can be wrongly decoded.

CCBUGS: 132244

 M  +7 -7      exifwidget.cpp  
 M  +7 -7      gpswidget.cpp  
 M  +7 -7      iptcwidget.cpp  
 M  +7 -7      makernotewidget.cpp  


--- trunk/extragear/graphics/digikam/libs/widgets/metadata/exifwidget.cpp #592267:592268
 @ -149,7 +149,7  @
 
         for (Exiv2::ExifData::iterator md = exifData.begin(); md != exifData.end(); ++md)
         {
-            QString key = QString::fromLocal8Bit(md->key().c_str());
+            QString key = QString::fromAscii(md->key().c_str());
 
             // Decode the tag value with a user friendly output.
             QString tagValue;
 @ -161,7 +161,7  @
             {
                 std::ostringstream os;
                 os << *md;
-                tagValue = QString::fromLocal8Bit(os.str().c_str());
+                tagValue = QString::fromAscii(os.str().c_str());
             }
             tagValue.replace("\n", " ");
 
 @ -178,7 +178,7  @
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot parse EXIF metadata using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return false;
     }
 @ -203,12 +203,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag title using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("Unknow");
     }
 @ -220,12 +220,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag description using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("No description available");
     }
--- trunk/extragear/graphics/digikam/libs/widgets/metadata/gpswidget.cpp #592267:592268
 @ -275,12 +275,12  @
 
         for (Exiv2::ExifData::iterator md = exifData.begin(); md != exifData.end(); ++md)
         {
-            QString key = QString::fromLocal8Bit(md->key().c_str());
+            QString key = QString::fromAscii(md->key().c_str());
 
             // Decode the tag value with a user friendly output.
             std::ostringstream os;
             os << *md;
-            QString tagValue = QString::fromLocal8Bit(os.str().c_str());
+            QString tagValue = QString::fromAscii(os.str().c_str());
             
             // We apply a filter to get only standard Exif tags, not maker notes.
             if (d->keysFilter.contains(key.section(".", 1, 1)))
 @ -309,7 +309,7  @
         d->detailsButton->setEnabled(false);
         d->detailsCombo->setEnabled(false);
         kdDebug() << "Cannot parse EXIF metadata using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return false;
     }
 @ -334,12 +334,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag title using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("Unknow");
     }
 @ -351,12 +351,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {  
         kdDebug() << "Cannot get metadata tag description using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("No description available");
     }
--- trunk/extragear/graphics/digikam/libs/widgets/metadata/iptcwidget.cpp #592267:592268
 @ -126,12 +126,12  @
 
         for (Exiv2::IptcData::iterator md = iptcData.begin(); md != iptcData.end(); ++md)
         {
-            QString key = QString::fromLocal8Bit(md->key().c_str());
+            QString key = QString::fromAscii(md->key().c_str());
             
             // Decode the tag value with a user friendly output.
             std::ostringstream os;
             os << *md;
-            QString value = QString::fromLocal8Bit(os.str().c_str());
+            QString value = QString::fromAscii(os.str().c_str());
             // To make a string just on one line.
             value.replace("\n", " ");
 
 @ -157,7 +157,7  @
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot parse IPTC metadata using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return false;
     }
 @ -181,12 +181,12  @
     {
         std::string iptckey(key.ascii());
         Exiv2::IptcKey ik(iptckey);
-        return QString::fromLocal8Bit( Exiv2::IptcDataSets::dataSetTitle(ik.tag(), ik.record()) );
+        return QString::fromAscii( Exiv2::IptcDataSets::dataSetTitle(ik.tag(), ik.record()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag title using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("Unknow");
     }
 @ -198,12 +198,12  @
     {
         std::string iptckey(key.ascii());
         Exiv2::IptcKey ik(iptckey);
-        return QString::fromLocal8Bit( Exiv2::IptcDataSets::dataSetDesc(ik.tag(), ik.record()) );
+        return QString::fromAscii( Exiv2::IptcDataSets::dataSetDesc(ik.tag(), ik.record()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag description using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("No description available");
     }
--- trunk/extragear/graphics/digikam/libs/widgets/metadata/makernotewidget.cpp #592267:592268
 @ -175,12 +175,12  @
 
         for (Exiv2::ExifData::iterator md = exifData.begin(); md != exifData.end(); ++md)
         {
-            QString key = QString::fromLocal8Bit(md->key().c_str());
+            QString key = QString::fromAscii(md->key().c_str());
             
             // Decode the tag value with a user friendly output.
             std::ostringstream os;
             os << *md;
-            QString value = QString::fromLocal8Bit(os.str().c_str());
+            QString value = QString::fromAscii(os.str().c_str());
             value.replace("\n", " ");
 
             // We apply a filter to get only standard Exif tags, not maker notes.
 @ -196,7 +196,7  @
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot parse MAKERNOTE metadata using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return false;
     }
 @ -220,12 +220,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagTitle(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag title using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("Unknow");
     }
 @ -237,12 +237,12  @
     {
         std::string exifkey(key.ascii());
         Exiv2::ExifKey ek(exifkey);
-        return QString::fromLocal8Bit( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
+        return QString::fromAscii( Exiv2::ExifTags::tagDesc(ek.tag(), ek.ifdId()) );
     }
     catch (Exiv2::Error& e)
     {
         kdDebug() << "Cannot get metadata tag description using Exiv2 ("
-                  << QString::fromLocal8Bit(e.what().c_str())
+                  << QString::fromAscii(e.what().c_str())
                   << ")" << endl;
         return i18n("No description available");
     }
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles free fr  2006-10-04 10:17 -------
Johann, please checkout current implementation from svn (not 0.9.0-beta2), and let's me hear is this commit have solved your problem.

Note: my comments #1 still right. UTF8 is not supported by IPTC. If an application try to embed UFT8 string in an IPTC tags, well the IPTC specification is not respected. Look here:

http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf

The alternative is to use XMP metadata instead.

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Loïc Brarda-2]

2006/10/4, Gilles Caulier <[hidden email]>:

> Note: my comments #1 still right. UTF8 is not supported by IPTC. If an application try to embed UFT8 string in an IPTC tags, well the IPTC specification is not respected. Look here:
>
> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf
>

For me, it's not that clear in the specification.

The character set can be defined in the envelop record (dataset 1:90)
which is normaly not used (as I understand the specs, the whole spec
was made to encapsulate picture in IIMV file, not encapsulate IOTC
infos in picture files).

Other specification sections let me think UTF8 is possible :

"Section 1.12 DataSet octet sizes do not imply character sizing. The number of
characters will depend on the encoding method specified. The number of octets
specified within a DataSet Data Field Octet Count will always be equal
to or greater
than the number of characters of data represented."

There is also the definition of UTF8 in Section 1.75.

The more standard way should probably be using a record 1 with a 1:90
dataset to define UTF8 but I think most programs just use UTF8
directly in the text fields.

After  some googling, I found the following page
(http://bugs.php.net/bug.php?id=27238) with links with files with
Record1 charset info but unfortunatly, the links are broken.
I found also some links with IPTC software showing their UTF8 support.

I'll try to do some tests with differents IPTC writing software.

   Loic
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Loïc Brarda-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From loic.brarda21 fnac net  2006-10-04 13:24 -------
2006/10/4, Gilles Caulier <caulier.gilles free fr>:

> Note: my comments #1 still right. UTF8 is not supported by IPTC. If an application try to embed UFT8 string in an IPTC tags, well the IPTC specification is not respected. Look here:
>
> http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf
>


For me, it's not that clear in the specification.

The character set can be defined in the envelop record (dataset 1:90)
which is normaly not used (as I understand the specs, the whole spec
was made to encapsulate picture in IIMV file, not encapsulate IOTC
infos in picture files).

Other specification sections let me think UTF8 is possible :

"Section 1.12 DataSet octet sizes do not imply character sizing. The number of
characters will depend on the encoding method specified. The number of octets
specified within a DataSet Data Field Octet Count will always be equal
to or greater
than the number of characters of data represented."

There is also the definition of UTF8 in Section 1.75.

The more standard way should probably be using a record 1 with a 1:90
dataset to define UTF8 but I think most programs just use UTF8
directly in the text fields.

After  some googling, I found the following page
(http://bugs.php.net/bug.php?id=27238) with links with files with
Record1 charset info but unfortunatly, the links are broken.
I found also some links with IPTC software showing their UTF8 support.

I'll try to do some tests with differents IPTC writing software.

   Loic
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahuggel gmx net



------- Additional Comments From caulier.gilles free fr  2006-10-04 13:30 -------
Thanks for this report Loic.

Andreas, you have a better experience with IPTC than me. Can you confirm that we can use UTF8 encoding in IPTC text tags using Exiv2 library ?

Thanks in advance

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Loïc Brarda]

2006/10/4, Gilles Caulier <[hidden email]>:
> Thanks for this report Loic.
>
> Andreas, you have a better experience with IPTC than me. Can you confirm that we can use UTF8 encoding in IPTC text tags using Exiv2 library ?
>

I must add that the specification is really not clear on that point.
I've read somewhere that it was probably writen in english by some
japanese lawer. The other point is that all program use IPTC in a way
that was not forseen by the specification. That's a real pitty that
the last IIMV specification did not took into account that real use of
the Record 2, first by adobe followed by many others.

XMP is well defined but having a look of recent photoshop jpeg, it
takes too much space in the file (lot of redundant infos, spaces, ...)
: the XMP part of one of the IPTC-XMP examples is 7.5 kb long. The IIM
part is 972 bytes long.

   Loic
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From cmaessen casco demon nl  2006-12-02 22:42 -------
Created an attachment (id=18756)
 --> (http://bugs.kde.org/attachment.cgi?id=18756&action=view)
screenshot metadata sidebar

As I understand above discussion, the screenshot I added is all about that
problem. I noticed this behaviour before, and decided to change the
copyrightnotice into (C)... But in the IPTC-documents I read that in Europe it
is probably best for juridical reasons to use the copyrightsign. So I changed
it back for all my fotographs with the use of the exiv2 commandline-tool.
Within digiKam this leads to the accompanying result. What I mean to say is
that apparantly the IPTC (needs to) accept(s) this kind of characters.

Caspar.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From ahuggel gmx net  2006-12-03 05:53 -------
Gilles,

Regarding the patch above, digikam code needs to distinguish between metadata (data stored as tag values) and text that comes from exiv2 (tag titles, descriptions, error messages, etc). Metadata is encoded according to whatever the relevant (Exif or IPTC) standard defines, possibly different for different tags (Exif user comment has its own charset setting for example). Text from exiv2 is currently in ASCII only but when we support gettext, that will change.
 
What character set do the translation files use?

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From ahuggel gmx net  2006-12-03 06:36 -------
To the question in comment #5: You can store any data in the tags, exiv2 usually doesn't care. But I don't know whether storing UTF8 encoded text in IPTC fields is ok and how it should be done to comply with the standard. Forwarded the question to the exiv2 list.

-ahu.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles kdemail net  2006-12-03 08:38 -------
Andreas,

Since we have implemented NLS support in Exiv2, the code patched in #2 is obsolete. In current implementation, i use QString::fromLocal8Bit() when its require. There is a digiKam screenshot with non-ascii characters (French) at this url:

http://digikam3rdparty.free.fr/Screenshots/dgikam_metadata_tags_i18n.png

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles kdemail net  2006-12-12 13:57 -------
Andreas,

Look this page :

http://peccatte.karefil.com/Software/Metadata.htm#IPTC

sorry it's in French...but it's very instructive. I have never seen an English page about Extended char with IPTC (UTF-8 like). Especiall, there is a section witch said :

« Le modèle IPTC-NAA permet de coder les champs selon divers jeux de caractères étendus. Les logiciels actuels devraient donc être capables de gérer correctement les accents, les signes diacritiques, etc. Il n'en est rien - si l'on utilise des caractères étendus lors de la saisie des informations dans Photoshop par exemple, ces informations ne sont pas correctement affichées sur une autre plate-forme. Adobe préconise de n'utiliser que l'ASCII 7 bits [ce qui est inacceptable pour beaucoup de langues!] parce que le standard IPTC n'autorise que ce jeu de caractères [ce qui est faux!] »

To resume, IPTC can support extended char set but because Photoshop only support ASCII 7bits char (with IPTC, not XMP), all others applications must only support this mode.

If you look into IPTC spec page 20, the tag Iptc.Envelope.CharacterSet is designed for personalize char encoding

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From ahuggel gmx net  2006-12-29 14:15 -------
On Thursday 28 December 2006 23:37, Marco Piovanelli wrote:

>     yes, the IPTC standard does allow for non-ASCII
>     character sets, although it's by no means obvious how these
>     are specified.  See for instance Stefano Bettelli's excellent
>     description of JPEG metadata on CPAN for a brief discussion of
>     this:
>
><http://www.annocpan.org/~BETTELLI/Image-MetaData-JPEG-0.15/lib/Image/MetaData/JPEG/TagLists.pod>
>
>     In particular, you can safely assume IPTC strings are
> UTF-8-encoded if the "Iptc.Envelope.CharacterSet" dataset contains
> the three-byte escape sequence "\x1B%G".

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles kdemail net  2007-01-02 21:33 -------
Thanks for the url Andreas.

I will trying to use it and check the interoperability with Photoshop...

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Dotan Cohen-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From kde dotancohen com  2007-01-17 20:51 -------
Created an attachment (id=19315)
 --> (http://bugs.kde.org/attachment.cgi?id=19315&action=view)
JPG image with Hebrew IPTC info. In all fields is the word שלום

This image was tagged with IPTC data on BrilliantPhoto on Windows. In the
following fields is the following info:
Caption:שלום
Keywords:מפתח, שלום
People:אתי, שלום
Event:שלום
Place:שלום

The data is in UTF-8. Note that multiple Keywords and People are seperated by a
comma and a space.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Dotan Cohen-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From kde dotancohen com  2007-01-17 20:53 -------
Created an attachment (id=19316)
 --> (http://bugs.kde.org/attachment.cgi?id=19316&action=view)
JPG image with English IPTC data.

This image was tagged with IPTC data on BrilliantPhoto on Windows. In the
following fields is the following info:
Caption:Caption
Keywords:Keyword1, Keyword2
People:Person1, Person2
Event:Event
Place:Place

The data is UTF-8. This and the previous attachment were added at the request
of Gilles on the Digikam mailing list.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From caulier.gilles kdemail net  2007-01-19 07:52 -------
Dotan,

Is BrilliantPhoto can configure the char-set encoding used with IPTC ? Are you a screenshot of setup ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Dotan Cohen-2]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132244         




------- Additional Comments From kde dotancohen com  2007-01-19 12:55 -------
BrilliantPhoto has absolutly no setup screen. There are no configurable options, and therefore no Preferences nor Options dialogs. That's actually one of the things that I _don't_ like about it, but otherwise it was a great program.

Acording to the BrilliantPhoto forums, which have since been taken down, the IPTC spec specifically requires the use of UTF-8 for the data. No other charset is acceptable. I read the spec a long time ago and in my opinion that 'fact' is debateable. However, the BrilliantPhoto author was very certain that only UTF-8 is allowed.

If you have a Windows virtual machine, I'd very much recommend downloading and trying BrilliantPhoto:
http://www.download.com/BrilliantPhoto/3000-2204_4-10326351.html

Digikam could learn quite a few things from BP, such as the wonderfull "fill flash" feature, which brightens underexposed photos better than any other program I've yet seen. The red-eye reduction selector is ROUND, like EYES, so they affect less skin. Why does no other program do that? Should I continue to list BP's other great features?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel