[Digikam-devel] XMP to solve tags name and Tags Path record in pictures metadata...

[Gilles Caulier]

2007/10/1, Mikolaj Machowski <mikmach at wp.pl>:
>
> Dnia poniedziałek 01 październik 2007, Gilles Caulier napisał:
> >     xmlns:xap="http://ns.adobe.com/xap/1.0/"
> >     xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
> >     xmlns:exif="http://ns.adobe.com/exif/1.0/"
> >     xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
> >     xmlns:dc="http://purl.org/dc/elements/1.1/"
> >     xmlns:digiKam="http://www.digikam.org/"
>
> Shouldn't path be more precise?


Excepted for digikam.org, 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 (:=)))


>
> > As Xmp use UTF-8 endoding nothing is lost ! Also, the strings size are
> > not limited ! The only limitation (for JPEG only) is the JFIF APP1
> > section used to store Xmp packet wich is limited to... 64Kb (PNG chunk
> > and TIFF tag don't have this limitation.)
> >
> > Nota : With the new future Database structure, we will store certainly
> > more private informations in Xmp digiKam namespace... Marcel, we can do
> > what we want (:=))) Xmp rock...
>
> Future looks very promising :)
> >
> > But i have a question about how to save the a tag path. Currently the
> > separator is a '/'. This can be a problem if user use this character in
> > a tag name because it will break the tags tree in a future import
> > (backup/restore). If somebody has an alternative to prevent this
> > problem, let's me hear...
> >
> > Thanks in advance for you constructive remarks...
>
> Maybe some "phishing"?
>
> Unicode provides several types of slash, among them:
>
> 2044    ???     FRACTION SLASH
> 2215    ???     DIVISION SLASH


This can be fine.


Comparing to well known solidus:
>
> 002F    /       SOLIDUS
>
> Since XMP fully supports utf-8 we could use them. But there is one big
> problem (as seen above): we may be not sure if user has font with proper
> glyphs. Of course it is possible to do some display time substitute but
> with that it would be probably better to use some special sequence of
> chars, beginning eg with :: and ending with {%this is digikam tags path
> separator%} :)


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)


> Well, after a moment of thinking... why stop at phishing-like solutions?
> 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"


I love this one. It's like C++ namespace. I think it's not used with natural
languages. Someone can confirm ?


\  - I hate this Win-path look ;)


me too

|  - hmm, not bad but IMO suggests equality of terms on both sides


yes

>  - risky


yes

Feature wish: auto synchronisation of appropriate  digiKam tags with
> more common XMP schemas like DC, or IPTC Core.


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

Gilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20071001/4c2e020c/attachment.html>