gcmd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gcmd-dev] Metatags


From: Piotr Eljasiak
Subject: Re: [gcmd-dev] Metatags
Date: Mon, 18 Sep 2006 23:06:53 +0200

On Mon, 2006-09-18 at 20:21 +0200, Magnus Stålnacke wrote: 
> > 
> > I will get back in this thread when i have done some testing.
> > 
> 
> Here comes a report of a first little testdrive.
> 
> It compiled fine, but i forgot about that gnome-autogen,
> so i had to find an old autogen.sh, then it went on.
> Where on earth do i find that "gnome-common"?

Please replace the latest autogen.sh with the previous one:
http://cvs.gnome.org/viewcvs/*checkout*/gnome-commander/autogen.sh?rev=1.3&content-type=text%2Fplain.
 This should do.

> First i did not get it, advrename looked just like
> before... Well of course, that $T(....) is supposed
> to be written in the "replace with" box i thought.
> So i tried:
> 
> Replace this: .jpg
> 
> With this: $T(Exif.DateTime).jpg
> 
> Hard crash when i hit enter, GCMD just died on me.
> I suppose it is not meant to be written like that,
> but it is not good that it crashes if the user makes
> an error like this.

Agreed, I'll take a closer look at it

> I think this advrename is in need of a help file..
> Now i did some RTFM in the usual places.. found the
> advrename text file in the source. That helped.

There is already some help for advrename. See attached screenshots.

> Tried following "Template" (would "Rule" be a
> better name?):
> 
> $N(0,3)_$T(Exif.DateTime)_$N(4)
> 
> Hey.. :-)
> It works!

:o)

> Added also a Replace-with rule to replace spaces and colons
> in the time stamp, this on two files containing Exif info.
> 
> Works fine.

:o))

> Now lets try Exif keywords on a file that exif reports
> as this:
> 
> /home/magnus/test/malmlok.jpg:
>   Tag      Name                 Type      Size  Value
>   -------- -------------------- --------- ----  -----
>   1:000    Model Version        Short        2  4
>   1:090    Coded Character Set  Binary       3  1b 25 47
>   2:000    Record Version       Short        2  4
>   2:010    Urgency              NumString    1  1
>   2:025:00 Keywords             String       4  LKAB
>   2:025:01 Keywords             String       7  malmlok
>   2:025:02 Keywords             String       4  tåg
>   2:025:03 Keywords             String       9  transport
>   2:025:04 Keywords             String       8  industri
>   2:025:05 Keywords             String       9  järnväg
>   2:080    By-line              String      17  Magnus Stålnacke
>   2:090    City                 String      10  Malmberget
>   2:092    Sub-location         String       9  Vitåfors
>   2:095    Province/State       String      10  Norrbotten
>   2:101    Country Name         String       6  Sweden
>   2:105    Headline             String      15  Repstoppet 2005
>   2:120    Caption/Abstract     String      35  Malmlok på bangården i 
> Vitåfors.

I guess it is rather IPTC, is it?

> I bet it will write all keywords, or only the first as
> filename... Yep. It used only the first one, this is
> not good. My suggestion is to use the last two digits
> in the numerical codes as option (without option = take the
> first like today), like: $T(IPTC.Keywords.03).

Good point. What about the following syntax:

        $T(IPTC.Keywords,1) = 'LKAB'
        $T(IPTC.Keywords,3) = 'transport'
        $T(IPTC.Keywords,1,4) = 'LKAB, industri'
        $T(IPTC.Keywords,4,1) = 'industri, LKAB'
        $T(IPTC.Keywords) = $T(IPTC.Keywords,0) =
        $T(IPTC.Keywords,1,2,3,4,5) = 'LKAB, malmlok, tåg, transport,
        industri, järnväg'

the same scheme (ie. for tag options) might be used for another tags,
like $T(Image.DateTime,%Y-%m-%d %H.%M.%S)

BTW - do you know other tags that can be found multiple times?

> BTW.
> Have i reported that the internal viewer IPTC does not
> handle swedish? Some months ago i had a little discussion
> with the author of libiptcdata, David Moore" about iso/utf-8,
> and he said:
> 
> "iptc _always_ uses UTF-8 internally, regardless of what your term is
> using.  It converts the input from your term's charset to UTF-8, and
> then converts the output from UTF-8 to your term's charset.  So it
> should work in both places unless something is misconfigured."
> 
> So, the data inside my jpeg should be in UTF-8, why does
> not GCMD handle it? I mean, most other Gnome-things handle
> both iso and utf just fine.

gcmd USES utf-8 for handling filenames. Current metatags code doesn't interpret 
the charset at all - so everything seems to be working with advrename... See 
attached screenshot


Piotr





reply via email to

[Prev in Thread] Current Thread [Next in Thread]