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

CID keyed OpenType fonts are not supported by T2K

    Details

    • Subcomponent:
      2d
    • Resolved In Build:
      b150

      Backports

        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 );
            }

          Issue Links

            Activity

            Hide
            prr Philip Race added a comment -
            Sounds like a bug in T2K CFF support. Can someone please supply the font to test with ?
            Show
            prr Philip Race added a comment - Sounds like a bug in T2K CFF support. Can someone please supply the font to test with ?
            Hide
            tyao Ting-Yun Ingrid Yao (Inactive) added a comment -
            test case attached
            Show
            tyao Ting-Yun Ingrid Yao (Inactive) added a comment - test case attached
            Hide
            prr Philip Race added a comment -
            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.
            Show
            prr Philip Race added a comment - 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.
            Hide
            vdyakov Victor Dyakov added a comment - - edited
            Still pending the fix to customer as high priority issue. Targeted to 9
            Show
            vdyakov Victor Dyakov added a comment - - edited Still pending the fix to customer as high priority issue. Targeted to 9

              People

              • Assignee:
                pnarayanan Prahalad Kumar Narayanan
                Reporter:
                shadowbug Shadow Bug
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: