Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4468862

Apps should have better control the font storage during createFont call

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Fixed
    • Icon: P4 P4
    • 5.0
    • 1.3.0, 1.4.0
    • client-libs
    • 2d
    • tiger
    • generic, x86
    • generic, windows_2000


      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.

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

            prr Philip Race
            tyao Ting-Yun Ingrid Yao (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: