Thanks. Please try it and let us know how it works for you.
By the way, if anyone wants to see how the caching algorithm works, run the TextFlow demo with -Djogl.debug.TextRenderer and it will display both the on-screen rendering results as well as the contents of the backing store in a second window. It’s interesting to watch.
Good work!
I have tested the demo (and added some random numbers as separate text ;D) and its running very smooth. The only thing I noticed is that the caching algorithm resizes the texture sometimes very often in a short period of time. To prevent this I would recommend to add (if possible) a time delay before the cache texture size could be decreased next time.
but again good work 
Thanks for the suggestion. I’ve filed Issue 261 to track this. If you have a modified test case which shows the poor behavior, please attach it to the bug report.
This is probably a naive question but do you think that your render algorithm will work with Unicode fonts?
I presume that eclipse can work with unicode chars but i never tested it myself.
For a list of free unicode fonts check this pages:
This one looks nice:
It’s allways nice to know that we can translate our game or application to a load of different languages in their native charset.
A major goal of this TextRenderer was complete Unicode support and I can basically guarantee that it will work properly. The String-by-String caching algorithm has been vetted by Sun’s Java 2D font expert, Phil Race, and was informed by his advice. It would be possible to also get complete Unicode support by dynamically caching individual rendered glyphs, but the algorithms involved are more complicated and we haven’t yet seen a strong need to go this route. For the cases where the String-by-String approach works well, it will also be faster than glyph-by-glyph caching and rendering.