OpenType errors

When writing OpenType rules, the error flags are often overlapping the code or get truncated, so I’m having to constantly resize the window to see what I’m doing.

You can click on an error icon to show its full error message.

1 Like

Also it seems to give up reporting errors after the first block or two:

That may very well happen since it can be difficult to tell whether an error is a new error or just a result of the previous erroneous code. Or maybe there are too many errors and Glyphs stops after a certain number to maintain performance.

1 Like

Thanks, that makes some kind of sense. Still, the overlapping errors bother me.

One other thing, when the popup appears so you can choose a class name, they’re in a random order, not following the class ordering that I’ve chosen, and not alphabetically.

I believe the suggestions are ranked by an internal score that also considers capitalization and other matching criteria. Perhaps it would be possible to also have definition order factor into the listing, maybe @Grzegorz_Rolek knows more about that.

1 Like

That is mostly right.

  1. In case of syntactic errors, any further errors might get skipped until the parser gets back on track with the context. But the errors here are of semantic type. Those are not limited in any way, except…
  2. No matter the error type, Glyphs stops after 20 errors or so (globally, not per feature) not to overwhelm people with hundreds of errors, especially that such high error count is most likely a result of some previous error propagating far beyond its original scope, or the same error repeated many times (like unknown glyphs used repetitively).

I’ll have a look what can be done with the overlapping inline error. One solution would be to break the line a bit earlier if the overlapping happens, thus make more space for the inline error, but that could result in an unexpected line jump when the error appears — something I’d rather avoid.

1 Like

That indeed doesn’t look right. I’ll have a look.

1 Like

Did something also change with the OT compiler for mkmk attachments?

I can’t find the thread where we discussed it a while ago, but I know Georg relaxed the mkmk anchor attachment which was previously being restricted by the anchor names. Now it’s a problem again, I think.

Here I want the first subjoined glyph to attach to the bottom anchor, and the second subjoined glyph to attach to the first subjoined’s bottomrightBUR anchor, but because the first mark doesn’t occupy the base’s bottomrightBUR anchor, the second mark is just attaching to the base instead of going below the first subjoined.

First line is correct, second line is attaching the second mark to the base instead of the first mark.

Screenshot 2022-10-02 at 10.28.14

I would name it bottomright_BUR With an underscore so it knows it’s a variant of bottomright.

Thanks, but changing the anchor name doesn’t help with this problem.