Pushing the Limits of Complex Script Typography in FontCreator: Automated Subtable Splitting & GPOS Extension Lookups

FontCreator - Font Editor FontCreator - Requests and Enhancements
1

Hi Sir Erwin,

Thank you again for the feedback and confirmation regarding (bug report Bug & Architecture Request: GPOS Subtable Overflow (65540 > 65535) in MarkToBase, Optimizer Corruption, and Subtable Splitting Heuristics (FC 16.0.0.3082)) the InDesign rendering pipeline. I will submit the comparative test case to the Adobe team as suggested.

Now that the diagnostic messaging in Build 3083 is working so effectively, I want to bring up the underlying necessity that complex-script developers (especially in Arabic, Persian, and Urdu Nastaleeq) face daily when scaling commercial fonts.

While optimizing layout storage reduced our subtable from 87 KB to 35 KB, this project is still in active expansion. As we add more stylistic sets, contextual ligature variations, and full diacritic coverage across hundreds of base forms, even the optimized table will inevitably cross the 65,535-byte barrier again.

Since the 16-bit ceiling is an immutable part of the standard OpenType format, manual splitting in the OpenType Designer becomes extremely painful, error-prone, and fragile when managing tens of thousands of anchor pairs across multiple classes.

To make FontCreator the definitive, undisputed powerhouse for massive complex-script font development, I want to strongly request that you consider implementing one (or both) of the following architectural enhancements in an upcoming release:

1. Transparent Compilation-Level Auto-Splitting (The Ideal Solution)

I understand and completely respect your philosophy: “the subtables in the OpenType Designer are yours, and I would rather have the exporter tell you exactly where the limit is hit than silently reshape your lookup.”

However, there is an elegant way to preserve both:

  • In the GUI (OpenType Designer): Keep the user’s lookups and visual layout completely untouched. The designer works logically with a single clean list of base glyphs and mark classes without having to manually calculate bytes or fragment their design structure.

  • At Compilation Time (Exporter): If a single subtable exceeds ~55–60 KB during serialization, the compiler transparently partitions the compiled BaseArray / Coverage structures into two or more physical subtables inside that same lookup in the final binary.

This gives the user the best of both worlds: clean, unfragmented project organization in the editor, and 100% compliant, overflow-free binary export.

2. Native Support for GPOS Extension Positioning (Lookup Type 9)

The OpenType specification explicitly provides Lookup Type 9 (Extension Positioning) with 32-bit offsets (Offset32), specifically designed to bypass the 64 KB Offset16 limitation for large GPOS tables (analogous to GSUB Extension Type 7).

  • If FontCreator can automatically promote overflowing GPOS lookups (or subtable wrappers) to Extension Positioning (Type 9), the physical subtable byte limit effectively ceases to be a barrier, allowing massive Nastaleeq matrices to compile without artificial boundaries.

Why this matters for FontCreator’s ecosystem:

Non-Latin scripts with rich calligraphic traditions (Nastaleeq, Thuluth, complex Arabic ligatures) represent the ultimate stress test for any OpenType compiler. Currently, font engineers often feel forced to move to CLI scripts or complex Makefiles just to handle subtable partitioning when fonts grow large.

If FontCreator handles this auto-partitioning or Extension promotion natively under the hood, it eliminates the single biggest bottleneck in high-end font production and makes FontCreator unmatched in the industry for complex script typography.

I would be more than happy to test internal alpha/beta builds with our largest, most demanding font projects anytime.

Thank you for your continuous dedication to pushing FontCreator forward!

2

Thank you for the detailed suggestions and for offering to test with your larger projects.

FontCreator already automatically makes use of both GPOS and GSUB Extension where appropriate to avoid 16-bit offset overflows. However, Extension Positioning does not remove all 64 KB limitations. There are still many structures within the OpenType specification that use 16-bit offsets, counts, or other fields, so sufficiently large subtables can still exceed limits imposed by the format itself.

Automatically splitting an oversized subtable during compilation is something we can investigate. Ideally this could happen without changing the logical organization you see in the OpenType Designer. We first need to determine whether this can be done reliably for all applicable lookup types without changing shaping behavior.

Even automatic splitting is not unlimited, though. The OpenType specification also places limits on the number of lookups and on various other structures, so at some point a sufficiently complex font will inevitably encounter another boundary.

FontCreator already does a considerable amount of work behind the scenes to optimize and preserve OpenType Layout features. I am not aware of another commercial font editor with native OpenType editing tools capable of preserving and rebuilding such complex layout data to the same extent.

Some open-source font-production tools, particularly projects developed or funded by organizations such as Google, may have comparable or more sophisticated optimization algorithms in specific areas. They also have considerably larger development resources available to them. As a small development team, we unfortunately cannot implement every possible optimization, but we will continue improving FontCreator where we believe we can provide a reliable solution.

We will look into whether automatic splitting of oversized subtables can be added safely.

3

Thank you for the detailed and transparent architectural explanation.

Your clarification regarding internal subtable structures (such as BaseArray offsets within MarkBasePosFormat1) versus lookup-level Extension positioning makes complete sense. The distinction is very clear: Extension handles outer lookup table offsets, but internal subtable structures remain bound by the format’s 16-bit design.

It is very encouraging to hear that the High-Logic team is open to investigating compilation-time subtable auto-splitting. Preserving the logical layout inside the OpenType Designer while managing physical subtable division under the hood would be a monumental workflow milestone for complex-script font engineering.

FontCreator’s visual OpenType Designer and layout rebuild capabilities are already leagues ahead of anything else available in the commercial font design space. The fact that an independent team delivers this level of precision and responsiveness is why so many of us rely on FontCreator as our primary production tool.

Please feel free to reach out whenever you have an experimental build or test cases ready for evaluation. I would be more than happy to benchmark it against our largest Urdu and Arabic projects to help verify shaping consistency.

Thank you again for your time, the quick release of Build 3083, and your continued commitment to pushing FontCreator forward.