[Digikam-users] unicode chars break xmp sidecars?

Sat May 17 23:43:51 BST 2014

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
>