RFC: Drop serif-only variants in a future release

[be5invis]

This plan may change after discussion.

Currently, Iosevka have a lot of character variants that only differs around serifs. And in parallel, it have the "Sans/Slab" switch. This makes a lot of confusion and inconsitencies, and since most of the serif variants are introduced when making the "motion serif" glyphs for SS17, I am planning...

• Drop all the serif-only variants (which includes almost all "motion serifed" variants), except...
  • Variants for narrow letters (I, i, l, j, and maybe f). For these variants serifs make significant shape changes.
  • Variants for C/c and S/s.
• SS17 will be removed, or "reduced" to not include serif variants.
• I might create a new "semi Slab" family that contains partial serifs that creates a top-left to bottom-right motion.
  • Being a more "Stylish" subfamily?

Some alternatives:

• Implement "Iosevka Slab" entirely using character variant system.
  • Too complicated, there are too many letters to add the serifed variant in parallel to the original.

[Logo121]

Is there a more comprehensive list of what gets dropped and what doesn't? I noticed that r also gets changed a lot with serifs in the current style sets but is not kept here.

Also, I suppose SS16 will be greatly affected by this as well.

---

I don't personally use CVs (or even Style Sets) that much to have a strong opinion on this, but from looking at the previous issues, the amount of requests raised for motion serifs is not insignificant either.
I'd lean towards at least keeping the motion serif forms in some way, even if not as CVs.

Maybe the alternative/compromise is to reuse the "Slab level" idea scrapped in #693 (which was dropped in favor of having them as variants anyway), so that it aligns with the Sans/Slab settings. That would keep the motion serifs as a build parameter (like SLAB in the code) instead of as different variants, which may help with the consistency?

And I guess slab levels can be further "modularized" (if it is worth the effort) to allow fine-tuning serifs by feature (e.g. separating top-left and bottom-right motions, attached to a vertical/diagonal/horizontal stroke), which can also accommodate different semi-slab forms like these:

This wouldn't completely resolve the problems with recreating SS17, considering that they are not exactly consistent either: But it would be better than dropping support entirely I guess

[be5invis]

r will be considered as a narrow letter so it will have serif variants. Yes SS16 might be influenced too (for lowercase) -- so maybe SS16 and SS17 will be both removed (or reduced). -- To be honest, PT Mono itself is a sort-of sans-serif hybrid, while Recursive Mono itself is very "Stylish". I doubt whether initially adding support to these is a correct decision.

[pv4]

Hello!

Do I correctly understand that after the proposed change, e.g., the capital latin A and capital latin K would only have 2 variants each (curly and straight)?

If so, my only wish is to make the new variants (for all letters) more consistent in look.

Example 1. By default currently italic cyrillic lowercase ka is currently top-left-serifed, whyle italic latin lowercase k is cursive. I personally don't like the cursive variant and would prefer a non-cursive one. AFAIU there would be only one variant WRT serifs. Would it be top-left-serifed or top-left-and-bottom-right-serifed? Imho they should be the same.

Example 2. Currently italic cyrillic lowercase en is top-left-and-borrom-right-serifed. So the k's from example 1 should actually be top-left-and-bottom-right-serifed as well.

Example 3. Currently italic latin lowercase a/d/u have a bottom-right tail while italic latin lowercase n/m have a bottom-right serif. I might be pretty wrong here, but for me it looks like an inconsistency and in my builds italic-slab variants of a/u/d have bottom-right serifs instead of tails. [default variant is above, my variant is below]

Example 4. By default sans italic variants have a/d/u with bottom-right tails and tailless+serifless n/m . For me it also looks like an inconsistency, so my builds have tailed n/m. And here arises an issue with characters that don't have variants at all. Times ago cyrillic lowercase en/el/yery didn't have variants so the only way for me to get a consistent look was to make all italic lowercase characters tailless+serifless. But that would make italic variant to be just a copy of an oblique one which I didn't like. Actually, I got what I wanted with issue #972 . But what about people using other languages? I don't know. [default variant is above, my variant is below]

As a result, I created a style that (aside of making slab/sans oblique/italic variants different) looks as consistent as possible even taking into account characters that don't have variants. My empirical rules are:

• uppercase slab letters are full-serifed, be they upright or italic
• upright slab lowercase letters are full-serifed
• italic slab lowercase letters are motion-serifed (not tailed)
• uppercase sans letters are serifless/tailless be they upright or italic
• upright sans lowercase letters are serifless/tailless
• italic sans lowercase letters are tailed

Let's return back to our story now.

• The current default Iosevka variant set is somewhat balanced between a. having consistent letters and b. clearly differentiating italic/upright (above all) and sans/slab (in much less degree).
• The current variant system allows me to customize Iosevka to make it a. have fully consistent letters, and b. being absolulely clear whether a letter is italic or upright, sans or slab.

So, my only wish is to not lose the ability to get the consistent font with clear difference between italic/oblique.

After all, I have to say that's just my own opinion that could be wrong. I'm not a font expert, demonstrated by issues like #1258 .

By the way, when are you going to implement this (if you will). Is it near future or far future? Couple of weeks, couple of months, a year or so?

[Logo121]

