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

Open Sans fails to kern in Chrome, Firefox and Edge #1162

Open
Gerry1135 opened this issue Aug 22, 2017 · 21 comments
Open

Open Sans fails to kern in Chrome, Firefox and Edge #1162

Gerry1135 opened this issue Aug 22, 2017 · 21 comments

Comments

@Gerry1135
Copy link

I'm not sure if you wanted me to report this here too. You said there was a known bug with Chrome and Firefox dropping the kern table but I can't see any mention of it here. If it is here somewhere and I missed it then feel free to close this.

Going to https://fonts.google.com/ in Chrome or Firefox (Edge seems to need a page that explicitly turns on kerning) and setting the preview text to Te and the size to maximum clearly shows that no auto-kerning is being done for Open Sans but it is for various other fonts. Using the TTF version of the font in a desktop program on my PC does auto-kern.

@Gerry1135
Copy link
Author

After closely examining the TTF files for Open Sans, it appears to me that the kern table is malformed. The kern table is supposed to consist of a header containing a version number and a count of the sub-tables in the table, followed by the sub-tables. Each sub-table has a header of 3 16bit values, one of which is the size of this sub-table in bytes (including the 6 bytes of header). In OpenSans-Regular.ttf, the header says that the kern table is 112180 bytes. The kern table header says there is only one sub-table. The sub-table says it is only 46642 bytes but then has the full 112160 bytes of kern pairs. OTS faults this and discards the whole of the kern table, resulting in no kerning when used in browsers.
It looks to me that whatever tool was used to build these TTFs has simply written the bottom 16 bits of the sub-table size, not caring about the overflow, rather than splitting the data into two sub-tables as the spec requires.
I have been able to generate working versions of these fonts by loading them into FontForge and re-saving them. This warns about the kern table and also warns about several other things, but it results in TTFs that have two sub-tables in the kern table and render correctly kerned in the browsers when converted to woff.

@Gerry1135
Copy link
Author

Incidentally, Open Sans Condensed Light and Light Italic also suffer from the same problem. Open Sans Condensed Bold does not suffer from it, it has two sub-tables in the kern table.

@davelab6 davelab6 added this to the Bugs in Font Files 03 Requires Rebuild milestone Oct 5, 2017
@davelab6
Copy link
Member

davelab6 commented Oct 5, 2017

@Gerry1135 thanks for reporting this!

@jobs-git
Copy link

what happened now? Has it been fixed?

@davelab6
Copy link
Member

davelab6 commented Feb 19, 2018 via email

@arena
Copy link

arena commented Dec 4, 2018

Check out the word "Button" set in OpenSans Regular with no tracking/letter-spacing adjustment
image

@jobs-git
Copy link

jobs-git commented Dec 5, 2018

what do you want to say?

@arena
Copy link

arena commented Dec 5, 2018

I'm trying to say that I love the OpenSans font but it needs better kerning. Sorry if that wasn't super constructive. If it's open source I guess I could try to contribute an enhancement.

@arena
Copy link

arena commented Dec 5, 2018

Also, I realize that this is more about a bug in Chrome that doesn't seem to exist anymore and less about the intricacy of the kerning of OpenSans. Maybe this issue should be closed? Unless there are steps to reproduce and there's a fixable issue?

@jobs-git
Copy link

jobs-git commented Dec 6, 2018

Hi, its open source, please try to contribute cause the font does not look good on WEB at its present state

@m4rc1e
Copy link
Collaborator

m4rc1e commented Dec 6, 2018

@arena I'm pretty sure Open Sans was spaced and kerned to work well on paragraphs of text, not text above 20pt.

@arena
Copy link

arena commented Dec 6, 2018

Ok. I'll think about it. If anybody else is inspired, OpenSans is part of this repository:
https://github.com/google/fonts

@Gerry1135
Copy link
Author

@m4rc1e please see the original report and the follow up where I describe exactly what is wrong with the kerning tables in the fonts... They do NOT kern correctly at any font size in browsers...

@davelab6
Copy link
Member

davelab6 commented Dec 9, 2018

@laerm0 is working on an update to Open Sans that will fix this.

@Gerry1135
Copy link
Author

I presume that the update mentioned above has happened but it appears to have made the situation worse not better. Now, each of the TTF files for the latest version of Open Sans has reduced in size to less than half of what it used to be. It appears that rather than fix the bad kerning tables, they have simply been removed...

@davelab6
Copy link
Member

As you can see in https://github.com/google/fonts/tree/master/apache/opensans the opensans font files haven't been updated by font designers or developers in many years, but work on such an update is underway.

However, the Google Fonts API engineers may have introduced changes to the API serving system that resulted in the Kerning tables being dropped, since they were delivered to Google in 2012 (?) by the vendor as malformed data (fonttools/fonttools#314 (comment))

@davelab6
Copy link
Member

@Gerry1135 are you seeing the 50% file size reduction in the ZIP downloads, or in the web fonts?

@Gerry1135
Copy link
Author

This was downloading the TTFs from https://fonts.google.com/?selection.family=Open+Sans
The individual files are all around 100 kb rather than >200 kB that the older versions were. One of my colleagues here mentioned the larger ones being "v15" and the latest ones being "v17" though both sets are marked as version 1.10...

@davelab6
Copy link
Member

davelab6 commented Jan 17, 2020 via email

@Gerry1135
Copy link
Author

Well, I am comparing TTFs downloaded as a zip from the URL I gave above back in 2017 against TTFs downloaded from the same place now. I haven't explicitly checked but the difference in the size of OpenSans-Regular.ttf matches very well with the 112160 bytes of kern pairs that were present, but "badly written" in the v15 version of the file (as mentioned in the second comment at the top of this issue).

So, the update to the font (that will also, hopefully, fix the malformed kern table) hasn't actually happened yet but the API side of things is now removing the kern table from the TTFs, either deliberately because the kerning doesn't work in browsers due to them discarding the malformed kern table in the WOFF data, or accidentally because the API is now using the same sanitisation code and no-one noticed because the font doesn't kern in browsers anyway.

The old TTFs with malformed kern tables work fine in windows and, if the kern tables are fixed and new WOFFs generated then the browsers can also kern it correctly. We currently work around the kern issues in our online application by serving these fixed WOFF files ourselves rather than referencing the Google ones. Unfortunately, now the TTFs have no kerning info, our servers format the text as if there is no kerning but we are still using our correctly kerned WOFFs so the browsers then display it with kerning.

Ideally, we would like the kern tables fixed in the master TTFs so the API serves correctly kerned files in all formats and we can stop serving our own fixed versions. In the meantime, we will continue to serve our fixed WOFFs and will roll back the TTFs on our servers to the v15 versions.

@msohni
Copy link

msohni commented Nov 18, 2020

This issue is going on and on. It was reported certainly as long as five years ago (i.e. 2015), initially as a bug in Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1185685), which was closed with a "Won't fix" after it was correctly stated that the bug is in Open Sans, not in Firefox. There are probably similar exchanges for Edge and Chrome elsewhere. As a consolation: the .woff files from Font Squirrel work correctly, but make sure you download the full set unless you know that you are only going to have Western European characters on your pages!

@RosaWagner RosaWagner removed this from the Bugs in Font Files 03 Requires Rebuild milestone Aug 13, 2021
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

8 participants