[Digikam-users] unicode chars break xmp sidecars?

Sun May 18 10:25:19 BST 2014

A screenshot :

https://www.flickr.com/photos/digikam/14231704273/

Compilation and installation : 1h20 on my macbook pro. Macports
package are taken from internet through a simple WIFI connection...

It's not so long after all...

Gilles Caulier

2014-05-18 11:11 GMT+02:00 Gilles Caulier <caulier.gilles at gmail.com>:
> Fresh install of MAcports and digiKAm 4.0.0 compilation work fine.
> Look my trace here :
>
> http://digikam3rdparty.free.fr/misc.tarballs/OS%20Macports%20digiKam%204.0.0%20install.txt.gz
>
> Gilles Caulier
>
>
> 2014-05-18 9:55 GMT+02:00 Gilles Caulier <caulier.gilles at gmail.com>:
>> I currently uninstall all my Macports from my Macbook pro to see if
>> problem is reproducible...
>>
>> Gilles Caulier
>>
>> 2014-05-18 0:43 GMT+02:00 Phil <philtuckey at free.fr>:
>>> port uninstall all
>>> and then reinstall following README.MACOSX: 3.5.0 from macports runs fine
>>> but 4.0.0 has the same problem as reported below. Oh well, it's not very
>>> urgent, I can wait for 4.0.0 to show up in macports.
>>>
>>> After installing 4.0.0, it takes some messing around to get the macports
>>> 3.5.0 version working again...
>>>
>>> Philip
>>>
>>>
>>>
>>> On 17/05/14 18:38, Gilles Caulier wrote:
>>>>
>>>> Macports is configured here and compile fine. I just do a port update.
>>>>
>>>> It sound like wrong install of Qt4 (not Qt5 !!!) on your system.
>>>>
>>>> Gilles Caulier
>>>>
>>>>
>>>>
>>>> 2014-05-17 18:14 GMT+02:00 Phil <philtuckey at free.fr>:
>>>>>
>>>>> 4.0.0 compiles but won't run (MacOSX). I get the following messages:
>>>>>
>>>>> objc[85913]: Class QCocoaColorPanelDelegate is implemented in both
>>>>> /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui_debug and
>>>>> /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of
>>>>> the
>>>>> two will be used. Which one is undefined.
>>>>> ...
>>>>> QObject::moveToThread: Current thread (0x7ffefac00600) is not the
>>>>> object's
>>>>> thread (0x7ffefae532c0).
>>>>> Cannot move to target thread (0x7ffefac00600)
>>>>>
>>>>> On Mac OS X, you might be loading two sets of Qt binaries into the same
>>>>> process. Check that all plugins are compiled against the right Qt
>>>>> binaries.
>>>>> Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are
>>>>> being loaded.
>>>>> ...
>>>>> QDBusConnection: session D-Bus connection created before
>>>>> QCoreApplication.
>>>>> Application may misbehave.
>>>>> QObject: Cannot create children for a parent that is in a different
>>>>> thread.
>>>>> (Parent is Digikam::AlbumWatch(0x7ffefacdb9b0), parent's thread is
>>>>> QThread(0x7ffefae532c0), current thread is QThread(0x7ffefac00600)
>>>>> digikam(85913)/digikam (core) Digikam::AlbumWatch::connectToKDirWatch:
>>>>> KDirWatch method =  "FAM"
>>>>> QPixmap: Must construct a QApplication before a QPaintDevice
>>>>> Killed: 9
>>>>>
>>>>> I followed README.MACOSX but perhaps I misconfigured macports somehow?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>>>>> On 16/05/14 21:17, Phil wrote:
>>>>>>
>>>>>>
>>>>>> Thanks for the bug pointer Gilles. The same citation from the IPTC spec!
>>>>>> Well it is highly poetic.
>>>>>> Will test 4.0.0 when I can. Might try compiling it if I have time.
>>>>>> Philip
>>>>>>
>>>>>> On 16/05/14 07:32, Gilles Caulier wrote:
>>>>>>>
>>>>>>>
>>>>>>> With digiKam 4.0.0, just released, i fixed this entry in bugzilla :
>>>>>>>
>>>>>>> https://bugs.kde.org/show_bug.cgi?id=159220
>>>>>>>
>>>>>>> ... which is the support of UTF8 with IPTC.
>>>>>>>
>>>>>>> Please update when you can and test. If probelm still here for you,
>>>>>>> open a new file in KDE bugzilla.
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>>
>>>>>>> Gilles Caulier
>>>>>>>
>>>>>>> 2014-05-16 1:19 GMT+02:00 Phil <philtuckey at free.fr>:
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for looking Gilles. This made me think I might be causing the
>>>>>>>> problem
>>>>>>>> by something I do to my images, and I found the cause.
>>>>>>>>
>>>>>>>> The problem is triggered by setting the IPTC record CodedCharacterSet
>>>>>>>> to
>>>>>>>> UTF8. For example, with image.jpg which contains no IPTC records, run
>>>>>>>>
>>>>>>>>     exiftool -tagsfromfile @ -iptc:all -codedcharacterset=utf8
>>>>>>>> image.jpg
>>>>>>>>
>>>>>>>> This creates two IPTC records, CodedCharacterSet (= ESC % G) and
>>>>>>>> EnvelopeRecordVersion (= 4). After this, the
>>>>>>>> unicode-tag-breaking-sidecars
>>>>>>>> behaviour appears for image.jpg. (One can verify that the problem is
>>>>>>>> not
>>>>>>>> caused by the EnvelopeRecordVersion record.)
>>>>>>>>
>>>>>>>> I was lead to set IPTC:codedcharacterset=utf8 by advice in the
>>>>>>>> exiftool FAQ:
>>>>>>>>     http://www.sno.phy.queensu.ca/~phil/exiftool/faq.html#Q10
>>>>>>>> This usage appears to be consistent with the IPTC IIM specification
>>>>>>>> pointed
>>>>>>>> to from that page:
>>>>>>>>     http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf
>>>>>>>> (I quote the relevant part below.)
>>>>>>>>
>>>>>>>> So it looks like digikam should continue to write the xmp sidecars as
>>>>>>>> usual,
>>>>>>>> when this record is set to utf8. Am I missing something?
>>>>>>>>
>>>>>>>> I tried tagging such images in darktable, which I believe also uses
>>>>>>>> exiv2,
>>>>>>>> and it wrote the sidecars correctly, which suggests the problem is
>>>>>>>> specific
>>>>>>>> to digikam.
>>>>>>>>
>>>>>>>> Best Philip
>>>>>>>>
>>>>>>>>
>>>>>>>> Quote from IPTC IIM specification v.4 rev.1:
>>>>>>>> "1.90 Coded Character Set
>>>>>>>> Optional, not repeatable, up to 32 octets, consisting of one or more
>>>>>>>> control
>>>>>>>> functions used for the announcement, invocation or designation of
>>>>>>>> coded
>>>>>>>> character sets. The control functions follow the ISO 2022 standard
>>>>>>>> and may
>>>>>>>> consist of the escape control character and one or more graphic
>>>>>>>> characters.
>>>>>>>> For more details see Appendix C, the IPTC-NAA Code Library.
>>>>>>>> The control functions apply to character oriented DataSets in records
>>>>>>>> 2-6.
>>>>>>>> They also apply to record 8, unless the objectdata explicitly, or the
>>>>>>>> File
>>>>>>>> Format implicitly, defines character sets otherwise.
>>>>>>>> If this DataSet contains the designation function for Unicode in
>>>>>>>> UTF-8 then
>>>>>>>> no other announcement, designation or invocation functions are
>>>>>>>> permitted in
>>>>>>>> this DataSet or in records 2-6.
>>>>>>>> ..."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15/05/14 22:58, Gilles Caulier wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I try to reproduce to dysfuntion here (Linux) and "Café appears fine
>>>>>>>>> in sidecar file.
>>>>>>>>>
>>>>>>>>> Sound like a dysfunction from Exiv2 which is delegate to write
>>>>>>>>> sidecar
>>>>>>>>> content.
>>>>>>>>>
>>>>>>>>> Best
>>>>>>>>>
>>>>>>>>> Gilles Caulier
>>>>>>>>>
>>>>>>>>> 2014-05-15 22:02 GMT+02:00 Phil <philtuckey at free.fr>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Does anyone else see the following behaviour? If I assign a tag
>>>>>>>>>> containing a
>>>>>>>>>> (non-ascii) unicode character to an image, for example "café",
>>>>>>>>>> digikam
>>>>>>>>>> will
>>>>>>>>>> write the tag to the image file perfectly well, but fails to write
>>>>>>>>>> the
>>>>>>>>>> xmp
>>>>>>>>>> sidecar correctly. Only the first line of the sidecar is written:
>>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>>>
>>>>>>>>>> I am on OSX 10.9.2, digikam 3.5.0 (current macports).
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Digikam-users mailing list
>>>>>>>>>> Digikam-users at kde.org
>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Digikam-users mailing list
>>>>>>>>> Digikam-users at kde.org
>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Digikam-users mailing list
>>>>>>>> Digikam-users at kde.org
>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-users mailing list
>>>>>>> Digikam-users at kde.org
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> Digikam-users at kde.org
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> Digikam-users at kde.org
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> Digikam-users at kde.org
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> Digikam-users at kde.org
>>> https://mail.kde.org/mailman/listinfo/digikam-users