[OpenJDK 2D-Dev] Thoughts about font implementation

Roman Kennke roman at kennke.org
Fri Sep 5 18:46:03 UTC 2008

Hi there,

I'm back from holiday now, and I think Phil is too. I'd like to have
another look at this proposal now, it is quite important for me. Any
other opinions from you, especially Phil?

Cheers, 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20080905/02e132e3/signature.asc>

More information about the 2d-dev mailing list