OpenType question: dlig feature causes "offset overflow"

Alejandro Paul2 December 2005 · 10:30

In another thread someone asked about an “overflow” problem when compiling OpenType kern feature in Fontlab. I am having the same problem, except with the dlig feature. The solution that was suggested for the kern feature overflow was using subtables. I tried that with my dlig feature, but it looks like subtables are not allowed with this feature.

My dlig feature is quite simple. It’s just about 120 lines of things like “sub @lc_d @lc_a @lc_b by dab.alt;” nothing at all more complicated than this. I’m at a loss as to why it would could cause an “offset overflow”. I thought overflow errors were caused by tables that exceeded 64k in size. My dlig feature is nowhere near that size. In fact, my liga feature is about the same size as my dlig feature, but it doesn’t cause an overflow.

If anyone can shed some light on this, or tell me of a workaround, I would very much appreciate it.

Ale

twardoch2 December 2005 · 11:18

what’s the contents of @lc_a etc.?

Alejandro Paul2 December 2005 · 11:30

These are classes of variations on each individual letters. For example @lc_a is a class that is the equivalent of [a a.alt a.swash a.alt2]. None of these classes contain more than 6 glyphs. I even tried doing it without the classes, i.e. using “sub [a a.alt a.swash a.alt2] [a a.alt a.swash a.alt2] [a a.alt a.swash a.alt2] by aaa.alt;” It still caused the same overflow.

Thomas Phinney2 December 2005 · 12:58

It’s unrelated to the offset overflow, but I’ll just point out that your ligature glyph name is not ideal. Instead of dab.alt it should be d_a_b.alt.

Sorry that I don’t know what’s causing the overflow problem.

Cheers,

Alejandro Paul2 December 2005 · 13:19

Thanks Thomas. I’ll certainly take your advice into account.

Ale

twardoch2 December 2005 · 15:04

> I even tried doing it without the classes, i.e.
> using “sub [a a.alt a.swash a.alt2] [a a.alt
> a.swash a.alt2] [a a.alt a.swash a.alt2] by aaa.alt;

Sorry, but that is not doing it without the classes. [a a.alt a.swash a.alt2] is a class, @lc_a is just a shorthand name for it.

Why don’t you try it *really* without classes, i.e. “sub a a a by a_a_a.alt”?

Adam

paul d hunt3 December 2005 · 06:28

it seems to me that this kind of encoding can easily result in a large # of replacement lookups. I’m sure I don’t understand OT compilation as well as Adam does, but for your given example if you have 4 letter variations in each of your classes and 120 lines you would end up with 7680 lookups, and easily many more if some of your classes have five or more alernates or your ligature strings are more than 3 characters long. (Adam, please correct me if my thinking on this is wrong!)

An easy way to get around this problem is to put your dlig feature before your other features (salt, swsh, calt, etc.) But maybe you’re trying to achieve some other effect. Maybe you could explain a bit more in detail what you’re trying to achieve?

twardoch3 December 2005 · 08:11

Not lookups but substitutions — but indeed, that’s the case. And your advice makes much sense, Paul. If you move dlig before calt, you may get away with just putting the basic variants into dlig (sub a a a by a_a_a.alt) instead of all the variants (sub [a a.alt a.swash a.alt2] [a a.alt a.swash a.alt2] [a a.alt a.swash a.alt2] by a_a_a.alt), and yet, largely, you’ll achieve the same functional effect (except that dlig will not work for variants that were manually inserted into the text string using the Glyph Palette, but it will still properly interact with calt).

Adam

Alejandro Paul3 December 2005 · 16:08

I had already tried Paul’s suggestion, and the same overflow happened. I’ll try your suggestion, Adam. Thanks for your help.

Thomas Phinney3 December 2005 · 17:05

Adam’s suggestion is a good one for simplifying the code (whether or not it helps the overflow problem). Plus, dlig will still work for variants that are manually inserted using the glyph palette, because what gets stuck in the text is the base character plus the needed formatting.

twardoch4 December 2005 · 17:35

Tom,

you are right. Adobe Illustrator and InDesign are smart: when I insert a glyph using the Glyph palette, they try to guess the “best” possible way to access that glyph, and store that information. If a glyph has a non-private Unicode codepoint assigned, InDesign (and Illustrator) inserts that codepoint. If a glyph is accessible through a particular OpenType layout feature that InDesign can work with, InDesign inserts the Unicode codepoint of the basic glyph plus a feature code. When I insert a small-cap a, InDesign will store it as “a with smcp applied”. This is nice because if I switch the font, that formatting will retained if the new font also supports small caps.

If the glyph is available through several different OpenType Layout features, InDesign makes a “best guess”. And only if the glyph is not accessible through an OpenType Layout feature and does not have a Unicode codepoint associated, the glyph id is stored, as a sort of “last resort”.

The Mac OS X Character Palette works differently. If I switch it to the glyph mode and use it to insert a glyph to, say, TextEdit, the glyph id will be always used.

Adam

Thomas Phinney4 December 2005 · 23:21

Well, what can I say. We’ve had a few years to refine these behaviors, and in the cases cited, we own both ends (the glyph palette and the application) as well as a lot of support infrastructure.

Cheers,

twardoch5 December 2005 · 10:03

Thomas,

on an unrelated note: as we all know, Photoshop CS/CS2 doesn’t have the Glyph palette. I tried to use the Mac OS X Character Palette with it and it only works for “characters”, i.e. glyphs that have a Unicode codepoint assigned (even if that’s just PUA). Even though the Apple Character Palette has a “glyph” mode, unencoded glyphs don’t make it into Photoshop, or InDesign or Illustrator. I realize this has to do with the text infrastructure, and that Adobe apps don’t use the Cocoa text handling (AAT/ATSUI). However, I wonder if this could be looked into for all future CS apps on the Mac. Even though Illustrator and InDesign have their own Glyph palettes, I think a seamless integration with the system Character palette would be desirable. The Mac OS X Character palette is actually a pretty potent tool.

Of course, I have submitted a request on this at http://www.adobe.com/support/feature.html

Adam

Captured from web.archive.org on 24 Sep 2008. view this capture