I know it's a minor detail, so thankyou for your patience! late night isn't always the best moment to realize things: I have not the xmpMetadata plugin enabled, nevertheless I have the same result with 2 different images and sets of data.
I'll think about while going to venice today, have a nice day
I've been stuck into this for the past 2 days but now I think I'm going a step forward. I couldn't understand wether the problem was/is in the tool (xnview), the cms (zenphoto) or eventually on my side (unproper use of the two), so I've just downloaded and used another tool specific for managing metadata.
as I'm not so confortable with command lines I ended up to use photome (www.photome.de).
I've downloaded the test photo file (the same linked above: http://www.indirizzofantasma.net/zenphoto/albums/numeri-civici/69/0069.jpg = the uploaded original file, with IPTC & EXIF) and inspecting it with photome I get the following:
[IPTC-NAA data (IIM)]
Keyword: finestrata
Content Location Name: Cannaregio
Creator: Richard Khoury
City: Venezia
Location: calle priuli ai cavaleti
Province/State: VE
Country: Italia
Headline: 69
So the lost data/field was/is there!
Maybe can help as additional information of the field which wasn't seen by zenphoto:
Content Location Name: Cannaregio - Tag-ID: 2:027 - Tag Name: ContentLocationName
At this point I guess the bug is more likely into zenphoto and I hope you can check if I'm wrong...
ah, well, after a week and more of struggling now that makes sense, although I see it as an arbitrary limitation - doesn't matter what adobe says.
also what you suggest unluckily is not a workable solution for me, as those fields are already used, besides I should change records to hundreds of files.
I'm currently trying to work it out (trial&error system) to tweak the field I need to retrieve with another that zenphoto processes in zp-core/functions.php (yes, I know I shoudn't touch core files, but whenever I'll update zp I can re-tweak those files: I don't see any other chance now).
I also know it's a naive way to code, so if anyone can help is welcome...
e.g.
'IPTCOriginatingProgram' => array('IPTC', 'OriginatingProgram', gettext('Originating Program), false, 32),
change to
'IPTCContentLocName' => array('IPTC','ContentLocName', gettext('Conten Location Name - hacked), true, 32),
- don't shoot me I'm only the photographer -
downloaded the last nightly build and tried to reupload its zp-core/functions.php in my installation...
obviously it wasn't possible so I went back to the previous functions.php which I've edited by adding the 2 new lines with no visible effect
(btw - the 2 lines are different from all others in that table, having 1 more [i]false/true[/i] field at the end - is it normal?)
however I've also succesfully sorted the order in a different way.
Quote:place where the IPTC data is processed.
but I don't know where or what to edit
and also I lack knowledge on how to correctly run again a setup - I'll look for info and eventually post in another thread.
apart of all this everything is fine and I see the light at the end of tunnel...
You cannot mix and match files. Install the complete development build. Anyway, this change will not be placed into the 1.4.2 stream since it requires database changes in order to save the new data.
So it is up to you. Use the development build or work aroung the use of those fields. Just FYI, all the documentation I can find on the fields indicates that they are unique to a particular software. So my suggestion for portability is to use the "standard" fields. But of course that is up to you.
I see... I wasn't aware of the fact that those fields weren't "standard": learning is a never ending process...
I might well consider to change pattern in the future. thankyou for the information.
about the installing of the complete development build, this is a completely new issue: obviously I'm afraid to mess up the database and all the work done, but if I decide to reinstall and everything goes well from my side, will my issue be definitely solved?
I believe so. It does work for me with the image you posted. Of course, it does not solve any other application incompatibilities with that field. But it will at least show up in Zenphoto.
The development build is fairly mature, but still a work in process. So it would be a good idea if you could install a test site first to confirm it works for you. It does work for me: www.sbillard.org is running the development build.
the development build installation was succesful, I've set the same customized theme and the wanted field happily shows.
but as murphy says: every solution generates new problems, now the embedded keyword doesn't show anymore as a tag - in the previous installation the tags were directly generated from the embedded keywords (and for some unknown reason the [i]keyword[/i] checklist was greyed out in the image options). I hope it's a minor problem.
here http://www.indirizzofantasma.net/gallery/test/0069.jpg.php
The Keywords element in the field list selections should let you choose either "hide" or "do not process". "Show" is not available because of how the field is stored in the metadata. But if you have selected "hide" the keywords will be imported as Zenphoto tags. In your case the image is tagged with [i]finestrat[/i]
There was a time when the Kewords field was totally disabled. If that is the case for you, get the current nightly build version. (As said, this is still a work in process.)
in my previous installation -though it was not so long time ago- the keywords were smoothlessly imported as tags, as you say.
now I simply can't select between "show" and "hide", they're both greyed out, and the "don't process" checkbox once selected can't be unchecked anymore (I had to go back to previous page without applying changes in order to uncheck it).
I've also tested it applying the "don't process" option, and of course nothing changed.
I'll try to reinstall...
Tags are NOT part of the metadata display as said (thus the show is not enabled.) You can use one of the Zenphoto function printTags() to show tags. Also you will have to refresh the image metadata since when it was first processed the Keywords metadata was set to dont process`.
I suspect you should get a better image metadata handling program. Your Keywords are in XMP and the rest of your data is IPTC. Really no reasonable application should mix these two--that just causes this kind of confusion.
Enable the XMP metadata plugin and set its options to process jpg images.
if it's there, the xmp mixing is not due to the tool I use.
at the time of your answer there was already online another test image with no xmp data http://www.indirizzofantasma.net/gallery/test/0069_noxmp_v2.jpg.php, still the keyword is there and it's written in its iptc field, not retrieved.
moreover zenphoto was/is working well with keywords handling in the installation with 1.4.1.6 [8326] build.
http://www.indirizzofantasma.net/zenphoto/numeri-civici/69/0069_noxmp_v2.jpg.phphttp://www.indirizzofantasma.net/
same photo/file, same php file and functions, same admin options (except for the new checklist), but different output.
@kyrd: I asume you expect tags on the right sidebar. Since that reads "No popular tags" you probably use the tag statistics function. If you have no popular tags those are of course not displayed (when they are is a matter of the options of that function). The functions for individual tags are completly different ones.
You are using a customized Zenage theme so you perhaps changed something wrong?
Just FYI this is the image you provided: http://testalbum.sbillard.org/index.php?album=xyzzy&image=0000.jpg complete with your content location and teh "finestrata" tag.
