ingrid.yao@Eng 2001-06-12
RFE requested from one of CAP members:
----------------------------------------
I have noticed one problem for my application with the current
API call to createFont and I wish to suggest an enhancement.
As reported by the engineer on the fix to bug id 4395902, createFont
may need to write the font out to disk as the source font may be
very large. However, in our case we require that the font is not to
be written to disk.
I have three main reasons for this:
- we are writing a publishing applications that will download many
different fonts while it is running. The temporary font files will
not be deleted until the application quits leading to the disk filling up.
- fonts can be very easily pirated by anybody with even a basic knowledge
of Java. In our case the font that we are using in our Java application
is very valuable and in markets where it is very hard to protect copyright.
- due to the complexity of OpenType, the encoding of the font may be a
company secret - our competitors would easily be able to get our font
and then reverse engineer it.
I suggest the following possible enhancements:
1/ The simplest is for createFont not to make a temporary file unless
the font is larger than a certain size, say, 2Mb. Then to make the
created file with a name that does not end in '.ttf'.
2/ Have createFont check a Java property which, if set, will require it
not to write fonts to disk. This would leave the responsibility of
writing fonts to disk to the application and not the VM.
3/ Have a new API call where the application would control the font storage.
The application would pass a class to the createFont call which contains
methods to retrieve the font data. Any time the Java VM would require
access to the font data it would then ask the application.
I do not think any of these are difficult to implement and can be done
before merlin becomes final. Also this could be used to resolve an open
bug - id 4372455.
-------------------------------------------------