Hi Vincent, in the long term, I agree with you. But as long as so many other parts of FOP (like Font.mapChar()) use "char", there's no point to use "int" in the backend. There will never be any characters outside the basic plane until the whole process from input through layout engine to rendering components are prepared for these characters. In the short term, my change really improves understandability which is usually one of your major concerns. It helped me a lot identifying a problem. The changes can easily be reverted once there is a concerted effort to make the whole of FOP compatible with the full range of Unicode characters. It's also important to note that the AFP part will need some special attention when these characters need to be used as some of the data structures in there will get insanely large if we start supporting characters beyong the basic plane. So unless there is a sustained veto against rev 946585 I'm inclined to leave it like it is.
On 21.05.2010 11:46:42 Vincent Hennebert 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 Jeremias Maerki
