Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consolidation of Glyph Variants Requests #140

Closed
10 of 15 tasks
be5invis opened this issue Dec 29, 2016 · 92 comments
Closed
10 of 15 tasks

Consolidation of Glyph Variants Requests #140

be5invis opened this issue Dec 29, 2016 · 92 comments
Labels
✒️ Glyph Shape Priority 3

Comments

@be5invis
Copy link
Owner

be5invis commented Dec 29, 2016 •
edited
Loading

  • Clearify #
  • More curly {}
  • Sulzbacher Form ß
  • @ in four-fold
  • @ like that in Fira
  • “Hooky” t
  • Percentage with rings (%)
  • Ampersand (&) with open contour
  • Variants for 1
  • Square puncatuation dots : ., ,, :, ;, ?, ! and quotes
    • Do we need to break into two selectors? one for . and one for ,?
  • Straight/curly y
  • Rounded box-drawings (maybe a non-OT selector)
  • Small caps by default (with c2sc feature?)
  • Flat tail t / Angular t
  • Force-serif 7
This was referenced Dec 29, 2016
Closed
Closed
@p-e-w
Copy link

p-e-w commented Jan 15, 2017

Thumbs up for modifying {} – their curvature too closely resembles () and at small sizes they are hard to distinguish. Input Mono is an example of a font that leaves no doubt which type of brackets is which.

@be5invis be5invis mentioned this issue Jan 15, 2017
Closed
@be5invis
Copy link
Owner Author

So, @p-e-w, do you like this?

image

@slice
Copy link

slice commented Jan 15, 2017 •
edited
Loading

@p-e-w I agree. I don't like the close resemblance to (.
@be5invis Very nice! Though, I'm not sure how this would look like in real code.

@be5invis
Copy link
Owner Author

@p-e-w @sliceofcode Hmmm...

image

@slice
Copy link

slice commented Jan 15, 2017

