Can't compile OT features

clauses's picture

I can't compile my OT features after some code cleaning. I get a new error about every time I try to compile from within Fontlab. E.g.

[FATAL] aborting because of errors:
syntax error at "feature"
[/Users/claus/Library/Application Support/FontLab/Studio 5/Features/fontlab.fea 2650]

and

[FATAL] aborting because of errors:
syntax error at "@lat"
[/Users/claus/Library/Application Support/FontLab/Studio 5/Features/fontlab.fea 1]

are the most common. Am I missing something here?

paul d hunt's picture

can you export your OT features and do a search for @lat check any lines that give you a result. it may be anything from simply not including a semicolon.

clauses's picture

There is nothing called @lat in the features. Only some groups called something with @latin...

clauses's picture

Karsten was so kind to have a look and found the error - a missing semi-colon after the kern feature. Sigh. I wish there was some better error reporting in Fontlab and MakeOTF.

oldnick's picture

syntax error is pretty specific: it indicates that there is a formal—or formative—error in the code. Debugging requires a modicum of attention to detail, wherein the devils reside...

clauses's picture

Oh come on! Syntax error - when is an error in the features not a syntax error? If the software in question would only call out the line where it chokes I would be happy. Alas.

oldnick's picture

when is an error in the features not a syntax error?

Misspellings or inadvertent transpositions aren't syntax errors: they are calls for elements which don't exist because of improper naming...

Mark Simonson's picture

It'd be nice if it just told you that you're missing a semicolon, but how does it know you meant to put one there? Instead, it keeps going past that point until it runs into something it doesn't understand, i.e., a syntax error. The missing semicolon was not the syntax error, but its absence led to one.

blokland's picture


 
Simply because I can’t resist mentioning this: in case of a syntax error in an OpenType layout features file, FM modules like DataMaster (‘auto’ features generation / latest build AFDKO 2.5) will indicate and locate (by line number) the error:
 
syntax error at "lookup" missing ";" [:features.txt 618]
HOT [FATAL] aborting because of errors
- end of HOT messages

 
FEB

Arno Enslin's picture

@ Claus

I just checked, how informative the error messages of Makeotf (belonging to the AFDKO 2.5 21898) are. You wrote, that you wish a better error reporting. But in my test I was contented with the error reports of makeotf:

syntax error at "feature" missing ";" [TestFont.fea 1469]
makeotfexe [FATAL] <TestFont> aborting because of errors
makeotf [Error] Failed to build output font file TestFont.otf.

Drücken Sie eine beliebige Taste . . . (Press any key)

1469 is the line number, in which the semicolon is missing. In this example it was the last semicolon of the kern feature.

And in the following example I have removed the last semicolon of a substitution rule:

syntax error at "sub" missing ";" [TestFont.fea 189]
makeotfexe [FATAL] <TestFont> aborting because of errors
makeotf [Error] Failed to build output font file TestFont.otf.

Drücken Sie eine beliebige Taste . . . (Press any key)

What was your problem with the report of makeotf? I am contended with the error report. It makes out the missing semicolon as problem.

In the following example I removed the word sub from the rule "ignore sub a' @all_without_space;". And the error message is:

syntax error at "a" missing { substitute reverse position } [TestFont.fea 188
]
makeotfexe [FATAL] <TestFont> aborting because of errors
makeotf [Error] Failed to build output font file TestFont.

Drücken Sie eine beliebige Taste . . . (Press any key)

In all three examples makeotf has posted the correct line number. And in all three examples it had been easy to make out the problem.

---------

I started makeotf with the help of a batch file:

@echo off
if exist TestFont.otf del TestFont.otf
if exist current.fpr del current.fpr
call makeotf -f TestFont.pfa -ff TestFont.fea -gf TestFont_GlyphOrderAndAliasDB -ga
del current.fpr
pause

---------

Just a secret (Not anymore now!) tip for the case, that you find the AFDKO too uncomfortable:

I am using it for the generation of the GPOS and the GSUB table only. When I have generated the OTF with makeotf I decompile the GPOS- and the GSUB-table (the GSUB-table as hexdata) with TTX, because TTX can damage the GSUB-table in certain cases. This requires, that you temporarily delete G_S_U_B_.pyc and G_S_U_B_.py (I have written a batch file for this, a switcher. Search for G_S_U_B_.pyc and G_S_U_B_.py in your AFDKO directory). And then I merge the two decompiled tables into the font, that I have generated with FontLab. It is absolute necessary, that the order of the glyphs in the glyph-order-file is matching with the glyph-index in FontLab, if you decompile the GSUB-table as hexdata.

