TrueTypeUtil.getFamilyNames() chooses the wrong font if a non-ASCII "MacRoman" font is first in the table

[GoogleCodeExporter]

Run the following code:

    public static void main(String[] args) throws Exception
    {
        BaseFont font = BaseFont.createFont("X:\\msgothicjp.ttf", BaseFont.IDENTITY_H, false);
        for (String family : TrueTypeUtil.getFamilyNames(font))
        {
            System.out.println(family);
        }
    }

View the output and notice that it is not "ＭＳ ゴシック".

I discovered this when I went looking for other utilities for reading the font 
family out of a TTF after finding that both Windows itself and our own 
application didn't handle this file correctly (a separate program called 
FontCreator which we had lying around did an okay job of it though.)

Looking at the font object in the debugger, it looks like this:

    font.getFamilyFontName() = {java.lang.String[2][]@2458}
        [0] = {java.lang.String[4]@2459}
            [0] = {java.lang.String@2468}"1"
            [1] = {java.lang.String@2469}"0"
            [2] = {java.lang.String@2470}"1041"
            [3] = {java.lang.String@2471}"‚l‚r ƒSƒVƒbƒN"
        [1] = {java.lang.String[4]@2460}
            [0] = {java.lang.String@2464}"3"
            [1] = {java.lang.String@2465}"1"
            [2] = {java.lang.String@2466}"1041"
            [3] = {java.lang.String@2467}"ＭＳ ゴシック"

So the correct name of the font is at index [1] but the code explicitly skips 
over this for some reason. It seems like getFamilyNames() could simply remove 
the check for "1" and "0" and instead return all family names.

Distribution of the attached font is for verification purposes only. I'm sure 
the licence doesn't allow it, but I will say that I acquired it off a web page 
elsewhere so it's not like I'm leaking it.

As for why the font at index [0] has a corrupt name, I guess that must be 
iText's fault.

Original issue reported on code.google.com by trejkaz on 8 May 2012 at 5:34

Attachments:

• msgothicjp.ttf