JDK-4468862 : Apps should have better control the font storage during createFont call
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.3.0,1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-06-12
  • Updated: 2017-05-16
  • Resolved: 2003-06-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
5.0 tigerFixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
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.


CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b08

EVALUATION Suggested fix for Merlin Beta refresh: Rename temporary file with a different prefix and use .tmp extension. jennifer.godinez@Eng 2001-07-27 =============================== Contrary to the assertions in the description there are some issues with implementing this functionality. By making a copy the JRE can control the lifetime of the file. By contrast the application can't know for how long a reference is held to the font. Thus at any time the JRE may need to access the file. If the file could be removed or replaced by the application then the JRE will need to keep the file open which would prevent the file being removed by the application on some OSes and increase the number of file handles in use. This requires redesign of the implementation to treat these files differently so isn't just a matter of an API. Its also unclear how one stated benefit (being able to prevent user access to font files) would be achieved if a File needs to be provided. Even more work - would be required for a callback interface for font data. Plus it would be slower, not least because there would need to be more code to validate the data. In summary * The benefit of minimising the amount of storage used should be partially taken care of in 1.4 by better deletion of temporary files, and should be even better taken care of in 1.5 by other reworking. * An API that takes a java.io.File would still expose that file to users. * There is a benefit in that it is expensive to copy a file. There would very certainly need to be security permissions to use such an API. This is somewhat unlikely to be implemented in tiger. ###@###.### 2002-10-01 ============================ New API has been approved to create a font from a file, The API is Font.createFont(int, File) ###@###.### 2003-04-28 ============================