Ok. Thanks, Vincent
Jeremias Maerki wrote: > 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 >
