Keywords and non-ascii chars

Opps

I think I've seen some messages about this before but I can't find them.

Anyway, I'm happy that I now can use non-ascii chars as keywords :clap

Unfortunately it seem that they can't be extracted from the IPTC info, for example if I have a keyword like "vårstädning" in my IPTC info, then smugmug reads it as "varstadning".

Have I missed something or is this a bug in Smugmug?

Andy

Should work fine - what image editor tool are you using? How are you uploading?

Opps

Aperture, I know that it encodes unicode in a bit "unusual" way and every time I get the iptc info I need to normalize it in some way, for example using applescript
"set c_taglist to normalize unicode p_taglist without decomposition"

I usually use smuginpro but I get the same results with MacDaddy and the web uploader (just checked)

Andy

I think aperture is messing things up. I added your keyword to a photo in Adobe Bridge, and uploaded it, and it's showing up fine:




And the url shows the utf-8 characters.

Opps

Aperture isn't really messing things up, it just uses a way of encoding chars that is a bit unusual ... but not against any rules for how to do it. I'm not sure I'm using the correct terminology here but the text needs to be "normalized without decomposition" for it to show correctly on most web apps. The same thing happens at Flickr, Wordpress etc so what I do when I use text from Aperture in an applescript is to use the line above to fix it.

Opps

And I like that you used that image ... the word means "spring cleaning"

Malte

Opps wrote:

...keyword like "vårstädning"...

You're Swedish, Opps?!

Malte

Opps

Malte wrote: »

You're Swedish, Opps?!

Malte

Jo, nog är det så:D

Boresha Photo

Opps wrote: »

Aperture, I know that it encodes unicode in a bit "unusual" way and every time I get the iptc info I need to normalize it in some way, for example using applescript
"set c_taglist to normalize unicode p_taglist without decomposition"

I usually use smuginpro but I get the same results with MacDaddy and the web uploader (just checked)

Hej kan du hjälpa mig igång med detta, jag har samma problem?

Mvh

Richard

Boresha Photo wrote: »

Hej kan du hjälpa mig igång med detta, jag har samma problem?

Mvh

Hi there and welcome to Dgrin

Not too many people here speak Swedish, but bad English is perfectly acceptable.

Here's the Google translation of the above post:

Hi can you help me start with this, I have the same problem?

Boresha Photo

Richard wrote: »

Hi there and welcome to Dgrin

Not too many people here speak Swedish, but bad English is perfectly acceptable.

Here's the Google translation of the above post:

Hi just wrote it in swedish to opps but of cause everyone that can help me with this problem are welcome to post.

And Richard I wrote this without using goggle translate :-D

Opps

Komma igång med vad? Jag är rädd för att jag inte riktigt förstår vad du menar.

(just asking what kind of help that is needed)

Opps

Richard wrote: »

Not too many people here speak Swedish

No, we're a small exclusive group

Boresha Photo

Opps wrote: »

Komma igång med vad? Jag är rädd för att jag inte riktigt förstår vad du menar.

(just asking what kind of help that is needed)

Jag tar det på Engelska så alla förstår oss.

Im new in aperture and yesterday when I sent files to our server the Ä,Ö,Å looks wrong in the IPTC core.

I understand that its something about a apple script I have to use or?

So how do I make that one and how do I use it, will it have to be every time i use Aperture 3 or is it a one time action that works in the future?

Best Regards , Vänliga Hälsningar :-)

Opps

Jäpp, this is a problem with Smugmug, all text in the caption seem to work just right - here å,ä,ö works correctly - but the tags doesn't work.

However, there seem to be one way of getting the tags there correctly but it requires extra work, if you use SmuginPro for Aperture (you should use it) then tags added within the plugin are shown correctly.

Here is an example of where I added the tag "meraåäö" in SmuginPro, the "aao" is "åäö" added in Aperture (note that I have both "åäö" and "ÅÄÖ" as tags)
http://album.mostrom.pp.se/Other/SmugShots/2011-02-0118-37-0618596/1176411863_WfKt7-L.jpg

