JDK-8074562 : CID keyed OpenType fonts are not supported by T2K
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7u60,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-03-06
  • Updated: 2020-02-03
  • Resolved: 2016-12-12
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.
JDK 7 JDK 8 JDK 9
7u271Fixed 8u152Fixed 9 b150Fixed
Related Reports
Duplicate :  
JDK-7076461 - OTF/CID font top-dict not parsed properly by T2K
Duplicate :  
JDK-7076461 - OTF/CID font top-dict not parsed properly by T2K
Duplicate :  
JDK-8233828 - Add OpenType CFF support in JDK 7
Relates :  
JDK-8185538 - JDK 9 is really slow initialising some OTF/CFF fonts.
Description
J2SE Version (please include all output from java -version flag):

Not working Java versions:
java.version: 1.7.0_75 Java(TM) SE Runtime Environment Linux amd64
java.version: 1.8.0_40 Java(TM) SE Runtime Environment Linux amd64
java.version: 1.8.0_45 Java(TM) SE Runtime Environment Windows 8.1 x86
java.version: 1.9.0-ea Java(TM) SE Runtime Environment Windows 8.1 x86

Working versions:
java.version: 1.7.0_75 OpenJDK Runtime Environment Linux amd64 =>

Does this problem occur on J2SE 6ux or 7ux?  Yes / No (pick one)
This feature was added in Java 7.

Operating System Configuration Information (be specific):
Different OS (Windows, Linux)

Hardware Configuration Information (be specific):
Different systems

Bug Description:

The follow test program (also attached) returns a negative string width for 
an OpenType fonts with Java SE. It works with OpenJDK. With Java SE it 
returns -5 pixel as string width for the word "Test". On OpenJDK it returns 
38 pixel.

Steps to Reproduce (be specific):

    public static void main( String[] args ) throws FontFormatException, 
IOException {
        BufferedImage img = new BufferedImage( 100, 100, 
BufferedImage.TYPE_INT_RGB );
        Graphics2D g = img.createGraphics();
        g.setFont( Font.createFont( Font.TRUETYPE_FONT, new 
File("AdobeMingStd-Light.otf") ).deriveFont( 18f ) );
        int stringWidth = g.getFontMetrics().stringWidth( "Test" );
        System.out.println( "java.version: " + System.getProperty( 
"java.version" )+" "+System.getProperty("java.runtime.name")+" 
"+System.getProperty( "os.name" )+" "+System.getProperty( "os.arch" )+" => 
stringWidth: "+stringWidth );
    }
Comments
Still pending the fix to customer as high priority issue. Targeted to 9
17-08-2016
This is a CID keyed font and there-in lies the problem. The T2K support for CID fonts is non-existent and when we enabled CFF fonts we should really have up-front discounted ones that are CID-keyed. In essence a CID font is a bit like a font-set. Instead of the top-dict referencing a private-dict there is instead an 'fdArray' reference to a font dict index. That index points to a sequence of 'font dicts'. Each of which is essentially a top-dict which will contain a private dict, and other fields from a top-dict, except I presume its not allowed for it to in turn reference another fdArray .. But there's more. Given multiple private dicts, how do you decide which one to use ? The answer is the 'fdSelect' table in the topDict. It needs to be used to perform a lookup for every glyph to see which of the 'fdArray' entries should be used for a particular glyph. And it comes in two formats, both of which need to be understood. Likely there's something else I'm overlooking or not covering in this high level explanation that will surface in time. Given this lack of support its amazing that the glyphs render well at all. This font must make minimal use of 'local' subroutines in the private dicts we have not located. Back to the bug that is observed, the problem is that the width of a glyph may be based off the 'default' and 'nominal' values in the private dict. Since we fail to find these dictionaries then we think its zero. So fixing this requires the full support for finding the per-glyph dictionaries and will require a fair amount of delicate implementation work. I am not yet sure we will have time for this in JDK 9. There's a possible band-aid of looking to see at the HTMX table and using its values but knowing when that is needed looks tricky as does inserting the values at the right place in the logic. Plus it probably just kicks the can down the road to the next problem due to missing CID support so I am not in favour of that even if it seems to work.
06-05-2015
test case attached
06-03-2015
Sounds like a bug in T2K CFF support. Can someone please supply the font to test with ?
06-03-2015