JDK-4752644 : RFE: Getting a java.awt.Font's FilePath
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.1,6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2002-09-24
  • Updated: 2022-04-12
Related Reports
Duplicate :  
JDK-6402253 - expose fsType in java.awt.Font
Duplicate :  
JDK-8284730 - Be able to get font path
Duplicate :  
JDK-6402303 - expose copyright and trademark information in java.awt.Font
Description

Name: jk109818			Date: 09/24/2002


FULL PRODUCT VERSION :
java version : 1.4.0_01
J2RE, SE : 1.4.0_01-b03
HotSpot client VM : 1.4.0_01-b03 mixed mode

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The problem is some classes need to know the path to a ttf
(or ttc) file to create their own Fonts (not a subClass of
java.awt.Font .

It would be very interesting if a FilePath
java.awt.Font.getFilePath() method existed.

Another possibilty would be to have a way of getting the
folders in which the font are located (either in the JRE or
in the system) and let the user find the wanted files. this
could be a FilePath
GraphicsEnvironment.getDefaultFontFolders() .

REPRODUCIBILITY :
This bug can be reproduced always.
(Review ID: 164849) 
======================================================================
Comments
EVALUATION 1) java.awt.Font.getFilePath() This could be done but there are some caveats. - It might return null because the file is not accessible - It will require a FilePermission. - It presumes that a java.awt.Font is supported by a single font resource, whereas in fact its not true for a) the "logical" composite fonts such as "dialog", b) cases where a group of font resources (files) which represent a single face are combined to support a larger range. c) cases where external bitmaps are used. I could imagine a follow-on RFE to get all the resources and probably more. 2) GraphicsEnvironment.getDefaultFontFolders() in this case the app would have no way of equating files to java fonts, nor any guarantee it locates all files. The class of applications for which this information would be useful is small: those that include a font scaler, or those which want to extract sufficient information to embed the font. It would be useful to have more information from the submitter about the intended usage, but its extremely unlikely this feature will be implemented in any currently planned releases and is thus at least several years off. ###@###.### 2002-09-24 ============================ We didn't get the requested justification. I am closing this as will not fix. It can be re-opened if we get sufficient justification and demand, and clarity on what is needed. ###@###.### 2002-10-09 ============================ New information is that the required usage is font embedding. This is something that also needs to take into account font licensing. Some font licenses specifically prohibit embedding. Applications which have such a requirement need to verify this. For now I'm going to leave this closed because I don't realistically think it will get implemented in JDK1.5. ###@###.### 2002-10-10 =========================== I am reopening this to re-consider getFontFile() for a future release. The exact design is TBD. It will necessarily be constrained such that it may return null if the font isn't mappable to a file, or the font prohibits embedding. We should also consider if a Permission should be required, at least for fonts which do not allow completely free copying. This would ensure that trusted code is required to able to make decisions about obtaining a font for embedding. This may be moot for an API that returns a File but more important if there were one that returned an open stream on the font file. Its possible that we could also add a query method which tells you more precisely why the font isn't available, etc. The return value could be an enum which is one of PROHIBITED : font license doesn't allow you to copy/embed it UNAVAILABLE : font can't be mapped to a file, maybe the JRE can't find the file either, or its a logical font, etc. ALLOWED : font says its OK. UNNKOWN : font is available but there's no information about whether it allows embedding/copying: ###@###.### 2004-01-23 =============================
23-01-2004
WORK AROUND Use platform knowledge to locate the font files. This should not be an undue burden and is obviously going to be needed any way for quite some time as this feature can only be added in an API release. ###@###.### 2002-09-24 ============================
24-09-2002