[Digikam-users] unicode chars break xmp sidecars?

[Phil]

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