<br><br><div><span class="gmail_quote">2007/10/1, Mikolaj Machowski <<a href="mailto:mikmach@wp.pl">mikmach@wp.pl</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:<br>>     xmlns:xap="<a href="http://ns.adobe.com/xap/1.0/">http://ns.adobe.com/xap/1.0/</a>"<br>>     xmlns:tiff="<a href="http://ns.adobe.com/tiff/1.0/">

http://ns.adobe.com/tiff/1.0/</a>"<br>>     xmlns:exif="<a href="http://ns.adobe.com/exif/1.0/">http://ns.adobe.com/exif/1.0/</a>"<br>>     xmlns:photoshop="<a href="http://ns.adobe.com/photoshop/1.0/">

http://ns.adobe.com/photoshop/1.0/</a>"<br>>     xmlns:dc="<a href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a>"<br>>     xmlns:digiKam="<a href="http://www.digikam.org/">

http://www.digikam.org/</a>"<br><br>Shouldn't path be more precise?</blockquote><div><br>Excepted for <a href="http://digikam.org">digikam.org</a>, where we can host a dedicaced page where users can found the descrition of the provate schema, all others are official and provided by specifications from adobe. For all request please mail to Adobe support (:=)))

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> As Xmp use UTF-8 endoding nothing is lost ! Also, the strings size are

<br>> not limited ! The only limitation (for JPEG only) is the JFIF APP1<br>> section used to store Xmp packet wich is limited to... 64Kb (PNG chunk<br>> and TIFF tag don't have this limitation.)<br>><br>> Nota : With the new future Database structure, we will store certainly

<br>> more private informations in Xmp digiKam namespace... Marcel, we can do<br>> what we want (:=))) Xmp rock...<br><br>Future looks very promising :)<br>><br>> But i have a question about how to save the a tag path. Currently the

<br>> separator is a '/'. This can be a problem if user use this character in<br>> a tag name because it will break the tags tree in a future import<br>> (backup/restore). If somebody has an alternative to prevent this

<br>> problem, let's me hear...<br>><br>> Thanks in advance for you constructive remarks...<br><br>Maybe some "phishing"?<br><br>Unicode provides several types of slash, among them:<br><br>2044    ???     FRACTION SLASH

<br>2215    ???     DIVISION SLASH</blockquote><div><br>This can be fine.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Comparing to well known solidus:

<br><br>002F    /       SOLIDUS<br><br>Since XMP fully supports utf-8 we could use them. But there is one big<br>problem (as seen above): we may be not sure if user has font with proper<br>glyphs. Of course it is possible to do some display time substitute but

<br>with that it would be probably better to use some special sequence of<br>chars, beginning eg with :: and ending with {%this is digikam tags path<br>separator%} :)</blockquote><div><br>no; the separator is never displayed somewhere in digiKam it used internally to "separate" all branches of the Tags Album treeview. In fact the right separator char must be used to not be confused with the real text (Tag names)

<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Well, after a moment of thinking... why stop at phishing-like solutions?<br>Just use real arrows:

279D    ???     TRIANGLE-HEADED RIGHTWARDS ARROW I put it in some random string in libksirtet.po and works quite nice on my system.  While I am working on KDE from SVN (3.5 branch), and Qt 3.4.3 the rest of my system is 2 years old - including fonts.

If you prefer good old ASCII: :: - geek friendly, may be not so understandable for "masses"</blockquote><div> I love this one. It's like C++ namespace. I think it's not used with natural languages. Someone can confirm ?

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">\  - I hate this Win-path look ;)</blockquote><div><br>me too <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

|  - hmm, not bad but IMO suggests equality of terms on both sides</blockquote><div><br>yes <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

>  - risky</blockquote><div><br>yes <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Feature wish: auto synchronisation of appropriate  digiKam tags with

more common XMP schemas like DC, or IPTC Core.</blockquote><div> Already don in svn (:=))) Just missing 2 methods to sync Exif/Iptc with Xmp, because Xmp can host all standard Exif/Iptc tags. The only tags witch cann ot be sync is makernote. A possible solution is to host markernotes byte array as binary string in a dedicaced Xmp tag. but it doesn't exist in norm. The way to save markernot in Xmp is important, especially with TIFF file format. libtiff is weird to handle/manage all Exif tags. When we convert a RAW file to TIFF, all Exif/Markernotes tags diseapear. Until than Exiv2 support tiff writing mode, this can be an alternative...

<br><br>Gilles</div></div><br>