Just a quick guess: Have you put semicolons at the end of each line where necessary?
As far as I remember, not doing so results in that kind of unspecific error message.

The OT compiler should show the number of the line which causes the trouble.

In the OT Panel, save the features, open the “.fea” file in a text editor (activate line numbering), and check if the mentioned line or the preceding contains any error.

Like I said, it’s compiling fine; I can compile the OT code and see the results in the preview panel and it all behaves as it should.

The problem occurs only during the final output stage of the font itself, and the only error message/info I’m getting is what I pasted in my original post, which is very vague and seems to contradict the fact that I can compile it and see the results in the preview panel just fine.

As you observed, sometimes FontLab’s error messages are remarkably unhelpful; just for grins, check for open contours...

Since the facts we got are few, all we can do is — guess. (Might even be that some value is missing in the FontInfo. But that’s just another guess.)  :))

My first attempt at generating the font did indicate that there was one glyph with an open contour. FontLab highlighted it in red, I fixed it, and the error went away. I’m still left with this strange and vague OpenType issue, however, and as a result my font is still “unbuildable”.

No guarantees, but maybe this will help: snoop around at the location (folder or subfolder, directory or subdirectory - call it what you will) where you expect the generated OT font to be built. There may be an uncompleted build residing there with a goofball extension (look for something like “[name of your font]._tf”). If so, remove it or rename the extension (try “[name of your font]._tf_fail”) and then retry your generation effort.

Such quirky behavior struck me thrice only when using FLS 5.0.0 on Win2K and the above procedure cleared the problem. Even though your difficulty may finally be different, I hope this helps.

Regards,
Ernie

ERROR: There was a problem while compiling OpenType font. Final .otf font is not saved. Please, check OpenType features definition for errors

Can’t say I’ve ever had this one, but to check if it is true, save the features as has been recommended, then reset the features in the FontLab OT panel so there are none. If you can now make an OT font, then you know the problem is (most likely) in the features.

As I remember debugging 101, you add one thing at a time until you find the problem — or alternatively, keep splitting the file in half until the problem is isolated. As has been suggested, by importing the features file, you can work in a text editor so you can see better, change file names etc. etc.

I saved everything out to a .fea file, then cleared out all opentype features and classes within the file. I closed the program, deleted the backup .bak files, opened it back up, and tried to generate an OTF without doing anything else.

Same problem. It seems that even with absolutely no OpenType features whatsoever, this is still a problem. Just as a sanity check I made a TTF, which of course worked.

For some reason, though, I get nowhere with OpenType.

Some idea from an amateur (maybe very lame, but hey...)

Have you tried to do the numr/dnom replacement not using classes? Yes, it is tedious to make everything by hand, but (I guess) this might help... I have already stumbled upon this, and sometimes I prefer making OT entirely by hand - on a single character replacement basis, using classes only when it is absolutely impossible to avoid them. (Because debugging class errors is really close to reading uncommented ANSI C :)

Another idea: try to add the features directly to the already generated TTF - and regenerate it as OTF?

Also it is (funny, but yes, why not?) not a bad idea to restart the PC :) And maybe check with other versions of FontLab, even maybe do an upgrade, if it solves the problem... (If you have some old FL 4.6, maybe it will provide hints where the problem is hidden). But at this stage the things are already becoming too heavy...

In FL preferences > Generating OpenType PS, did you enable ’Use subroutines to compress outlines in the CFF table’?

Might help.

Artur

Artur,

+100
Disabling this option will help for sure.
And updating FL to 5.0.4 is recommended too.

Alex Petrov

Alex,

Perhaps you can give us some indepth information on this function and why it solves this particular problem?

Thanks,
Artur

Here is what I would do . . .

Take an old Type 1 font you’ve used for years.

Read it into FontLab.

See if you can make an OpenType font from it — just read it in (make sure there are no parens in the copyright line) and see if you can generate an OT font.

If not, likely there is some problem with your installation of FontLab.

If so, the problems is likely with your font.

If it seems to be in your font, make a copy & throw away everything but two letters — the space and something else, say “A”. See if you can make an OTF font. If not, remove the “A” and try a “B”.

If this initial test doesn’t work, you need a guru beyond me, but likely someone here can help.

If this test does work, make another copy of the and remove half the lettes, & see if you can generate the otf font.. If not, keep removing half the letters until you can. If it is a single letter, pretty soon, you will have it isolated. If it is more than one letter it will take longer; I’d use an “addition” rather than a “subtraction” procedure (i.e., keep adding to what works).

One thing you might try first is to make the OT-TTF font, read it back in, change the curves to PostScript, and see if THAT will let you generate an OT-CCF font. But my guess is it won’t.

Good luck

Artur,

the Adobe AFDKO code that FontLab Studio uses to build OpenType fonts has several bugs, one of them involving subroutines. This has been fixed in the standalone AFDKO but Adobe also changed other things in AFDKO making it impossible for a simple fix on our end. We will incorporate the improved AFDKO code into the next major FontLab Studio release though.

Adam

Adam and Alex,

I’ve heard more suggestions recently about turning off this “Use subroutines to compress outlines in the CFF table”, could you tell me more what exactly could cause a bug to come up when using it? Is there a way I could test a generated OTF to find if there was a problem or not?

Thanks,
Andy

Adam,

Would you recommend turning off the “Use subroutines to compress outlines in the CFF table” option at all times or only when there’s a problem generating the font?

Many thanks,
Andy

This is not a feature file problem - note that Andy tried removing all features and had the same problem.

All that CFF subroutinization does is make the font file smaller. It does this by finding bits of contours that are common to several glyphs, and sharing that bit between them. Think composite glyphs, but sharing just parts of an outlines. With some fonts, this can make the CFF table as much as 50% smaller, although it is more common to see size decreases of around 20-30%. It is rare to have a problem because of this; the bugs I know of happen when there are > 32K subroutines, and you usually run into this when you have > 10,000 glyphs. However, it does no harm to turn subroutinization off. The size difference of the final OTF font is usually don’t matter on modern systems, unless you are targeting mobile device.

The approach suggested above by charles_e on 2.Nov.2007 6.13am seems the most practical. to me, although I’d do it the other way around; make a new font, then add the letters in gradually, then fix the FontInfo and other meta info to match the original, then add features.

- Read Roberts

I had this same problem and I had no OT features, I was simply adding cyrillics to an existing typeface. I had renamed the cyrillic characters from the “afii” names to a more proper name, and when I went back to the “afii” names and generated the typeface I got “The feature file OS/2 overrides TypoAscender and TypoDescender do not sum to the font bbox size!”. After making that change the typeface generated fine. I have no idea why that worked, but it did.

Best of luck.