(See, that's what I had about a modularized serif system, which can definitely help with the above issue)

Though I guess a problem with this is the fact that some people actually want the inconsistencies for the sake of differentiation. Mononoki, as mentioned in #622, does this (has top-left slab) for D and B (to differentiate from O and 8 I suppose), even though it is not necessarily a serif (or even motion-serif) font.
It does not have serif for P, even though it would align with D and B, probably just because it's not needed.

So it's likely not a problem unique to the styles SS16 and SS17, and it might not be a problem unique to serifs either (except for the Sans/Slab switch issue which is unique to serifs)

I guess a long term target, if serif variants are to be dropped, is to come up with a way (independent from CVs) to decide systematically when to add serifs to a character or not (sorta like splicing different styles but at build time). Not even sure if that is possible though.

[be5invis]

To @pv4 : This change may happen in version 24 or 25. For Sans Italics, the tails is added for only the bottom-right of a "bowl" or "enclosure". Adding tails to a "standing leg" just look strange to me.

[AndydeCleyre]

I don't well understand the proposal, but in case this is a useful data point (well, anecdote), I usually build with the following:

$ rg serifless vars.yml

charvars

```yaml capital-a: curly-serifless capital-c: serifless capital-e: serifless capital-g: toothless-corner-serifless-hooked capital-h: serifless capital-j: serifless capital-l: serifless capital-n: standard-serifless capital-r: straight-open-serifless capital-s: serifless capital-t: serifless capital-u: toothless-rounded-serifless capital-v: curly-serifless capital-w: straight-asymmetric-serifless capital-x: curly-serifless capital-y: curly-serifless capital-z: straight-serifless-with-crossbar b: toothless-corner-serifless c: serifless d: tailed-serifless h: straight-serifless j: serifless k: curly-serifless m: short-leg-serifless n: earless-corner-tailed-serifless q: earless-corner-diagonal-tailed-serifless r: corner-hooked-serifless s: serifless u: toothless-rounded-serifless v: curly-serifless w: cursive-serifless x: curly-serifless y: curly-serifless z: straight-serifless-with-crossbar capital-gamma: serifless cyrl-capital-ka: curly-serifless cyrl-ka: curly-serifless cyrl-capital-u: curly-turn-serifless cyrl-capital-ya: straight-serifless cyrl-ya: straight-tailed-serifless seven: curly-serifless ```

$ rg serifed vars.yml

charvars

```yaml capital-b: standard-interrupted-bilateral-serifed capital-d: more-rounded-unilateral-serifed capital-f: top-left-serifed capital-i: short-serifed capital-k: curly-top-left-serifed capital-m: hanging-motion-serifed capital-p: closed-motion-serifed p: eared-motion-serifed lower-iota: tailed-serifed cyrl-capital-ze: unilateral-serifed cyrl-ze: unilateral-serifed cyrl-en: tailed-top-left-serifed ```

[be5invis]

@AndydeCleyre It means in a future releae (25?) all the variant names that has serifless or serifed will disappear. For example, d will only have a variant called tailed that its serifs will be controlled by SLAB or other variables (i am still refactoring the code to make this realizable).

[AndydeCleyre]

Thanks!

its serifs will be controlled by SLAB or other variables

Will it still be possible to have some characters with serifs and some without, in a single build? Or will those mentioned variables be globally applied?

[Logo121]

That is the part that is under discussion here. There are probably some ways to implement a partial serif system that is "good enough" for most use cases, but otherwise for now parameters like SLAB are mostly applied universally (or based on some general rules at least)

Ideas on how serifs could be applied are definitely welcome.

[be5invis]

@AndydeCleyre I am still thinking the way to do it -- perhaps it will be driven by another object in the build plan (serif-variant-override?) to provide fine-grained control of the serifs.

[Lieutenant-L-T-Smash]

The ability to create a mixed-serif build seems pretty important. The customizability is the big selling point of Iosekva. Reducing that is going backwards, no? Plus, I have seen fonts that used a mixed-serif approach for style and legibility.

As an aside, what even are "motion serifs"? It's not a term I've seen elsewhere.

[be5invis]

@Lieutenant-L-T-Smash The term "motion serifed" denotes haveing partial serifs at certain corners (like only at top-left). I do not want to drop the ability to build partially serifed fonts. Instead, I plan to separate it from the conventional variant system, so we could have fonts with significantly less glyph quantity (and file size) and faster build speed. We may have another variant "dimension" that controls the serifs of each glyph.

[jmcwilliams403]

Something I thought I'd mention: Currently, normal selection of such partial serifs for the case of ascii digits isn't supported without building the font as fully slab‑serif, with the exception of 7 for some reason.

[Logo121]

Something I thought I'd mention: Currently, normal selection of such partial serifs for the case of ascii digits isn't supported without building the font as fully slab‑serif, with the exception of 7 for some reason.

Not all serif forms exist as variants.

Only those that already had some implementation of partial serif as a variant (e.g. for Stylistic Sets) will get serif variants (see commit e93d87a), since the purpose of the rectification was to make variants more consistent, to transition into the "buildup-based" variant system.

It's probably a temporary change before removing slab-only variants from the CV system altogether anyway.

[be5invis]

I am going to close this for now, as after we refactored the variation generator maintaining the variant list is no longer a very big problem. The only real problem now is the glyph count, but there are still some room for more glyphs, and the quantity of variants won't grow too fast in the near future. I may reopen a similar RFC when the glyph count goes too high again.