@be5invis That looks nice. Although I prefer the tip of the brace (I don't know what it is called) to extend more instead of being short, like in Monaco:

20170115_102407_dyg

That's just my personal preference though, the font looks great 😄 If you don't mind me asking what colorscheme and text editor is that? Looks great with Iosevka!

@be5invis
Copy link
Owner Author

@sliceofcode VSCode, theme is Railgun

@slice
Copy link

slice commented Jan 15, 2017

Alright, thanks.

@p-e-w
Copy link

p-e-w commented Jan 21, 2017

@be5invis: Sorry for the late reply. I have studied the changes and find two small issues: First, the new ß is hard to distinguish from B because the bottom loop almost touches the stem. Other fonts eschew this problem by either leaving more space between the loop and the stem or by making the two loops "wavy" in a fashion that is obviously different from B. I would recommend the first approach as I think the overall glyph shape is good already.

Second, I agree with @sliceofcode in that I feel all three bracket types should be wider than they currently are, and indeed I believe should be as wide (and as tall) as the character cell allows. While your adjustments make ( and { more distinct, { almost looks like | now because of its small horizontal extent. I love the Monaco example given above – the wide extent makes it possible to really flesh out the different shapes, and matches the role brackets usually have in code: Containers for code blocks or array-type objects, which should be immediately recognizable.

In any case, I continue to be amazed by your responsiveness and swift release cycle. I am not aware of any other font with a development speed approaching that of Iosevka.

@slice
Copy link

slice commented Jan 21, 2017

Here is another comparison. This time, Iosevka and Input.
2017-01-21-10 27 44
Input's braces are shorter, and "longer". You can clearly see the difference between |, (), and {}. Although the same can be said for Iosevka, I prefer Monaco/Input style braces.

I agree on what @p-e-w said, especially the last sentence. It's what makes Iosevka so great. 👍

@be5invis
Copy link
Owner Author

@sliceofcode well its “wider”.
Given that Iosevka is designed to be very narrow (in fact it is the narrowest monospace typeface I know), I think I can increase the width of brackets only a little.

@be5invis
Copy link
Owner Author

image
@p-e-w @sliceofcode Like this?

@slice
Copy link

slice commented Jan 22, 2017 •
edited
Loading

@be5invis Looks like it. 😄 Thank you for this.

@be5invis
Copy link
Owner Author

@sliceofcode It's in Master. build it (on linux please, because OSX fontforge is some sort broken)

@be5invis
Copy link
Owner Author

Add some overshoot
image

image

@slice
Copy link

slice commented Jan 22, 2017

2017-01-22-11 44 53

@be5invis Looks beautiful. 😄

Had to use this workaround for Fontforge to work properly in Linux: fontforge/fontforge#2992

@slice
Copy link

slice commented Jan 22, 2017 •
edited
Loading

Here's some TTFs of master: iosevka-wide-braces.tar.gz Outdated.

@be5invis
Copy link
Owner Author

be5invis commented Jan 22, 2017 •
edited
Loading

@sliceofcode I have no clue what happened to FF. Perhaps I should write something to get rid of it (for example, otfcc-ttcize is written to replace FontForge's TTC exporter)... It's annoying, really.

Currently FF is ueds to:

  • Merge contours
  • Transform contours into glyph references (Reduces about 50% of file size)

@slice
Copy link

slice commented Jan 22, 2017

2017-01-22-11 52 03

Here is another preview, this time all weights. Click for higher resolution.

@p-e-w
Copy link

p-e-w commented Jan 23, 2017

Interesting... in @sliceofcode's last preview, for the light weights } is shifted upwards compared to [, while for the heavy weights it is shifted very slightly downwards (or perfectly aligned, can't decide which one). Is the overshoot weight-dependent?

Otherwise, this is an enormous improvement, @be5invis! I'm also excited about the possibility you hinted at of eliminating FontForge from the build chain, which has always felt like the odd one here (FF is primarily a GUI tool, after all). A pure command line-based font compilation toolchain could literally usher in a new era of "precision fontmaking", of which Iosevka thus far appears to be the only example.

@be5invis
Copy link
Owner Author

@p-e-w {} and [] are perfectly vertically middle-aligned. His image just does not have enough resolution. FF is a cluster of uncertainty and bugs. It should be eliminated.

@be5invis be5invis mentioned this issue Feb 18, 2017
Closed
@jdw1996
Copy link

jdw1996 commented Feb 24, 2017

I'm glad that the # sign has been mentioned—that is the least clear symbol in the font for me. However, there are a couple others that I would also love to see variants of:

  • $ — Right now, I find that the dollar sign looks a bit too much like an S. It would be nice to have a variant that created a stronger distinction. Here are some examples; from left to right, the fonts are Iosevka, Monoid, Input, and Consolas:
    dollars
    While I prefer the $s in Input and Consolas to Monoid's, something more similar to Monoid's $ may be more feasible because Iosevka is such a narrow font.
  • Q — The current letter Q is nice and simple, but I find it a bit hard to distinguish from O. Again, I think there are a few different ways to handle this; from left to right this image shows Iosevka, Monoid, Input, and TexGyre Schola:
    q
    Input's Q is the most similar to the current Iosevka Q, but its tail is more pronounced, making it easier to see. That said, I think the other two are clearer, as the tail breaks the circular outline of the letter.

Thanks again for the great font!

@be5invis
Copy link
Owner Author

@jdw1996
How about this?

image

@be5invis
Copy link
Owner Author

be5invis commented Mar 30, 2017 •
edited
Loading

@therockmandolinist
Here you are:

image

@be5invis
Copy link
Owner Author

@jdw1996 And we have this:

image

@memophen
Copy link

Odd that I discovered Iosevka just recently, while looking for a holy mono grail for so long. Interesting for its collection of glyphs and variants, as well as for the way the whole thing is produced. As a newcomer, I might say things now that have been said before, but I found little evidence of it so far. Despite all appreciations of the glyphs, I cannot imagine that many people are really happy with the paperclip shapes of the @ sign (cv31 and cv32). At least, I am not.

I've tried to find out the logic of the chosen measures. There is an x-height of course, and a cap height. And -- forgive me not knowing the proper typographical terms -- a somewhat bigger #-height, and an even exceeding slash height. Ascenders don't surpass the cap height, and descenders go slightly deeper than the slash height characters.

Making special characters like # just a bit outstanding from capitals is a defensible design decision in my opinion. But I wonder why cv31 and cv32 were stretched to slash height. Why not #-height, like cv33? That would make these characters less distracting. And I think there is still some room for widening all @ variants a tiny bit.

The slash height in itself doesn't make me enthousiastic either. May I suggest adding an option for a little more modesty by equalizing the top side with the top level of the #-height? That's a more balanced compromise between the combination with uppercase/digits vs the combination with lowercase text. Satisfying everyone (high-levelers vs low-levelers) would require this to be parameterized categorically, I guess. No idea how much effort would be involved in constructing a tweaking mechanism for that.

The attached graphic shows my fiddling around with ss09 based on these ideas, concluded by the same text in PragmataPro.
Iosevka-at-sign-1-45perc

@be5invis
Copy link
Owner Author

be5invis commented Mar 17, 2019 via email

@bluz71
Copy link

bluz71 commented Mar 19, 2019

Thank you @be5invis and @sharpjs,

I really like the new ringed % and six-pointed * glyphs. A big improvement.

@memophen

I cannot imagine that many people are really happy with the paperclip shapes of the @ sign

I also dislike the paperclip @, but it is not the default, the short Fira style is the default and I think that version looks superb. I appreciate that @be5invis has given this font flourishes, such as the short @ and ringed %, it makes looking at code enjoyable.

@memophen
Copy link

Don't understand me wrong, I really do support the principle of the higher braces etc., and only slightly disagree over how far to go with it. As the current proportions are somewhat peculiar but not distracting, no further insisting is to be expected from my side. Another matter bothers me more: the readability of the digits, especially the nine and the zero.

The change of style between six and nine is not just esthetically unsatisfactory. I imagine the shape of the six was chosen to contrast with the letter G. But even without the existence of G, the open form would be a better choice, since it also contrasts better with the eight. So I would highly appreciate a nine that's a 180 degree rotation of the current six.

If I had to characterize the circular glyphs of Iosevka, I would call them racecourse-shaped. This qualification is applicable to the letter O, the current zeroes, but also to C, G, U, and the current nine. Opposed to that are the oval-shaped characters. There aren't many in Iosevka, but I've found the lowercase theta. Wouldn't that shape (a bit more stretched to the same width as the current letter O) be a better representation of the zero, even more in combination with the current six and the alternate nine I pled for? This would make larger numbers far more readable, in my perception.

Below I tried to make these ideas visible. First a sample sheet of possible letter and digit shapes with or without different zero marks:
O0
Then a lot of solutions for the zero (first line), a sample with the current nine (second line) and a sample with an alternate nine (third line):
Zeroes
Would oval-shaped zeroes be problematic? It doesn't look like. The theta does not misbehave at smaller sizes:
Digits-with-theta
As far as I'm concerned, I would be quite happy to see the three current zeroes cv20/cv21/cv22 simply replaced by three equivalent oval ones. However, if people are devoted to the racecourse shapes, addition of the ovals to the assortment of zeroes would be okay as well. The exact kind of slash or dottish thing is less important to me, although my personal preference is the last sequence 1068092 in the second sample (and I'm considering to choose cv51 instead of cv50, but that's a private affair).

@bluz71
Copy link

bluz71 commented Mar 23, 2019

As far as I'm concerned, I would be quite happy to see the three current zeroes cv20/cv21/cv22 simply replaced by three equivalent oval ones.

Absolutely NOT!

The existing current zeros looks far nicer than the proposed oval zeros (to my eyes). I strongly disagree on changing it.

Your arguments about 9 do make sense, but I am agnostic on that. I like the current 9, but a change to an inverted 6 would not bother me either.

My 2c as a big fan of the current font.

@be5invis
Copy link
Owner Author

@memophen Changing the shape of 0 will severely de-harmonize the design consistency between digits and letters. Theta is the only exception case since its upper-case and lower-case are very closely shaped so I have to made some difference.

@memophen
Copy link

@be5invis -- Do we need and want such a fargoing design consistency? Arabic digits are a different species, after all. That was clear when they arrived in Europe (in 976 or just before):
976-33pct

(Item de figuris arithmetice: Scire debemus in Indos subtilissimum ingenium habere et ceteras gentes eis in arithmetica et geometria et ceteris liberalibus disciplinis concedere. Et hoc manifestum est in novem figuris, quibus designant unumquemque gradum cuiuslibet gradus. Quarum hec sunt forma: 9 8 7 6 5 4 3 2 1.)

And it’s also clear in contemporary bookprint, where they still don’t go along the established lines of uppercase and lowercase letters:
OSF
Even tabular figures don’t conform the lettering conventions, and I must say, I’m glad they aren’t completely harmonized yet:
Conformity-50pct
In my view, the proposed kind of difference does not imply disharmony. But de gustibus non est disputandum. If you are opponent to freer forms and want to force all glyphs in the same grid, well, it’s your show. Then my best contribution would be advising you to replace the de-harmonizing 6 by a rotated 9.

Nevertheless I think Iosevka has a lot of charms. It would suit well for display on posters and covers, when you want to apply an austere style.

@be5invis be5invis mentioned this issue Aug 31, 2019
Closed
@AlsoScratch
Copy link
Contributor

@be5invis You still haven't added my suggestion for the digit 7 having a downward pointing bit.

@be5invis
Copy link
Owner Author

be5invis commented Sep 1, 2019 via email

@AlsoScratch
Copy link
Contributor

Where do I find it?

@AlsoScratch
Copy link
Contributor

Maybe consider adding it to the task list?

@be5invis
Copy link
Owner Author

be5invis commented Sep 1, 2019

@AlsoScratch b789f17

@rileyinman
Copy link

rileyinman commented Sep 24, 2019 •
edited
Loading

I'd like to request forms of 7 and z with the "crossed" style seen in some European countries. The strikethrough makes it easier to distinguish in my opinion and would (hopefully) be simple enough additions.

Examples:

image

@robertgzr
Copy link
Contributor

@memophen @bluz71 I just opened a PR with the inverted six glyph for the nine. I've been using this patch for my daily driver font and ended up preferring it over the current nine

image

@zyxw59
Copy link

zyxw59 commented Jan 8, 2020

I'd like a version of i and j that have the tails at the bottom, but not the serif at the top (to match l in cv27)

@zyxw59
Copy link

zyxw59 commented Jan 9, 2020

Oh, it looks like these are available as design options (v-i-tailed and v-j-straight), but not as cv options.

@be5invis
Copy link
Owner Author

be5invis commented Jan 9, 2020

@zyxw59 v-i-tailed and v-j-straight are originally for Aile. I do not test them on monospace.

@AndydeCleyre
Copy link

AndydeCleyre commented Jan 19, 2020 •
edited
Loading

If made available, I'd use and appreciate the old style upper case G, without that tooth.

I don't like when letters get very skinny at joins (like how the b and r have recently thinned more where the curves meet the vertical bar), and I just like the old G.

Thanks again for this incredible project.

EDIT: I'm having trouble finding the change in the code responsible for the new G shape. Can you point me to a commit, so I can revert/patch locally? Looks like it's sometime at or before 3bcade3 (r1313), and after 1263c3a (r1273). I'll bisect if I need to, but if you happen to know where the change is, I'd appreciate saving the build-and-check time.

EDIT: I did the bisect, so for anyone else wondering, it looks like the G was transformed in c1593c7. A lot of stuff happens in that commit though, so I'm not sure of all the effects of reverting that. I'll find out.

EDIT: got the old G back with this partial revert

EDIT: If anyone else wants a patch for the smoother G, you can save the following to toothless-G.patch and apply within the checkout folder with patch -p1 < /path/to/toothless-G.patch:

diff --git a/glyphs/letters-unified-basic.ptl b/glyphs/letters-unified-basic.ptl
index 40fb8784..5cd2ffae 100644
--- a/glyphs/letters-unified-basic.ptl
+++ b/glyphs/letters-unified-basic.ptl
@@ -2753,8 +2753,6 @@ export : define [apply] : begin
 	do "G and related ============================================================================="
 		define [GShape top sma smb] : glyph-construction
 			local yBar : top * 0.52 + STROKE * 0.25
-			local fine SHOULDERFINE
-			local sb : shoulderMidSlope fine nothing (-1)
 			include : dispiro
 				widths.lhs
 				g4   RIGHTSB (top - HOOK)
@@ -2762,12 +2760,13 @@ export : define [apply] : begin
 				flat (SB + OX) (top - sma)
 				curl (SB + OX) smb
 				arcvh
-				g4.right.mid (MIDDLE + (CORRECTION_OMIDX - sb) * STROKE) O [widths.heading STROKE 0 {.y (1) .x (sb)}]
+				g4   (MIDDLE + CORRECTION_OMIDS) O
 				archv
-				straight.up.end (RIGHTSB - (STROKE - fine) * HVCONTRAST) sma [widths.heading fine 0 UPWARD]
-			include : HBarTop MIDDLE RIGHTSB yBar
-			include : VBarRight RIGHTSB sma yBar
-			include : VBarRight RIGHTSB sma 0 (STROKE - fine / 2)
+				flat RIGHTSB sma
+				curl RIGHTSB yBar [heading UPWARD]
+			include : dispiro
+				flat MIDDLE yBar [widths 0 STROKE]
+				curl RIGHTSB yBar [heading RIGHTWARD]
 
 		sketch # G
 			set-width WIDTH

@paolobolzoni
Copy link
Contributor

paolobolzoni commented Feb 6, 2020 •
edited
Loading

I'd like a j variant with the round bottom like v-j-serifed (cv58) and the sans serif top like v-j-line (cv57). I prefer the rounded shapes with no serif.

I see zyxw59 asked something similar, buy I am not sure if he obtained it or how.

Edit:
It is easy to obtain, one needs to edit glyphs/letters-unified-basic.ptl and in the section

sketch # dotlessj.serifed
			include markset.p
			include glyphs.'dotlessj.straight' AS_BASE
			include : LeftwardTopSerif (MIDDLE + JBALANCE) XH LONGJUT

just comment (or remove) the last line.

@paolobolzoni
Copy link
Contributor

paolobolzoni commented Feb 6, 2020 •
edited
Loading

Did you consider an octothorpe variant without the horizontal lines between the vertical bars?

A-la IBM plex mono:
ibm plex octothorpe

I personally don't like it much, but it is really readable.

@lshoravi
Copy link
Contributor

lshoravi commented Feb 17, 2020 •
edited
Loading

In line with the cursive k, would it be possible to get a cursive i?

image

@ChiefMikeK
Copy link

In line with the cursive k, would it be possible to get a cursive i?

image

Look$ like this U+2139 from George Douros's Symbola.ttf
Image

@AndydeCleyre AndydeCleyre mentioned this issue Mar 6, 2020
Closed
@astrolemonade
Copy link

My request is a 'U' variant that is like the JetBrains Mono one:
image

@lshoravi
Copy link
Contributor

lshoravi commented Mar 8, 2020

I believe this was just added, @cata0309

Check out ss14 from the latest release candidate

@be5invis
Copy link
Owner Author

I'd like to close this issue now.
For further character variant requests, please open separate issues.

@alexeyten alexeyten mentioned this issue Apr 26, 2020
Closed
@paolobolzoni paolobolzoni mentioned this issue May 14, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
✒️ Glyph Shape Priority 3
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests