FOText question

[Andreas Delmelle <an...@telenet.be>]

Hi fopsters

I've just been working on changing FOText to work with a java.nio.CharBuffer (instead of a char[]).
So far, while refactoring this, I already noticed that this makes the related code much more compact on our side. Another small improvement is that TextLayoutManager no longer duplicates the FOText's character array, but simply shares the same array that is backing the FOText's CharBuffer (slight reduction of the memory footprint; could be a significant amount in large documents).

Now, while I'm at it, I'm wondering whether it would be a good idea to have FOText implement Java 1.4's java.lang.CharSequence interface. This would mean that FOText gets a few extra methods (charAt(), length() and subSequence()), allowing us to use it in other parts of the code in the same fashion as a String or StringBuffer. The toString() method would need to be altered to follow the  definition as specified in the API docs (i.e. only output the text-content). 

Any opinions on this? (or more importantly: Any objections?)


Cheers

Andreas

Re: FOText question

[Max Berger <ma...@berger.name>]

Andreas,


Am 15.06.2008 um 13:25 schrieb Andreas Delmelle:
> Now, while I'm at it, I'm wondering whether it would be a good idea  
> to have FOText implement Java 1.4's java.lang.CharSequence  
> interface. This would mean that FOText gets a few extra methods  
> (charAt(), length() and subSequence()), allowing us to use it in  
> other parts of the code in the same fashion as a String or  
> StringBuffer. The toString() method would need to be altered to  
> follow the  definition as specified in the API docs (i.e. only  
> output the text-content).
>
> Any opinions on this? (or more importantly: Any objections?)

Not at all. I am still working my way through the Layout code, trying  
to get the alignmentContext to work, so any reduction / simplification  
in this respect would only make it easier.

As for the implementation of the interface: If the "subSequence" is  
never used, then it is probably a good idea to implement if by  
throwing an "UnsupportedOperationException", as this operation seems  
very complex and there'd be no point implementing it unless it is used.

> Cheers
> Andreas

Max