MakeOTF GSUB offset overflow

After searching earlier threads, I get the impression I’m the first one to get the attached warning when attempting to update the features. Any help in overcoming the problem is highly welcome. (Glyphs 1.4.5 (614), Mac OS 10.8.5)

You seem to have many, many ligatures. What is it that you are doing in the font?

This is a related thread.

It’s Lepcha, still. :slight_smile:

I know it’s probably not the most elegant solution, but I’m attempting for a fail-safe Unicode font covering the whole range of the Lepcha La-Zóng comprising of around 8200 characters. Since a font can accomodate more than 60’000 characters this should not be an issue, as such. I don’t mind to patiently compile the required combinations, nor to have a font file of around 860 KB once finished.

By the way, it does not seem to be a matter of the many ligatures. I can still add new ones, but when coming to the ligatures

ya_voweluu_consonantkang-lepcha.liga;
ya_voweluu_consonantnyindo-lepcha.liga;

I get the error message, which, meanwhile, reads as in the attachment. Removing these ligatures does not help, however.

I’m not qualified to be able to suggest a solution, but it is a matter of the size. It’s not any specific line that the problem.

I’m more interested in La-Zóng thing as a person who has done Lepcha before. Which character sequence do you need and what should happen?

La-Zóng are the traditional syllabaries used by the Lepchas to learn the Lepcha or Róng script. It’s basically a table listing one by one the initials with all their possible combinations that can be formed adding NUKTA, vowel signs, RAN, medials (-l, -r, -y) and finals.

What I require is no specific sequence, but the ability to finish my work. I managed to create 6000 characters and I’d simply like to add the remaining 2000. From what I learn in the linked thread, there is no limit in terms of ligatures defined. However, the length of code required for these definitions is limited.

Furthermore, there seems to be a possibility to extend the liga subtable, but I don’t understand how this is achieved. May be, someone code-savy will have pity with me …

Perhaps it can be done with a useExtension statement. Add that right before the curly bracket of the Liga feature in the features.fea file in the temp folder, and run the generate command from there again.

Thanks for the hint. This is what I get:

macmini-2300:~ steff$ /Users/steff/Library/Application\ Support/Glyphs/Temp/Mainwaring\ Lepcha-Regular/generateFont.command ; exit;
makeotfGlyphs [WARNING] final name uni1C031C371C251C241C271C36.liga is longer (32) than limit 31, in GlyphOrderAndAliasDB line 1591.

makeotfGlyphs [WARNING] final name uni1C1D1C371C251C241C271C36.liga is longer (32) than limit 31, in GlyphOrderAndAliasDB line 2011.

makeotfGlyphs [WARNING] final name uni1C001C371C251C241C271C36.liga is longer (32) than limit 31, in GlyphOrderAndAliasDB line 2522.

makeotfGlyphs [WARNING] The total size of the glyph names is greater than the safe limit for Mac OSX 10.4.x and earlier by 110714 bytes, and will cause crashes. [font.pfa]
makeotfGlyphs [ERROR] “useExtension” allowed in feature-scope only for ‘aalt’ [features 38]
makeotfGlyphs [FATAL] aborting because of errors
logout

Is it thinkable to give the ligatures a shorter name, for example ‘l1539’ instead of ‘fla_voweli_ran_consonantnyindo-lepcha.liga’ to cut down bytes?

Can you try the latest cutting edge version. I updated to the latest version of makeOTF.

Can you send me the file? I had a look at Lepcha some time ago.

Files are on the way.

What exactly do you mean with ‘cutting edge version’? I generally consider Glyphs to be cutting edge. :smile:

Beta version.

@blinkenlichten Here are another case of feature overflow:

Also, if you need to use “useExtention” tag in one feature, be sure to use it also in aalt.

Time for an update:

I actually ran into a twofold problem with MakeOTF. One was (still is) the number of ligatures exceeding the 64k limit of GSUB subtable 4, as diagnosed immediately by some of the contributors.

The other one was the fact that the chains of ligatures - such as ka_nukta_subjoinedra_subjoinedya_voweli_ran_consonantnyindo-lepcha.liga
were getting too long as well. Georg helped me to overcome this issue with shorter names.

I ignored the first problem for the time being and accommodated the remaining ligatures in a new file. Meanwhile, I finished the compilation resulting in 84 glyphs and 8316 ligatures. While this is probably not a very sophisticated approach to the intricacies of Lepcha script, it has a huge advantage over all the other attempts I’ve come along, so far: It’s a WORKING approach.

So, my font is split into two font files with around 6000 and 2000 characters, respectively, and the next step preferably were the merger of these into one file. I think this should be feasible placing the surplus liga-definitions in the GSUB lookup 7 (extension) subtable.

@Nicolas: You pointed me to a proposal I failed to implement. I would be most grateful for some more detailed advice adapted to my Greenhorn level.

@Tosche: Attached the La-Zóng (syllabary traditionally used by the Lepchas for the instruction of their language) written in my font.

Lazong_Mainwaring_Rong.pdf (2.3 MB)

Didn’t we figure out how to reduce the number of ligatures, too?

Hi @blinkenlichten,

With my comment I meant that whan you exceed the 16 bits (65536) for lookup you can use the tag useExtention after the feature declatarion. allowing you to have a 32 bits (4294967296) limit insead of the 16 bits.

lookup <label> [useExtension] {
	# rules to be grouped
} <label>;

But you should keep in mind to do the same in all alternatives feature in order to avoid a overflow of the aalt feature.

So try to do as many lookup as neccesary to avoid overflow error.

Let me know if this clarify my point.

Best,

Nicolás

This did not work for me, unfortunately. Treating subjoined ya and subjoined ra as marks broke all the related ligatures. So, I had to revert back to the definition as letters.

Moreover, your specimen used dligs. Lepcha requires unconditional ligas, however.

Well, you are the experts, but I suspect that the difficulties may be due to the complex hop-around collation in Lepcha script. I’m attaching a very simple example for visualization. I only manage to get anchors working with one initial plus one subscript or one superscript. Beyond that, I failed to implement any ‘savings’.

Hi Nicolas,

I’m so grateful for your support. Anyway, good answers raise new questions:

  • How and where can I create lookups? I thought they are pre-defined by the OT specs.
  • Can I really by-pass the 64k limit of lookup 4 if splitting my thousands of ligatures into sub-groups?
  • Is the argument ‘useExtension’ (that’s what I tried earlier without success) or ‘useExtention’?
  • Where should I insert ‘useExtention’? (liga is the only feature I use)

I would appreciate if you could just treat me as first grader, at least for the time being. :slight_smile:

Best thanks!

I would go the other way, make your font work with the mark paradigm, which makes sense for subjoined glyphs.

Best thanks for your suggestion, mekkablue. Just to be sure:

You’re aware of the fact that subjoined ya and subjoined ra are subjoints by name only? In reality, they are attached at the right side of the initial glyph individually or in combination.

I didn’t suggest to treat the two ‘subjoining’ glyphs as marks. They where all ligated. But you don’t need all combinations with actual top and bottom marks as ligature.

Hi @blinkenlichten,

Maybe there is an easier way (for the machine) to do that. I am working in something similar. Can I work in the example that you wrote? May I ask you for the Unicode values of those characters? I will try to figure something out only using mark attachment and rearrangement, without extra glyphs.

Best,

Nicolás