Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSans font compatability #8

Open
GoogleCodeExporter opened this issue Aug 11, 2015 · 16 comments
Open

OpenSans font compatability #8

GoogleCodeExporter opened this issue Aug 11, 2015 · 16 comments

Comments

@GoogleCodeExporter
Copy link

It seems that the truetype package cannot load the OpenSans font.

The font is compatible with other TTF viewers/editors.. so I wonder why I 
receive this error (from freetype.ParseFont() function):

freetype: invalid TrueType format: bad kern table length

Download font at www.opensans.com, I used the OpenSans-Regular.ttf font, but it 
seems all the OpenSans fonts do not parse properly.

Best regards,
Stephen

Original issue reported on code.google.com by [email protected] on 26 May 2013 at 4:47

@boriwo
Copy link

boriwo commented Sep 21, 2015

Just ran into the same issue. Any plans to fix this in the near future?

@alimoeeny
Copy link

For me it opens Open-sans-regular but fails on many others (on a mac OSX 10.11, go 1.5.1 )

@jeffwilliams
Copy link

I'm having the same problem.

@artyom
Copy link
Member

artyom commented Feb 6, 2016

Here's a great explanation on what's wrong with Open Sans kerning table; its parsing indeed fails on this check:

        if 6*f.nKern != length-14 {
                return FormatError("bad kern table length")
        }

@narqo
Copy link

narqo commented Feb 22, 2016

Same problem for me. Are there any plans to fix this?

@fstanis
Copy link

fstanis commented Apr 9, 2017

Any update? It seems to fail with Open Sans regular as well now.

@rillig
Copy link

rillig commented May 25, 2017

A quick fix is to apply the following patch:

--- a/truetype/truetype.go
+++ b/truetype/truetype.go
@@ -345,7 +345,7 @@ func (f *Font) parseKern() error {
                return UnsupportedError(fmt.Sprintf("kern coverage: 0x%04x", coverage))
        }
        f.nKern, offset = int(u16(f.kern, offset)), offset+2
-       if 6*f.nKern != length-14 {
+	if uint16(6*f.nKern) != uint16(length-14) {
                return FormatError("bad kern table length")
        }
        return nil

This allows at least Calibri to be loaded successfully. I have no idea about other consequences, though.

@adnsv
Copy link

adnsv commented May 30, 2019

For some reason this problem is still not fixed in the main repo. This prevents lots of fonts from being used with this library.

The original freetype repo, would load such fonts. IMHO a bit incorrectly, but better than nothing.

Here is my version of a slightly more robust check:

	// For large kerning tables, the extracted length value may be incorrect.
	// For such fonts, often only the lower 16 bits of the actual length are
	// stored. Here we validate the lower 16 bits, and also make sure that
	// the extracted number of kerning pairs does not exceed the total length
	// of the kerning table.
	if uint16(6*f.nKern) != uint16(length-14) || 6*f.nKern > len(f.kern)-18 {
		return FormatError("bad kern table length")
	}

@guilhermehubner
Copy link

Hello! There is any updates on this? 🤔

mishmish-dev pushed a commit to mishmish-dev/freetype that referenced this issue Jan 25, 2020
@SamusAranX
Copy link

This is still an issue, btw

@montanaflynn
Copy link

Also hitting this with the the https://fonts.google.com/specimen/Anton downloaded ttf file.

Marcon pushed a commit to Marcon/freetype that referenced this issue Mar 9, 2021
@zwang
Copy link

zwang commented May 4, 2021

Still an issue in 2021

@Vahanerevan
Copy link

Vahanerevan commented Jul 16, 2021

+1

@dastanaron
Copy link

dastanaron commented Feb 10, 2022

Still an issue in 2022

@rothcold
Copy link

Still have issue with Clear Sans

@SuperFromND
Copy link

SuperFromND commented Apr 1, 2024

This appears to still be an issue as of 2024; we just got a report about this over on the Ikemen GO repository (see ikemen-engine/Ikemen-GO#1715); it affects this font.

Is there any reason why the changes made in unidoc's fork or adnsv's fix above haven't been incorporated into the main branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests