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.
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.
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.
That is mostly right.
- 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…
- 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.
That indeed doesn’t look right. I’ll have a look.
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.
I would name it
bottomright_BUR With an underscore so it knows it’s a variant of
Thanks, but changing the anchor name doesn’t help with this problem.
Here’s an example from Khmer. This used to work fine.
The mark preview plugin is showing correct anchoring. The first mark anchors on the bottom anchor. The second mark anchors on the bottomright anchor of the first mark.
However, when I export, the second mark is anchoring directly on the base.
Whatever changed in the OT compiler, please revert it back as I can’t generate SEAsian fonts correctly.
Bendy, can you send the .glyphs file to support at this domain? There indeed were some glitches in mark attachment lately, but all should be fixed by now…
Thanks, just emailed
I’ve got another strange anchor problem, I haven’t seen this before. I’m on v3140 and this time it’s Khmer:
With Mark Preview, we see the coengKA is correctly centred on the second bowl of the ញ
but when I export the font, it is sitting on the anchor named ‘nno’ although that mark doesn’t have a ‘_nno’ anchor
Can you send me the file?
I’ll send an invitation to the GitHub repo, if that’s ok. There are a lot of associated files to keep emailing, and as we saw the other day we’re running into version issues on email
Yes. That is OK.
I’ve tagged you in the issue where I noted the problem. You’ll see the problem in the string
ញ្ក ញ្ខ ញ្គ ញ្ង ញ្ច ញ្ឆ ញ្ជ
All those belowmarks should be centred on the second bowl of the ញ