UTF-8 encoding of IPTC (APP13 block) data

[Claude Diderich]

I am writing IPTC (APP13 block) data using UTF-8 encoding in a separate application and then open/edit the photos in PhotoMechanic. (The application is actually used for mass editing/correcting/translating IPTC data, in addition to XMP data).

(It seems that) PhotoMechanics is interpreting the UTF-8 encoding of IPTC data (not the XMP block) only after having read the 1:090 (Coded Character Set) tag indicating that the encoding is UTF-8. As a consequence, if the 1:090 tag is added at the end of the IPTC/APP13 block, the UTF-8 encoded data is not correctly displayed in PhotoMechanis. If the 1:090 tag is the first tag (or before any UTF-8 encoded data), then PhotoMechanics correctly displays the data.

It is/was my understanding that the 1:090 encoding applies to the whole APP13 block? Is that understanding incorrect, or is this a "bug" in PhotoMechanics?

[dennis]

Yes we are expecting record 1 fields to come before record 2.  I haven't double-checked the IPTC specification about this to see if this is a requirement (I do know that record 2 fields don't need to be ordered by increasing field numbers like TIFF tags).  If the specification says record 1 fields can come after record 2 then to "fix" this we would need to make an initial pass through tags to search for record 1 UTF-8 before loading the record 2 fields.

Is there any reason you can't write the record 1 UTF-8 field before record 2?

--dennis

[Claude Diderich]

I reviewed the standard. You are right!

Chapter 3 / Section 1.1 Ordering of Records
(a) Records must be in numerical order. However, DataSets within a record need not be in numerical order, unless otherwise specified in the DataSet description.

I did not remember the first part. I have updated my app to follow the standard (write the 1:90 character set record first). But I had a hard time debugging the issue (I had initially added the 1:90 DataSet set at the end at it was the only new DataSet), especially as other apps do not seem to care and decode the UTF-8 data independent of the location of the 1:90 record.

Thanks for your prompt reply!
--Claude