Bracket alignment issue

[TonCherAmi]

• Font version: 1.14.1
• Font variant: Iosevka with cv37 enabled
• Operating system (name and version): Gentoo Linux ~amd64
• Applications using Iosevka: GNU/Emacs 26.1, st 0.8.1

---

There appears to be an issue with vertical bracket alignment when using Iosevka with certain character heights.

Namely, when using GNU Emacs with character height of 14 (set by evaluating expression (set-frame-font "Iosevka:pixelsize=14")):

As well as st with the same character height:

The issue seems to disappear if the character height is increased to 16:

In Emacs:

As well as st:

I have also not encountered this problem in any other font I tried:

e.g, Pragmata Pro Mono in Emacs, character height of 14:

Monaco in Emacs, same character height:

---

Hopefully this can be fixed, as it is quite an eyesore and makes working with certain languages a rather unpleasant experience.

[be5invis]

I think it is something with TTFAutohint. Perhaps you could use this tool (again!) to re-calculate or remove the hints and try out.
I do not want to do manual hint (though I wrote IDH), it is horrible.

[be5invis]

cc. @lemzwerg

[lemzwerg]

Yes, chances are high that this is a hinting issue. Reason is that {} and [] are not aligned to any blue zone; if there are slight differences in height and/or depth rounding might cause alignment to different vertical pixels. I suggest to use a control instructions file for fixing this.

[be5invis]

@lemzwerg
Does TTFA support defining custom alignment zones? All the brackets are aligned to two zones (parenTop and parenBot).
You know Iosevka is created in an automatic manner and I cannot make sure that point indexes are preserved across versions.

[be5invis]

@lemzwerg
Wait I read the docs of TTFA... It does not calculate any alignment zones for punctuations?

[lemzwerg]

Correct. Alignment zones are limited to script-specific characters, and right now there are no custom alignment zones. Patches are welcome to improve that :-)

[be5invis]

@lemzwerg
Brackets ()[]{} and some blob punctuations (like +) are symmetric so we could round its halfway-height virtual line first, then round its extrema.

[lemzwerg]

There are ideas to add 'character knowledge' to FreeType's auto-hinter (and thus to ttfautohint), for example that 'i' has a dot which must be always separated, or '~' which needs a wiggle at least two pixels high, etc., etc.

The symmetry properties of brackets might also be part of that knowledge database.

I won't work on such a feature in the near future; I would be glad if anyone could help...

[be5invis]

@TonCherAmi
For now, I'd like to add an unhinted build in the package (prebuilt) as a workaround for this problem.
Fixing this need a lot of long-term work with @lemzwerg.

[TonCherAmi]

@be5invis sounds good, I'd be glad to test it out.

[TonCherAmi]

@be5invis hey, I've tried the unhinted build and there doesn't appear to be any difference. However if I switch Xft.hintstyle from hintslight to hintnone the alignment seems to be in order (though it looks atrocious overall), this is true for the unhinted build as well as the normal one. Not quite sure what to make of all this.

[be5invis]

@TonCherAmi You used Freetype's auto hint?
This is the native hints under 14ppem:

It looks different from your image.
I'd like to close this issue since Freetype's light auto-hinter is out of my control.
Hmmm, maybe you should really ask @lemzwerg about your problem, because the auto-hinter is also made by him 😶.

[TonCherAmi]

@be5invis, well, I'm not really sure, I have Xft.autohint disabled and Xft.hinting enabled.

[be5invis]

@TonCherAmi Your image is inconsistent with my results (taken from VTT). So maybe Freetype affected your hints.

[TonCherAmi]

@be5invis so is Iosevka supposed to be used with all Freetype hinting disabled? It looks really blurry that way (both hinted and unhinted builds).

[be5invis]

@TonCherAmi
Iosevka is designed to use its built-in hints. Not sure what option controls whether Freetype should read the built-in hints.