[Digikam-users] unicode chars break xmp sidecars?
Phil
philtuckey at free.fr
Sun May 18 12:35:04 BST 2014
I see you do not install digikam from macports first, as README.MACOSX
says to do.
Thanks to your transcript I can see all the compile dependencies,
including the ones you thought of while you were bootstrapping... I will
work through them later on.
Nice screenshot! I see it says dk 4.1.0. I am using:
git clone git://anongit.kde.org/digikam-software-compilation ./3.x
to download the source. Should I use something else to get the same
version as you?
Thanks
Philip
On 18/05/14 11:25, Gilles Caulier wrote:
> 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
> _______________________________________________
> 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