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

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

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.

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...

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.

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.

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.

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?

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

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

Ah. Okay, cheers.

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?

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.

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

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