Errors when importing an existing Adobe OT font to FontLab

charles ellertson's picture

I have a problem using FontLab & Adobe Minion Pro Regular.

If you simply open the font & try to compile the OpenType Features, you fill up the output error panel. I think the significant part of the message is:

GPOS feature 'kern' causes overflow of offset to a subtable (0x12c6c)

Since I

John Hudson's picture

FontLab decompiles the actual OpenType Layout tables in the font, but cannot always recompile them because of limitations in the decompiling/recompiling process. Subtables are not recognised during decompiling, for instance, or the font contains OTL lookup types that the Adobe FDK code in FontLab cannot compile.

twardoch's picture

FontLab 4.6 is great for developing new OpenType fonts but if you're trying to modify somebody else's OpenTypes, you will likely hit the problems that you describe.

Also, there is no universal solution for that. Not all OpenType Layout features can be expressed in the Adobe FDK for OpenType source code that FontLab internally uses.

One of the new features of FontLab Studio 5 will be the ability to leave OpenType Layout tables in binary form when opening OpenType fonts. FontLab will have an option to decompile the features or not, and when generating the font, you will be able to select whether to use the stored binary tables or the features recompiled from the source.

This will enable the user to perform smaller modifications to existing OpenType fonts (changing glyph names, adding glyphs, modifying outlines) even if the OpenType features embedded in the font cannot be expressed in source code -- for example for Arabic fonts that use GPOS lookups.

But this will be in FontLab Studio 5. With FontLab 4.6, the only sensible solution is to open the OpenType font in FontLab, completely reset the features in the OpenType table, perform the modifications (do not reorder any glyphs!) and generate a new OpenType font. Then, use TTX (http://www.font.org/software/ttx/ and http://www.letterror.com/code/ttx/ ). Convert both the old and the new fonts into .ttx files by dropping them onto the TTX icon. Open them in a text editor (e.g. UltraEdit-32 on Windows, BBEdit on Mac) and copy the XML code for the tables GSUB, GPOS and GDEF from the old font's .ttx file to the new font's .ttx file. Finally, convert the new font's .ttx file into an OpenType font by dropping the .ttx file onto the TTX icon.

Regards,
Adam Twardoch
Fontlab Ltd.

twardoch's picture

I wrote: "reset the features in the OpenType table", but I meant: "reset the features in the OpenType panel".

Adam

charles ellertson's picture

Adam, thanks very much.

The problem, of course, is the approximately 250,000 kerning pairs in this font (of which I

Thomas Phinney's picture

It seems to me that the problem is that FontLab's decompiling can't handle subtable breaks.

* * * *

Charles,

"The problem, of course, is the approximately 250,000 kerning pairs in this font (of which I

twardoch's picture

"If you elect not to decompile the features, I imagine you can

charles ellertson's picture

>> This is a fundamental misrepresentation or misunderstanding of the way class kerning works. >>

Only if you take file size as the only important parameter

>> In such a situation, using class kerning to represent your 15K pairs, even if it results in 250K virtual pairs, is usually more space-efficient than simply putting in 15K flat pairs. >>

I

Thomas Phinney's picture

Actually, no, I'm not taking file size as the only important consideration. But performance isn't any slower with class kerning than with flat kerning, either.

Note that the nightmare around untangling and rebuilding the kerning has to do with FontLab failing to re-instantiate subtable breaks. This would be a problem regardless of whether you use pairs or classes.

"It does seem to me that if someone paid more attention to the classes, the 15,000 pairs wouldn

Thomas Phinney's picture

Oops. In that last sentence, replace "size-independent kerning" with "non-contextual kerning."

T

charles ellertson's picture

A subtile difference, I suppose.

As to the difficulties of efficient class-based kerning, while I haven't done *class-based kerning*, I do have some experience with something similar. When we first used Plain TeX, you were limited in the number of kern + ligature commands you could have. The limit was only on the number of commands, so if you wrote "kern f, d c e o q -5" (I've forgotten the syntax), you had five pairs with one "command". Of course, we used this with a Linotron 202 & it's proprietary fonts, & there was no reason to assume that d,c,e,o,q all had the same left sidebearing (usually didn't), even though they all have the same shape. You'd have to run everything off & take a look to be sure. A lot of work.

Cheers, C

Syndicate content Syndicate content