GNOME Bugzilla – Bug 718107
Xmp.dc.description or Iptc.Application2.Caption is not imported with accented characters
Last modified: 2016-12-15 09:15:31 UTC
---- Reported by shotwell-maint@gnome.bugs 2011-12-31 06:49:00 -0800 ---- Original Redmine bug id: 4543 Original URL: http://redmine.yorba.org/issues/4543 Searchable id: yorba-bug-4543 Original author: Romain Gabin Original description: [note: the two fields the reporter is referring to, are, in Exiv2 parlance, Xmp.dc.description and Iptc.Application2.Caption; for whatever reason, Iptc.Application2.Headline field seems to work fine] Hello, I really like the shotwell feature if importing IPTC/XMP tags from photos and the search functionality which is very fast. However, I have noticed that if the Caption-Abstract IPTC field is not imported when accented characters are present (but they are not preventing the import on the IPTC Headline field) The shotwell version I have is the 0.11.6. I've attached two photos (the same one, with two different XMP:Description & IPTC:Caption-Abstract, modified with XnView) The "my legend" one (P1020841 Copie.JPG) is seen on shotwell nicely. The "ma légende" one is seen on shotwell with its image name: P1020841.JPG I hope this will not be too hard to correct since the problem does not exist on other fields as already written above. Have a nice year 2012 ! :) Romain ---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ---- ### History #### #1 Updated by Lucas Beeler almost 2 years ago * **Subject** changed from _XMP:Description or IPTC:Caption-Abstract is not imported if with accented characters _ to _Xmp.dc.description or Iptc.Application2.Caption is not imported with accented characters _ * **Description** updated (diff) * **Priority** changed from _Normal_ to _High_ * **Target version** set to _0.12_ #### #2 Updated by Lucas Beeler almost 2 years ago It'd be nice to fix this for 0.12 if we could. #### #3 Updated by Adam Dingle over 1 year ago * **Target version** deleted (<strike>_0.12_</strike>) #### #4 Updated by Jim Nelson 11 months ago * **Target version** set to _0.14.0_ #### #5 Updated by Jim Nelson 11 months ago * **Category** set to _metadata_ #### #6 Updated by Jim Nelson 10 months ago * **Target version** changed from _0.14.0_ to _0.15.0_ #### #7 Updated by Jim Nelson 8 months ago * **Target version** changed from _0.15.0_ to _0.16.0_ #### #8 Updated by Jim Nelson 6 months ago * **Target version** deleted (<strike>_0.16.0_</strike>) --- Bug imported by chaz@yorba.org 2013-11-25 21:55 UTC --- This bug was previously known as _bug_ 4543 at http://redmine.yorba.org/show_bug.cgi?id=4543 Imported an attachment (id=262189) Imported an attachment (id=262190) Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
retest with master
Still valid. It seems that the encoding of Iptc.Application2.Caption in the example image is not UTF-8 or UTF-16
Yes, the Iptc.Application2.Caption fails the utf-8 validation in src/util/string.vala:prepare_input_text and thus is skipped.
Created attachment 342003 [details] [review] Guess convert when UTF-8 validation fails If validation of a text is requested and it fails, try to convert from current locale if not UTF-8, otherwise fall-back to windows-1252 and iso-8859-1. Signed-off-by: Jens Georg <mail@jensge.org> The question is whether that should be done here or not and for everything. As far as I understood, only iptc might have an unclear charset if the charset code is not set in the meta-data
Attachment 342003 [details] pushed as da0e595 - Guess convert when UTF-8 validation fails