This one is added using SmuginPro but I didn't change anything in the plugin
http://album.mostrom.pp.se/Other/SmugShots/2011-02-0118-37-0618596/1176410108_gLF8w-L.jpg

and is the same photo uploaded using the web uploader
http://album.mostrom.pp.se/Other/SmugShots/2011-02-0118-37-0618596/1176410661_TrYka-L.jpg

and finally using MacDaddy
http://album.mostrom.pp.se/Other/SmugShots/2011-02-0118-37-0618596/1176414857_Yuo8b-L.jpg

As you can see the only way to get åäö there directly is to add them when exporting using smuginpro. So I draw the conclusion that Smugmug IPTC parser can't handle the UTF-8 encoding Aperture use in the keywords field.

However, this is not something unique with Smugmug but you can see the same behavior in Wordpress blogs (except if you use NGGallery).

I would love if this could be fixed by smugmug!!

Boresha Photo

Ok I dont use smugmug but its the same problem i have sending pictures to one of my bylines.

When I use bridge its not a issue, but same file when the metadata is made in Aperture show this problem.

It was Apple support that sent me to this forum to ask for more help, be cause they don't know why it happens only that some web browsers show the information differently.

So do you know where to makes this changes to get it to work?

Opps

OK, well kind of. You can use Applescript and extract the IPTC info from Aperture and then convert the chars so most clients can read the info. I haven't tried to change the actual IPTC info (can probably be scripted using the EXIF tool), I've only sent the converted chars to MarsEdit so it ends up correctly on various web sites.

You can see the script at http://mostrom.eu/blog/2011/01/25/smugmug-smuginpro-for-aperture-easy-blogging/ and what you're looking for are the three lines

set c_title to normalize unicode p_title without decomposition
    set c_body to normalize unicode p_body without decomposition
    set c_taglist to normalize unicode p_taglist without decomposition

This is where I convert the text with the help of the Satimage OSAX plugin

Boresha Photo

Opps wrote: »

OK, well kind of. You can use Applescript and extract the IPTC info from Aperture and then convert the chars so most clients can read the info. I haven't tried to change the actual IPTC info (can probably be scripted using the EXIF tool), I've only sent the converted chars to MarsEdit so it ends up correctly on various web sites.

You can see the script at http://mostrom.eu/blog/2011/01/25/smugmug-smuginpro-for-aperture-easy-blogging/ and what you're looking for are the three lines

set c_title to normalize unicode p_title without decomposition
    set c_body to normalize unicode p_body without decomposition
    set c_taglist to normalize unicode p_taglist without decomposition

This is where I convert the text with the help of the Satimage OSAX plugin

Had a look at your blog, That looks very complicated.

So I use Aperture to export version to my drive and then send them with a ftp program.

Is there anything i can do so this issue don´t happen in my process?

Regards

Opps

That script is complicated because it does a lot more than you need

If I understand you correctly you upload your photos using FTP, then I suggest you create a custom applescript that
a) exports the files from Aperture
b) extract the meta info from Aperture
c) convert the text using "normalize unicode sometext without decomposition"
d) write back the info using EXIF tool
e) upload it to the FTP server

+ I can add a post with the script I use for a),
+ a handler for b) can be found here http://mostrom.eu/blog/2011/01/25/get-photo-info-from-aperture/,
+ c) is done as above,
+ d) I haven't tried it,
+ e) I also have a script for this using interarchy that I could add to my site

so basically what you need to figure out is d), I've already done the rest.

Boresha Photo

Opps wrote: »

That script is complicated because it does a lot more than you need

If I understand you correctly you upload your photos using FTP, then I suggest you create a custom applescript that
a) exports the files from Aperture
b) extract the meta info from Aperture
c) convert the text using "normalize unicode sometext without decomposition"
d) write back the info using EXIF tool
e) upload it to the FTP server

