[Digikam-users] unicode chars break xmp sidecars?
Gilles Caulier
caulier.gilles at gmail.com
Sun May 18 10:11:09 BST 2014
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
More information about the Digikam-users
mailing list