blokland's picture

The FM modules have a modified version of the AFDKO under the hood, hence the similarities between the syntax error messages.

As an alternative for compiling, decomposing and merging tables using FL, TTX and the AFDKO, there is the option in OTM to compile binary OT Layout tables using for instance an ‘all covering standardized’ GSUB features file, like this one (my most recent file [I added some comments]; change the ‘txt’ suffix in ‘fea’ for OTM) and a font specific (of course) GPOS file. One can test this with the Light versions of OTM (saving is disabled though).

An option for FL users is to compile the GPOS in FL and to add the GSUB with OTM. The character set does not have to correspond with the GSUB features listed; all obsolete features will be removed after compiling, just like in the FM modules. Of course, the naming conventions in the font and the features file should match.

If everything goes well, one of the coming versions of OTM will support this functionality on batch level via a command line.

Admitted, both TTX and the AFDKO are costs-free and OTM isn’t, but when it comes to convenience, time saving, reproducibility and standardization, OTM clearly wins, I reckon.

FEB

Arno Enslin's picture

@ Frank

If you merge in the GSUB table with TTX, the character set (the index!) likewise has not to correspond in the very most cases – except you make use of my trick. My trick with the hexdata is helpful in rare cases – if the GSUB table contains names for the stylistic features for example. TTX does actually not support that, but the latest makeotf does.

And with regard to OTM, it is unfortunately out of my budget as amateur. (And the money, that you wanted to have for the last update – no, that would be too much for me.) In relation to the time one needs for designing a font, compiling the features with the AFDKO is almost nothing. You only have to understand it one time. With a strategy the AFDKO is not really uncomfortable.

Arno Enslin's picture

I just have seen, that the AFDKO contains a program called sfntedit, with the help of which you can extract and insert tables. So there is no need to change anything in TTX.

k.l.'s picture

[Have a look at Claus' initial post. Error message 1 points to line 2650 which is close to where the actual error occurs, so as Paul Hunt wrote, saving the features and inspecting the according line(s) in a text editor helps. No need for any roundtrip except if you like making things more complicated than necessary.]

Arno Enslin's picture

@ Karsten

I would not call it making things more complicated, because generating the features with the AFDKO has more advantages.

k.l.'s picture

[Depends on the feature file. With most fonts, including those in question: No advantage.]

Arno Enslin's picture

@ Karsten

I don’t directly contradict to you, but I would like to complement:

1. In my opinion it is better to program the features in a text editor. I comment my features. If I import them in FontLab, it depends on the position of comments (before or after a feature), where they are displayed on the feature panel. Sometimes a comment is regarding to a group of features. But in FontLab it looks like the comment is regarding to one feature only.

2. The languagesystem statement "DFLT dflt". FontLab is not able to compile it, isn’t it?

3. Stylistic set features and names for stylistic set ('ss01 - ss20') features are cool, but not supported by FontLab.

4. If you use the AFDKO only, if FontLab does not support a special thing, you need more time to make use of the AFDKO, when you need it. So why not directly use it? (The training aspect.) Doing anything from the command line is wrongly scaring for many people, because it is not difficult, but just a bit unwonted. It is not a loss, but a win of comfort, if you learn how to use the command line and how to program batch files.

5. The AFDKO is free software and partly OpenSource. If you have not FontLab, but TypeTool or another font editor only, that is unable to compile features, you have to use the AFDKO, if you want to put OT features into your font. I would say, that the syntax, as it is expected by the AFDKO should be the standard, when code snippets are posted here. As more people use the AFDKO, as more people explore its possibilities. When others wait for a new version of FontLab with a later version of an OT compiler, you and me always have the latest. The AFDKO furthers the competition between the developers of software.

386sky's picture

Compiling fractions feature:
[FATAL] aborting because of errors:
syntax error at "}"
[E:/문서/FontLab/Studio5/fontlab.fea 270]

Notice the backslashes are now slashes. Typophile doesn't work with any other name than the button for Post. It should be fixed however Arial and TNR includes no support for IPA added to Version 5.0.

Syndicate content Syndicate content