Fontlab errors when modifications are made to font

Daniel Couper's picture

I'm having a problem making a basic modification to a font in FLS. I'm only learning FLS, so I assume I'm doing something stupid, but I can't nail down what it is.

I'm trying to modify the font Crimson, adding in a tabular oldstyle. I've already added two discretionary ligatures (no problems), and amended the OT substitution so that it correctly subs in ligatures and c2sc, and it all works great in-browser using font-feature settings (the main aim of the exercise).

I copy the oldstyle figures to a line in the private use area, set a width, name them, add a tnum1 OT class, then add a @pnum1 to @tnum1 OT substitution, then compile, at which point I get the "GPOS feature 'kern' causes overflow of offset to a subtable" fatal error. If I bypass the classes, and just substitute manually (zero by zero.tnumoldstyle &c.), the console tells me I have a script error somewhere else, despite the syntax being typed correctly throughout. It's driving me crackers, and I keep destroying perfectly good font files. Any advice?

hrant's picture

I hope you'll fix the spacing while you're at it...

hhp

Jens Kutilek's picture

I would suggest to start working from the source (VFB) files, instead of opening the fonts, because fonts are easy to mess up.

But apparently there are only FontForge source files available:
http://crimsontext.svn.sourceforge.net/viewvc/crimsontext/trunk/sources/

gargoyle's picture

The 'kern' overflow error is a fairly common one, but I'm not sure how adding oldstyle figures and related code would suddenly trigger it. Is it possible that you've also modified the kern feature, or added new glyphs to classes that are referenced by the kern feature?

charles ellertson's picture

"fairly common"?

There is essentially the same question on this very page. See:

http://typophile.com/node/97873

esp. John Hudson's answer.

oldnick's picture

Fontlab sucks. Fontographer sucks. FontLab succks. Eventually, DTL Kernmaster 2012 will come out…in 2013 or…whenever…

charles ellertson's picture

Maybe so Nick, but the kerning "problem" isn't due to the the font editing program, but the small tables (64K) allowed for in TrueType & then OpenType.

Let's say that OpenType sucks. Time for a new format.

gargoyle's picture

"fairly common"?

Yes, "fairly" meaning "to quite a high degree".

There is essentially the same question on this very page. See:
http://typophile.com/node/97873

Yes, and on many other pages going back years. However, in the case you cite, the poster clearly said that the kern feature had been modified. In this case, the font had already been successfully modified (and presumably compiled) without error, and the description of adding tabular oldstyle figures made no mention of any changes to the kern feature.

k.l.'s picture

Maybe so Nick, but the kerning "problem" isn't due to the the font editing program, but the small tables (64K) allowed for in TrueType & then OpenType.

It's both. Table design being based on false assumptions. And editing program not taking table design into account when generating AFDKO-syntax data from which the table will be compiled. Anyway, this is something that users, i.e. type designers, should not be bothered with ...

Jens Kutilek's picture

the description of adding tabular oldstyle figures made no mention of any changes to the kern feature.

My guess is that FontLab copied the kerning of the proportional OsF along with the glyphs to the tabular OsF. That would explain a change in the kern feature which leads to the overflow error.

The solution would be to delete the kerning of the tabular OsFs, they, being tabular, should have no kerning anyway.

It would be best to keep the kern feature code as it is (uncheck "Generate Opentype kern feature if it is undefined or outdated" in the FontLab options under "Generating OpenType & TrueType" → "Kerning").

I just tried opening Crimson-Roman.otf in FontLab, and while the existing kern feature code compiles fine, as soon as I regenerate the kern feature code (via the OpenType panel menu → Generate kern feature), it fails with the overflow error.

azxs's picture

Opting for an internet vogue is like building a store that may forever be open, even after you area unit asleep.Web Designing Asian country will produce for you merely netsite|the web site} you need! Our experience at building a Custom web style is sure to assist you build your distinctive whole identity. Our creations let\'s you harness your business within the web world. It helps:

charles ellertson's picture

I'm guessing that the old style figures you *copied* to the the Private Use area are in the original font with a name, but not an Unicode index (which is proper).

If you're using layout software that requires a Unicode index, rather than "copying" them to PU, just assign a PU number to them without changing the name. Should work, and since the kern feature as found in FontLab will be using the name, it shouldn't care that you've added a PU Unicode index.

Then follow Jen's advice.

BTW, as far as personal bias goes, if it was a font I was interested in, I'd just write a new Kern feature -- actually, I'd rewrite all the features, but that's because I have a stock set I've gotten comfortable with over the years. I think this not a bad approach for a user, whose primary concentration lies elsewhere.

Daniel Couper's picture

Sorry for the extremely late response to all the responses - I really should make sure I've followed everything up before going on holiday. Anyway. I had looked at all the other threads relating to the overflow error, and followed the advice, hence the original post.

This was just done to have a fully-featured OT font I could use live on a website to play with a wide variety of font-feature settings in modern browsers without tossing too much money at it - the reason Crimson was chosen was because most of what I would need is already present, unlike other free/cheaper fonts. Could just drop back to something good on Typekit, but then an element of control is lost.

@Jens, tried clearing the kerning data, and tried keeping the kern features as-is, but no dice, still throws the overflow error. But following @charle_e's advice, I seem to have managed to force it through. It then susequently chokes on further changes of any kind, so temporary fix at most. I think you're right though, and I need to rewrite the kern feature. More work initially, but at least I know I can then have something that will display. And yes, I do realise the current spacing is dubious @hrant, so I'll give it a go.

Thanks for the advice, it was very useful, and at the very least pushed me to learn in a bit more detail how OT tables store the data. Still want to scream at FL most of the time, but I see why it throws crap at me now

adelaroger's picture

I think the solution would be to delete the kerning of the tabular OsFs, they, being tabular.Anyways nice information thanks.
Customs clearance Adelaide

Syndicate content Syndicate content