Line numbers in MakeOTF errors

I often get MakeOTF errors after removing glyphs because they are still referenced in some manual feature code. Which is fine – it’s my job to fix this.

The “Show” button is a great help for quickly fixing the code but usually, it jumps to the line after the one that contains the error, in manually written classes in particular. Similarly, the error message quotes this line that does not contain the error. I assume this is probably how the parser works but it can be very confusing to the user.

In this example, the error is in line 71, not 72.

Would it be possible to handle this in a more user-friendly way? It would be great if the “Show” button really jumped to the line that contains the error.

Thanks!

2 Likes

Could you send me the file for testing.

That’s one of these things. Technically, the error often (not always) comes after the actual miscoding, but only when the expectation of the interpreter is not fulfilled. That is how makeotf works when it comes to error handling. I wonder what Glyphs could do. Parse and reformat the error message to in line 71 or 72?

Looks like this could be the best solution. I assume Glyphs has to parse the error message anyway when determining the line to jump to after “Show”?

On the other hand, this is obviously a bug in makeotf so maybe trying to fix it upstream makes more sense?

Just played around with the makeotf data in the temp folder, manipulating the .fea file to see whether there is a workaround by tweaking the feature code. Adding a space at the end of each line, changing line breaks to CRLF, even inserting blank lines, it all doesn’t help. This is an odd behaviour: the error should be obvious at the first white space – which teminates the name of the (missing) glyph – not when the next one starts.

1 Like

the problem is that makeOTF reports the error for the token next to the actual problem. That token can be on the previous line (as in your case) or on the same line. So just subtracting one line is not going to do a better job.

Is there any chance this could be fixed in makeotf? I had a look at the source code today to find the root of the problem but the code seemed very cryptic, didn’t get vry far.

I did try to fix a few things here and there and mostly I was not successful…