address@hidden wrote:
The multiple unicode codepoints for 0xBD and 0XDB will result two
different unicode strings to be translated into the same MACROMAN
string, making the "return trip" ambiguious. I am curious though
since libiconv already does make a decisive choice when going from
MACROMAN to UTF8(instead of rejecting those characters),
wouldn't it make sense for it to choose the same consistent
behavior from UTF->MACROMAN?
libiconv currently only implements a 1:1 conversion, exactly as listed in the
file libiconv/tests/MacRoman.TXT. I'm also not so much a fan of mapping two
different Unicode code points to the same byte value; because of the round-trip
problem, as you say. It's safer to tell the user clearly that a certain Unicode
code point (such as U+20AC) is not supported in the particular character set.
I am still unclear about the motivation behind Apple Logo,
because even when I am on a linux system(which I am)
it's private-use U+F8FF should still get translated into
ASCII 240(0xF0). should it?
It was not done this way in the MAC-ROMAN mapping table published on
ftp.unicode.org around 2000.