Awesome hint… hits the nail on the head! The "faulty" version (i.e. the one not appearing in the PDF with Minion Pro) is<dotlessi><acuteaccent> (where<acuteaccent> appears to translate to CC81 in hex, correct?).
Yes. Useful site for find out stuff like that without having to do utf-8 calculations yourself:
http://www.decodeunicode.org/en/u+0301/properties
At the top right, it has numerical values for the current character in various encodings.
This page looks great. Jotted down for later reading ;-)
I guess I need to find and replace the accent combination by the direct slot?
That would be wise for now, but I think context should be able to trap this automatically (at least in the mode=node case).
Sounds reasonable. By the way, is the direct encoding generally preferred over the combination method (say, by good Unicode practice ;-)? If yes, I certainly wouldn't mind a little warning message if I happen to use the other variant…
Can something similar happen for other "foreign" characters (like ß, umlauts, ae, etc.) or is this sort of error only possible with accents?
IIRC, in principle it can happen with some other characters as well, but I do not think that happens often. It is mostly combining accents.
I see. So umlauts are good candidates to check, too. Thanks again, Oliver