Excerpts From ned(_dot_)freed(_at_)mrochek(_dot_)com:
Message
There's also the whole issue of encoded-words and character sets. I think the
way to go is for this document to be clear that the notification material it
creates is in UTF-8, and that encoded-word and content decoding should be done
as part of these substitution operations.
The text[n] construct is also fairly problematic. For example, what happens
when the cut off falls in the middle of a line terminator? What happen when th
e
number fall in the middle of a multibyte character?
A line-oriented construct would avoid these issues, however, it wouldn't
necessarily work right with message services that have limited text capacity.
This is a good point. Trying to deal with byte boundrys with different
character sets is a major pain. I agree the output should be utf8 and the 'n'
in text[n] should refer to n unicode characters not n octets (as currently
implied).
btw Thank you to everyone for the comments in the last couple messages. We'll
try to get them integrated and a new version out in the near future.
Thanks,
Tim