You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vh...@gmail.com> on 2010/05/21 11:46:42 UTC
Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts:
AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java
CharacterSetOrientation.java DoubleByteFont.java FopCharacterSet.java RasterFont.java
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
Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts:
AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java
CharacterSetOrientation.java DoubleByteFont.java FopCharacterSet.java RasterFont.java
Posted by Vincent Hennebert <vh...@gmail.com>.
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
>
Re: svn commit: r946585 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/afp/fonts: AFPFont.java AbstractOutlineFont.java CharacterSet.java CharacterSetBuilder.java CharacterSetOrientation.java DoubleByteFont.java FopCharacterSet.java RasterFont.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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