I agree that it may be a good idea to have both backwards-combining
and forward-combining non-spacing characters in the RFC-CHAR.
Actually all the codetables only have forward-combining non-spacing
characters. I will change the specifications accordingly.
While RFC-CHAR does not cover Unicode it depends implicitly on Unicode's
definition of what various characters mean.
You cannot have it both ways. You cannot depend on getting definitions from
Unicode and then say you don't deal with the fact that the definitions in
the document you cite don't agree with your usage of them.
OK, I will remove the dependency on 10646 for these characters.
Well, I knew that T.61 etc was not fully defined, so that
a truly reliable conversion could be done. My idea has always
been to do the full specification, including the character combinations
allowed. According to SC2 terminology, a non-spacing character is
actually not a character, but only part of a character. T.61
has a repertoire of characters, where the non-spacing accents
actually is not a part. So these characters were only meant
as building-blocks.
I hope this change will satisy the requirements for now.
Keld