I'm puzzled by this discussion. AFAIK, Java has rejected moving to 32 bits in Java 5. Instead, they are supporting supplementary characters. There's a discussion here: http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
Peter West "Lord, to whom shall we go?" On 21/05/2010, at 11:11 PM, Glenn Adams wrote: > I concur with this change, and have already made some changes in this > direction in my work on adding complex script support. > > Please note that it is not quite so simple as merely changing from char to > int in some locations. It is also necessary to convert from UTF-16 to UTF-32, > i.e., to the full Unicode code point value, which can range from 0x000000 > through 0x10FFFF (see Unicode 5.2, Section 3.3, Item D9). It is probably not > a good idea to make this conversion too early, but rather, to defer it until > certain well defined interface points, which need to be documented as taking > the full Unicode code point, and not merely a UTF-16 code element. > > On Fri, May 21, 2010 at 3:46 AM, Vincent Hennebert <vhenneb...@gmail.com> > wrote: > Hi, > > > Author: jeremias > > Date: Thu May 20 09:52:27 2010 > > New Revision: 946585 > > > > URL: http://svn.apache.org/viewvc?rev=946585&view=rev > > Log: > > Changed many variables and parameters from "int" to "char" because AFP font > > support mostly uses Unicode code points unlike Type 1 and TrueType support > > which use internal character code points (the result of Font.mapChar()). > > This should improve code readability. > > Not sure this is a desirable change. char can only address characters > from the Basic Multilingual Plane. Java 1.5 have started to use int to > overcome that issue actually. So unless there is a fundamental > limitation in AFP such that characters beyond the BMP will never be > usable, I think we want to stick to int. > > <snip/> > > Vincent >
