Microsoft: Please fix Opentype!

Charles_borges_de_oliveira's picture

Opentype has a major flaw in it. The limited size of the GPOS subtable is set at 64KB. That puts a cap on the amount of Kerning pairs a font can have. Most people will probably never go over the amount alloted but for those of us who do it really puts a damper on making fonts. I know House Industries had the same problem and posted a video on it. I am not sure what Microsoft can do at this point to fix it. Anybody who is involved with the opentype division at Microsoft, could you please pass this note to them.
Thanks!

Thomas Phinney's picture

This was addressed nine years ago. The "extension" lookuptype 9 for GPOS (lookuptype 7 for GSUB) was added to the OpenType spec with version 1.3, released in April 2001.

Now, be warned that some older apps and operating systems may not support extension lookups, but that is not something that can be addressed by the spec.

This is arguably just a workaround for a limitation in the format overall, but changing OpenType to use four-byte offsets instead of double-byte offsets would be a huge and highly incompatible change. Maybe some day there will be strong enough reason to do that, but I'm not expecting it will necessarily happen in my lifetime.

Cheers,

T

Charles_borges_de_oliveira's picture

Thanks for the response Thomas. Thats too bad the Opentype will always be flawed. Oh well.....

Ray Larabie's picture

How can I measure the GPOS subtable size in FontLab? I'd like to be able to expand kerning classes to squeak in just below the 64k limit.

Ideally, FontLab would have an option to expand kerning classes to fill the remainder of the GPOS subtable space. In the background, it would test compile, check the remaining GPOS subtable space and calculate how many pairs could be squeezed in.

A not-as-good but acceptable feature would be to produce an error message if the 64k limit was exceeded.

Adam Shubinsky's picture

This reminds me of a previous Microsoft "oversight" – the infamous 640k restriction. Sounds like the short-sighted attitude is well entrenched in some minds.

I don't agree with Thomas' pessimistic timeframe though, just to quote Mr Gates:

"I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time. Well, it didn't - it took about only 6 years before people started to see that as a real problem."

(1989 speech on the history of the microcomputer industry)

So, perhaps there is hope for the GPOS...

John Hudson's picture

Ideally, FontLab would have an option to expand kerning classes to fill the remainder of the GPOS subtable space.

Why? In what way is that useful?

This reminds me of a previous Microsoft "oversight" – the infamous 640k restriction. Sounds like the short-sighted attitude is well entrenched in some minds.

Before we all start dumping on Microsoft, it should be pointed out that the table size limitations of OpenType, which affect almost every aspect of the architecture, date back to Apple's original TrueType spec.

Ray Larabie's picture

Why? In what way is that useful?

If I don't expand, kerning won't appear in apps which don't support classes. I usually do around 2000 pairs and it doesn't break but I don't know what the limit really is.

I don't have a list of apps that don't support classes. MyFonts was my main concern for a long time. Not expanding kerning means broken kerning in some apps.

John Hudson's picture

Are you talking about expanding classes and writing pairs to a kern table, or expanding classes to fill out the maximum size of a GPOS table, which is what you wrote.

Ray Larabie's picture

I meant expanding classes and writing pairs to a kern table. When I add too many pairs, the OT code breaks in some apps. Is that unrelated to the 64k limit?

John Hudson's picture

The kern table is unrelated to OTL, and it has a particular limitation all its own. See Josh Hadley's comment in this discussion:
http://typophile.com/node/70841

Thomas Phinney's picture

Yup, limited to 10,920 pairs in apps that are sticklers for that aspect of the spec.

Individual apps faced with more than 2K or 4K pairs in a flat kern table may exhibit various kinds of failures. This was a serious problem about a decade ago, and although I expect the situation is much improved, I don't recall if anybody has done rigorous testing on it recently.

Cheers,

T

Ray Larabie's picture

Ah. Okay, cheers.

Adam Shubinsky's picture

John, I am not dumping on Microsoft per se. The bug of short sightedness afflicts us all at one point or another, and Microsoft did after all have the good sense to take your advise, on more than one occasion…

I am puzzled and curious though; did Microsoft, in devising the then-new OpenType standard, have to adhere to the historical table restrictions of Apple's original TrueType specifications? Was it not possible to just breakaway from these legacy restrictions and establish a less confined standard? Or did they just stick to the existing limitations out of convenience?

Khaled Hosny's picture

I think they had that idea of OpenType fonts remaining backward compatible i.e. for non-OpenType aware apps it still looks like good old TrueType font, so may be it has something to do with this issue.

John Hudson's picture

Yes, backwards compatibility was one of Microsoft's goals.

Thomas Phinney's picture

And rightly so. Lack of backwards compatibility was one of the reasons Apple's GX typography originally failed (and has failed again in AAT form, though not as dramatically, in part because it is more backwards compatible).

T

Syndicate content Syndicate content