+ I can add a post with the script I use for a),
+ a handler for b) can be found here http://mostrom.eu/blog/2011/01/25/get-photo-info-from-aperture/,
+ c) is done as above,
+ d) I haven't tried it,
+ e) I also have a script for this using interarchy that I could add to my site

so basically what you need to figure out is d), I've already done the rest.

Im still lost be cause mac and Aperture is new to me.

But is it the Satimage OSAX plugin I need to download and in that case how do i program it?

This action how long time will it take extra to process my pictures?

Opps

Ahhh, OK, then I better go back a bit.

Applescript is a scripting language for the Mac, it differ from the scripting you do in batch files in that instead of telling different apps what to do and then wait for the result you can give control what the apps are doing step by step. The commands available in Applescript are not static, they are determined by the core language commands (if, repeat, set, etc), the commands available in a certain application (each application that definer commands that are relevant to it) and plugins installed. When you install a plugin like the Satimage OSAX you get an additional set of commands that you can use.

To see what commands an application or a plugin offers, you open the application/plugin dictionary (from within the Applescript editor) and all the commands are listed there. The Applescript syntax can be a bit confusing at first because of english-like way of writing.

Speed ... well, my experience is that the overhead of adding stuff like this is much much much less than the time it takes to export stuff from Aperture. I've got one Applescript that export three versions of each selected photo, extract the meta information, do the conversion, generates tags for inserting the images into blog posts, upload the photos to ftp server and finally generates blog posts in MarsEdit (setting title, date, keywords, body, images tags etc). I do all this using pressing one shortcut and I would say that something like 80-90% of the time is spent exporting the images from Aperture, 10-15% on uploading them and a few precent on doing the rest.

Boresha Photo

Ok now I understand

So I thing this will give my problems or?

I work as a sports photographer and on one work there is not 2 pictures with the same tag so i cant auto script all that you do.

Can you help me to write a script that fix the ä,ö,å issue only, I really like the editing in Aperture but if I cant fix this I have to go back to bridge or find alternative software.

And if this is a issue Aperture 3 generate, shut apple not think about this in a future update?

Opps

My scripts are not dependent on any tags, I just select the photos in Aperture and run my script and the selected photos are processed.

I can give you code for everything but the exiftool stuff - I would love to write this part but to be perfectly honest: I don't have the time to fix it. So I'm not going to say that I will do it - hope you understand

I've got some important deadlines regarding work + a lot of other things I've promised to do (tomorrow saturday will be the first evening I'm home since sunday )

It's difficult to say if this is a Aperture issue or not, as far as I understand they are saving the text in a perfectly valid - although "unusual" way. It seems like most web services either expect that the IPTC info is in Latin-1 encoding or in some other (also valid) way of representing characters (sorry about being vague here but I don't know Unicode well enough). Interesting examples are Smugmug which reads the caption correctly but not the tags, or wordpress which fails but the wordpress plugin NGGallery is able to read things correctly.

Boresha Photo

Hi all help are welcome, don´t stress to help me enjoy you Saturday :-)

In Aperture help I did a search on unicode and found this. sorry the long post.

"
WebObjects 5: How to Specify the Character Encoding for a Web Browser

A WebObjects application may set the character encoding used by the client Web browser so that international characters are displayed correctly.
Character encodings can be set at various places in a WebObjects application, such as string encoding for session data, XML encoding, database server encoding, or the encoding used to communicate with the client Web browser. This document only discusses the latter.

It is important to select the proper character encoding and initialize WebObjects accordingly, so that the characters of your chosen language are displayed correctly. This document discusses using Japanese characters, but this information can be used for other languages as well.

Setting the encoding inside WebObjects

UTF-8, which is a way to represent Unicode, covers a wide range of Japanese characters and allows Japanese text to be mixed with other languages (European, Asian, and so forth). Therefore, this encoding is preferred compared to other Japanese-only encodings such as Shift-JIS.

