Source Code Pro 11 fits 106 characters in a half-tiled terminal and 212 when not tiled, versus 119 and 239 with Source Code Pro 10.I had the same problem, Jetson nano 2 GB, fresh install connected to a TV and the letters where too small to read (the same size as the pixels). I personally care more about avoiding wrapping (in code, tables, and terminal output, not in text) than seeing more lines. Source Code Pro 11 matches exactly Cantarell 11’s x-height. Still not enough to avoid all wrapping, and there are still many screens with smaller resolutions. Not nearly enough to avoid text wrapping.Ī 13-point size is enough to fit 95 characters in a half-tiled terminal and 93 in half-tiled Text Editor when line numbers are displayed. On a screen with a 1920 × 1080 resolution, and with Source Code Pro, that’s enough to fit 137 characters and only 68 in a half-tiled terminal. Make It Big! The Effect of Font Size and Line Spacing on Online Readability (probably the best and most recent article on font sizes) detects significant improvements in readability and comprehension ratings for Wikipedia articles up to 22 points and recommends at least 18 points (equivalent to 24 CSS pixels, 16 physical pixels on my p screen, and a font size of 18 in Pango and GTK) for the text body of websites. I don’t think there’s much objective argument that can be made for the tradeoff between readability and information density. The increase in contrast is an improvement, but readability was poor to begin with and font size makes a bigger difference. And I think #36 is still a good idea-document fonts used for example to show Wikipedia articles in web browsers don’t have to be the same as the system interface and monospace fonts (on macOS and iOS they aren’t). For the interface font too, system-ui would have the benefit of providing better fallbacks for characters not in Cantarell, since it’s already in fontconfig with many substitutions for non-Latin fonts. I agree, but the ui-monospace generic family might be more appropriate than monospace. I would also support switching back to Monospace 11, and change Fontconfig to alias Monospace to Source Code Pro if that's what we want to do. The exclamation mark especially looks much better with Source Code Pro 11 than Source Code Pro 10. Is there any other feedback that we're basing this on? Or Fedora ending up being permanently out of alignment with upstream, because we didn't give ourselves time to have the necessary conversations.īeta testing feedback here (and the feedback says the font is too small)?Īll I see here is 's opinion that Source Code Pro 10 looks too small to him. Or have to change it again because of other developments we don't know about. What I don't want is to make a quick last-minute decision, and that decision turn out to be a poor one. At this point in the cycle, I'm not sure that we have time to do that. That means being confident in our decision, having a long-term plan, and coordinating with upstream. If we do change the monospace again, we should be confident that it won't be another temporary change.Users have had the current default for one cycle, so it would look a bit strange to change it again so quickly.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |