digiKam › digikam-users

unicode chars break xmp sidecars?

Classic

List

Threaded

16 messages Options

Philip Tuckey-2

unicode chars break xmp sidecars?

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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:
>> 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
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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 <[hidden email]>:
>>>
>>> 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
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:
>> 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 <[hidden email]>:
>>>>
>>>> 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
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>>
>>>>> 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
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>>
>>>>>> 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
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:
>> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]>:
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>>>
>>>>>>
>>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]>:
>>>>>>>
>>>>>>>
>>>>>>> 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 <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Digikam-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>>>
>>>>> 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 <[hidden email]>:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Digikam-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Digikam-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

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 <[hidden email]>:
>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>> 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 <[hidden email]>:
>>>>>>
>>>>>> 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 <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 <[hidden email]>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Digikam-users mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Digikam-users mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Digikam-users mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Digikam-users mailing list
>>>>>>> [hidden email]
>>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Digikam-users mailing list
>>>>>> [hidden email]
>>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>>> _______________________________________________
>>>>> Digikam-users mailing list
>>>>> [hidden email]
>>>>> https://mail.kde.org/mailman/listinfo/digikam-users
>>>>>
>>>> _______________________________________________
>>>> Digikam-users mailing list
>>>> [hidden email]
>>>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

2014-05-18 13:35 GMT+02:00 Phil <[hidden email]>:

> 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?

yes, exactly...

Gilles
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

In reply to this post by Gilles Caulier-4

Hi Gilles

Thanks again for your help.

The current code from git (i.e. 4.1.0) is working for me now.

I confirm that the problem I had with UTF8 IPTC tags and xmp sidecars is
fixed.

As I had misunderstood README.MACOSX and it is missing a couple of
dependencies, here is the full list of commands I used to install:

I first did a "sudo port -fp uninstall installed" in order to have a
fairly clean starting point. Then:

sudo port -v selfupdate
sudo port install qt4-mac
sudo port install qt4-mac-sqlite3-plugin
sudo port install kdelibs4
sudo port install kde4-baseapps
sudo port install opencv
sudo port install marble
sudo port install oxygen-icons
sudo port install sane-backends
sudo port install libgpod
sudo port install libgphoto2
sudo port install lensfun
sudo port install liblqr
sudo port install libraw
sudo port install eigen3
sudo port install mysql5
sudo port install sqlite2
git clone git://anongit.kde.org/digikam-software-compilation ./3.x
cd 3.x
./download-repos
./bootstrap.macports
cd build
make
sudo make install/fast
launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
launchctl load -w /Library/LaunchAgents/org.macports.kdecache.plist
/opt/local/bin/kbuildsycoca4

and now digikam runs.

Best Philip

On 18/05/14 11:25, Gilles Caulier wrote:

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles Caulier-4

Re: unicode chars break xmp sidecars?

2014-05-18 21:40 GMT+02:00 Phil <[hidden email]>:

> Hi Gilles
>
> Thanks again for your help.
>
> The current code from git (i.e. 4.1.0) is working for me now.
>
> I confirm that the problem I had with UTF8 IPTC tags and xmp sidecars is
> fixed.
>
> As I had misunderstood README.MACOSX and it is missing a couple of
> dependencies, here is the full list of commands I used to install:
>
> I first did a "sudo port -fp uninstall installed" in order to have a fairly
> clean starting point. Then:
>
> sudo port -v selfupdate
> sudo port install qt4-mac
> sudo port install qt4-mac-sqlite3-plugin
> sudo port install kdelibs4
> sudo port install kde4-baseapps
> sudo port install opencv
> sudo port install marble
> sudo port install oxygen-icons
> sudo port install sane-backends
> sudo port install libgpod
> sudo port install libgphoto2
> sudo port install lensfun
> sudo port install liblqr
> sudo port install libraw
> sudo port install eigen3
> sudo port install mysql5
> sudo port install sqlite2
>

Sure. All of these are already in my install script here :

https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/project/macosx/macports-install.sh

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Philip Tuckey-2

Re: unicode chars break xmp sidecars?

On 18/05/14 22:37, Gilles Caulier wrote:

> 2014-05-18 21:40 GMT+02:00 Phil <[hidden email]>:
>> Hi Gilles
>>
>> Thanks again for your help.
>>
>> The current code from git (i.e. 4.1.0) is working for me now.
>>
>> I confirm that the problem I had with UTF8 IPTC tags and xmp sidecars is
>> fixed.
>>
>> As I had misunderstood README.MACOSX and it is missing a couple of
>> dependencies, here is the full list of commands I used to install:
>>
>> I first did a "sudo port -fp uninstall installed" in order to have a fairly
>> clean starting point. Then:
>>
>> sudo port -v selfupdate
>> sudo port install qt4-mac
>> sudo port install qt4-mac-sqlite3-plugin
>> sudo port install kdelibs4
>> sudo port install kde4-baseapps
>> sudo port install opencv
>> sudo port install marble
>> sudo port install oxygen-icons
>> sudo port install sane-backends
>> sudo port install libgpod
>> sudo port install libgphoto2
>> sudo port install lensfun
>> sudo port install liblqr
>> sudo port install libraw
>> sudo port install eigen3
>> sudo port install mysql5
>> sudo port install sqlite2
>>
>
> Sure. All of these are already in my install script here :
>
> https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/master/entry/project/macosx/macports-install.sh
>
> Gilles Caulier

Ah, they were not all in the version which I downloaded yesterday...
But also they are not all in README.MACOSX, which is the file I tried to
follow for installing. I didn't even know about the directory
project/macosx until I saw your transcript this morning.

Best Philip
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users