United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4468862 Apps should have better control the font storage during createFont call
JDK-4468862 : Apps should have better control the font storage during createFont call

Details
Type:
Enhancement
Submit Date:
2001-06-12
Status:
Resolved
Updated Date:
2003-06-02
Project Name:
JDK
Resolved Date:
2003-06-02
Component:
client-libs
OS:
generic,windows_2000
Sub-Component:
2d
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0,1.4.0
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
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.

-------------------------------------------------

                                    

Comments
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
============================
                                     
2003-04-28
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b08


                                     
2004-06-14



Hardware and Software, Engineered to Work Together