#3170·Iosevka

[RFC?] Flat-hook `e` implementation problems

Author: Logo121Created Apr 27, 2026Updated Sep 3, 2026

In #3015 I mentioned splitting flat-hook e (i.e. migrating all e glyph-procs into using Arc/Hook classes) for a different PR, which at the time was mostly done but with some remaining problems.

Since then there has been a few PRs on lower-e.ptl which either conflicted with or complicated some of the decision I made on the module, so the migration code was scrapped.

I also don't have much time to implement anything now, so I'm leaving this as a reference/backlog/request for someone else to pick up.

Here are the issues that needs to be decided/resolved first:

Implementations around SubDF

In #2957 I opted for using Box for Arc/Hook bounds over DivFrame anticipating the deprecation of the latter (with LetterModel in #2725).

There are 2 modules that depend on the e shape (lower-ae-oe and iotated-a), both of which calculate a SubDF+shift for the e part, which needs to be converted back to Box before referencing e shape-procs again. This leads to some clumsy and inconsistent conversions (especially since not many other glyph-procs use Box).

This may be a broader problem with the overall code (having like 3-4 systems for specifying glyph-proc bounds), and may be a something that LetterModel resolves (or further complicates).

Handling of Swash

There are some process around suppressing hook swash that is only used in lower-e. I thought of scrapping it altogether, but there has been a few modification/extension to the swash behavior (e.g. #2845), which conflicts with this decision.

We'll have to decide on whether to:

  • Keep the Swash control, incorporating the logic (e.g. [SmallEHook]) into the Rounded hook forms
  • Generalize this swash behavior to other glyphs (e.g. whatever is happening with Open O vs Turned C right now)

There are also some hook behavior problems I've not completely sorted out, like I'm not sure if this is the correct behavior for existing glyphs: https://github.com/be5invis/Iosevka/blob/a8c568fe11fe3a336fa447ad6781683012127da6/packages/font-glyphs/src/letter/shared/arc-hook.ptl#L181-L196

Treatment of e and ə

Currently the serif of ə is controlled by variant selector of c. If flat-hook e is implemented (possibly along with Toothless/Toothed hook e), this means the hook terminal will have to be controlled by e.

If so, should the serif of ə be controlled by e or c?
The latter felt very hacky to me, so my plan was to disable Toothless/Toothed forms for e and make those variants only affect ə, which I didn't feel was better either.

Interpretation of

is currently implemented as e with an extra (small) arc, which assumes the hook to be fully rounded.

While it might be fine to just force the hook shape to be Rounded for this glyph, the original implementation is kinda awkward to begin with (doesn't attach properly to oblique/italic sometimes).

I had some ideas on how to reimplement this glyph (taking some of these forms as reference), but it also required some rewrite, which was the main blocking problem (before the conflicting PRs).

There's also ᶒę which attaches to the "last knot of e", which doesn't really work for non-round terminals. But if e don't have those "serifed" variants, it would likely be fine.


A preview of what my previous attempt looked like (without disabling serifed variants for e) Image

Image