In your Application.java file, override two methods, takeValuesFromRequest() and appendToResponse() to specify the proper encoding (UTF-8 is used as an example here). The method appendToResponse() also sets the proper encoding in each WOResponse header.
public void takeValuesFromRequest(WORequest r, WOContext c) {
r.setDefaultFormValueEncoding("UTF8");
super.takeValuesFromRequest(r,c);
}

public void appendToResponse(WOResponse r, WOContext c) {
r.setContentEncoding("UTF8");
super.appendToResponse(r,c);
r.setHeader("text/html;charset=utf-8", "Content-Type");
}

See Sun's encoding documentation (http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html) to determine the correct encoding for your environment.

Example: Resolving a browser display problem when using Shift_JIS (JIS X0208:1997)
Problem description: Web browser does not display correctly the vendor specific characters
Encoding used: Shift_JIS

Solution:

1. Windows-31J is the correct character set for displaying the vendor specific characters.

2. Modify the character encoding to "MS932", Windows Japanese.

3. The request header should be set to ("text/html;charset=Windows-31J", "Content-Type")

Code example:
public void takeValuesFromRequest(WORequest r, WOContext c) {
r.setDefaultFormValueEncoding("MS932");
super.takeValuesFromRequest(r,c);
}

public void appendToResponse(WOResponse r, WOContext c) {
r.setContentEncoding("MS932");
super.appendToResponse(r,c);
r.setHeader("text/html;charset=Windows-31J", "Content-Type");
}


For more information, see:

Microsoft Windows Codepage : 932 (Japanese Shift-JIS)
<http://www.microsoft.com/globaldev/reference/dbcs/932.htm?&gssnb=1&gt;

Mapping Differences Between JIS X 0221 and Code Page 932
<http://support.microsoft.com/default.aspx?kbid=286776&gt;

Windows31-J and other character sets
<http://www.iana.org/assignments/character-sets&gt;

Important: On Mac OS X, Internet Explorer may not display the Japanese characters correctly even with the MS932 encoding. Use Safari 1.0 or later instead.

Note: Mention of third-party websites and products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance or use of information or products found at third-party websites. Apple provides this only as a convenience to our users. Apple has not tested the information found on these sites and makes no representations regarding its accuracy or reliability. There are dangers inherent in the use of any information or products found on the Internet, and Apple assumes no responsibility in this regard. Please understand that a third-party site is independent from Apple and that Apple has no control over the content on that website.

Document 17159: "Locating Vendor Information" can help you search for a particular vendor's address and phone number.
Article ID: TA21331 Date Modified: 2003-10-01
"

You think this can have something to do with the issue we have with the swedish letters?

Opps

I don't think so, the problem is probably this (if I guess correctly):

Canonical equivalence is a form of equivalence that preserves visually and functionally equivalent characters. For example, precomposed diacritic letters are considered canonically equivalent to their decomposed letter and combining diacritic marks. In other words, the precomposed character ‘ü’ is a canonical equivalent to the sequence ‘u’ and ‘¨’ a combining diaeresis. Similarly, Unicode unifies several Greek diacritics and punctuation characters that have the same appearance as other diacritics

from this page http://en.wikipedia.org/wiki/Unicode_equivalence

If I guess correctly Aperture stores an "ö" as 'o' + '¨' while many programs expect the precomposed form 'ö' - but as I said, I'm just guessing.

Boresha Photo

Ok sounds right, I will sent this post back to apple and hear what they have to say.

If Aperture do as you say and it looks like it, Ö becomes O" or OL in my files.

The fun part is just that when I look in Aperture the letters looks right, the issue is after I sent the files.

Be cause even if I open the version file as a new project the Iptc core is ok.

frax

Tjenare!
Fick du ÅÄÖ att funka?

Hi there!
Did u get ÅÄÖ to work?

Opps

Nä, jag har inte haft tid att göra något.

(No, I haven't had the time to do anything)