| Summary: | All displays of the same caption don't show the same text when it contains éèà... | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | mahikeulbody |
| Component: | Metadata-Iptc | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.10.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.0.0 | |
| Sentry Crash Report: | |||
| Attachments: | an image to illustrare the problem | ||
|
Description
mahikeulbody
2009-04-18 16:58:08 UTC
Can you add your picture in this file to test ? Gilles Caulier I can confirm this bug as iso-8859-2 user even don't seeing image in question. I have tons of my own examples :) In some part bug is invalid: as advertised in numerous places in metadata plugins IPTC supports only us-ascii subset of characters. And eacute isn't in this subset. But: Metadata Working Group in latest version of guidelines http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf pages 27-28 writes: 1. Program should honor encoding set in 1:90 field 2. If 1:90 is not set assume: utf-8 or local encoding (in this order) 3. When changing string it should be recoded to utf-8 and field 1:90 should be updated. 4. Newly created strings in IPTC-IIM should be in utf-8 Ad 4: if I understand text properly IPTC-IIM is considered deprecated and if possible new content for IPTC-IIM fields shouldn't be created at all - use XMP instead. Created attachment 32910 [details]
an image to illustrare the problem
(In reply to comment #2) > I can confirm this bug as iso-8859-2 user even don't seeing image in question. > I have tons of my own examples :) > > In some part bug is invalid: as advertised in numerous places in metadata > plugins IPTC supports only us-ascii subset of characters. And eacute isn't in > this subset. Anyway, Digikam should display the same string in all places of the GUI: either "soir?e" either "soirée", but everywhere. To mik,
>Ad 4: if I understand text properly IPTC-IIM is considered deprecated and if
>possible new content for IPTC-IIM fields shouldn't be created at all - use XMP
>instead.
yes, IPTC is obsolete now...
Gilles
(In reply to comment #5) > To mik, > > >Ad 4: if I understand text properly IPTC-IIM is considered deprecated and if > >possible new content for IPTC-IIM fields shouldn't be created at all - use XMP > >instead. > > yes, IPTC is obsolete now... Is there a way to sync xmp tag from iptc tag of a set existing images (a batch tool) ? Mik, Using image provided by mahikeulbody, I find why iptc caption is not the same with accentuate chars. It's in libkexiv2. Look code there : http://lxr.kde.org/source/KDE/kdegraphics/libs/libkexiv2/libkexiv2/kexiv2iptc.cpp#164 This line is used to fill metadata list view from digiKam right sidebar. QString::fromAscii() is used to convert string data from Exiv2 byte array to QString. http://lxr.kde.org/source/KDE/kdegraphics/libs/libkexiv2/libkexiv2/kexiv2iptc.cpp#333 ...and this one by IPTC editor from kipi-plugins. QString::fromLocal8Bit() is used to convert string data from Exiv2 byte array to QString. Gilles Caulier SVN commit 980383 by cgilles: IPTC key => QString::fromLocal8bits() IPTC val => QString::fromAscii() CCBUGS: 189979 M +4 -4 kexiv2iptc.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=980383 with my commit #980383 this file is now fixed. string is the same everywhere... Gilles Caulier |