[OpenJDK 2D-Dev] Thoughts about font implementation

[Roman Kennke]

So, no more opinions on this proposed change?

/Roman

Am Dienstag, den 12.08.2008, 13:29 +0200 schrieb Roman Kennke:
> Hi there,
> 
> I have a small problem with current implementation of fonts in OpenJDK.
> It is required that fonts are present as files, and that all fonts are
> loaded via a FileChannel, not InputStream, because FreeType doesn't
> support loading from a sequential-only stream. From my perspective as
> embedded VM developer this is not very practical. Ideally I'd like to be
> able to embed fonts in the classpath (with the Jamaica VM you can create
> a complete image of an application+VM+resources and don't need anything
> else on the target machine, sometimes not even a filesystem). I can't do
> that using the current approach in OpenJDK. I have some ideas how to
> change it, and I think there are also some advantages for the more
> general OpenJDK community. Here's my plan which I'd like to discuss:
> 
> - Change TrueTypeFont and all related classes (these are a lot) to read
> from a (direct) ByteBuffer, instead of a file channel. FreeType can read
> fonts directly from a memory buffer, this would make a lot of code
> easier (i.e. freetypeScaler.c wouldn't need these callbacks).
> - At a slightly higher level, don't pass FileChannels to TrueTypeFont to
> read from, but instead map the file, and pass the resulting buffer. I'm
> not sure about all the OS level details, but I think it is possible that
> the OS does some interesting optimizations here. For example, if the OS
> already has the font file open (for the desktop), this can be reused,
> and should be faster than reading into a new buffer.
> - File.createFont(InputStream) could be changed to read from the stream
> into a memory buffer, instead of a temporary file.
> 
> For me personally, this means that I could access the app+VM+resources
> image directly using a (direct) ByteBuffer and pass that to read fonts
> from the classpath, thus solving my problem.
> 
> What do you think about this rough outline? Maybe you have other ideas
> how to solve my problem? Would such a change have a chance to be
> accepted into OpenJDK mainline? (I'd try hard to avoid having to
> maintain a fork of the code.)
> 
> Kind regards, Roman
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt