Some more information from upstream about the iconv issue: > I have seen the discussion in the bug. > > Coversion from legacy to Unicode in Khmer is so complex that it would be > a nightmare to do it in a standard system, even if the system was able > to do it (which I very much doubt). It requires complex reordering of > characters (in legacy fonts you type from left to write, in Unicode you > type phonetically, which often goes right to left), breaking up > characters in legacy that require 2 or more code-points in Unicode, > reuniting several legacy code-points into one unicode code-point (after > reordering, often with characters in the middle that need to be > rellocated somewhere else, and then the recombination results depend on > which character was in the middle)... and all this is different for each > legacy encoding (that is why the program needs to be compiled > differently for ABC and Limon). I have never seen a system that was able > to do it correctly... and for us it really has no value doing it. > > > Thanks for that info. Do you mind if I quote you if/when anyone asks > > about that? > > Please do. One of the things that we often find with very complex > scripts is that people in western countries who have not been exposed > have a hard time understanding that a script can do such funny things. > They tend to believe that Chinese would be the most complex language to > display... and this is really far from the truth, even Arabic would be > more difficult to display. Input methods are a different story... here > Chinese and Japanese are the difficult ones. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part