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.

[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?

[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

  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

  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?

[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.

[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.