Recommended to see in 100% scale on a 14" laptop screen. It will look much more comfortable on a 24" external screen.

(don't get fooled by "f31" in terminal, it's Fedora 32)

I agree. 11 px seems like a better default.

Why is this issue being reported here, rather than upstream?

@aday Because we're the Workstation WG. It's entirely possible that it's a downstream choice. How is anyone going to know before asking us first?

I originally wanted to report it against https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas (that's where the defaults live, not sure if it is the right project to have the conversation in), but @kalev recommended me to file it here first, because it might have a better traction. And it also makes sense when thinking about Fedora 32 release schedule (upstream doesn't need to care about our release schedules, but we can put the patch in in time and continue discussing in upstream afterwards).

I originally wanted to report it against https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas (that's where the defaults live, not sure if it is the right project to have the conversation in), but @kalev recommended me to file it here first, because it might have a better traction.

Thanks @kparal. An issue against gsettings-desktop-schemas should be fine. Feel free to cc me. You can also reference the discussion where the monospace was selected.

And it also makes sense when thinking about Fedora 32 release schedule (upstream doesn't need to care about our release schedules, but we can put the patch in in time and continue discussing in upstream afterwards).

F31 is using Source Code Pro 10, so Fedora users have had it for a little while. Do you really think that this is so urgent that we should patch F32?

It's a pretty bad font size. I actually don't know why we aren't using point size 12 consistently everywhere either.

Thanks @kparal. An issue against gsettings-desktop-schemas should be fine. Feel free to cc me. You can also reference the discussion where the monospace was selected.

Sure, but that should be orthogonal to fixing this in F32. I can't see GNOME upstream changing the default so late in the GNOME 3.36 release cycle; we should instead make a decision for Fedora 32 here and then consider if GNOME should follow in 3.38 or not. The Fedora side of this is entirely in Fedora Workstation WG territory.

I'll note that a number of other downstreams have changed the font, including flathub that uses "'Monospace 11'" instead. Also see https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/issues/12

F31 is using Source Code Pro 10, so Fedora users have had it for a little while. Do you really think that this is so urgent that we should patch F32?

What you mean with "so urgent"? F32 is not yet released so now's a good time to do any tweaks like this. Why should a simple font change have to wait for the next cycle when we're just starting to get beta testing feedback here (and the feedback says the font is too small)?

F31 is using Source Code Pro 10, so Fedora users have had it for a little while. Do you really think that this is so urgent that we should patch F32?

What you mean with "so urgent"?

Various things:

• We've had Source Code Pro for nearly a whole cycle, and it only just seems to have been flagged, so that makes me doubt how serious the issue is.
• Users have had the current default for one cycle, so it would look a bit strange to change it again so quickly.
• If we do change the monospace again, we should be confident that it won't be another temporary change. That means being confident in our decision, having a long-term plan, and coordinating with upstream. At this point in the cycle, I'm not sure that we have time to do that.

What I don't want is to make a quick last-minute decision, and that decision turn out to be a poor one. Or have to change it again because of other developments we don't know about. Or Fedora ending up being permanently out of alignment with upstream, because we didn't give ourselves time to have the necessary conversations.

beta testing feedback here (and the feedback says the font is too small)?

All I see here is @kparal 's opinion that Source Code Pro 10 looks too small to him. Is there any other feedback that we're basing this on?

I've always considered it to be too small, I just figured nobody would care.

I've always considered it too small as well. I just didn't have the capacity to bring this up earlier.

If someone could actually file an upstream issue with their experiences, that would be helpful.

Here's an upstream issue:
https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/issues/26

F31 is using Source Code Pro 10, so Fedora users have had it for a little while.

I checked and you're right! I quite apparently forgot and considered it a change in F32. I looked at all my permanent F31 VMs and in all of them, I increased the default monospace font size. And I start to remember - I disliked it even during F31 cycle, but I had didn't force myself to file a bug about it. So... take this as a request to improve it in F32 :wink:

If we do change the monospace again, we should be confident that it won't be another temporary change. That means being confident in our decision, having a long-term plan, and coordinating with upstream. At this point in the cycle, I'm not sure that we have time to do that.

I see only positives and no controversy in increasing the size to 11px. Of course, that's just me.

FWIW, I just checked Ubuntu 19.10 and they use "Ubuntu Mono Regular 13", which is in size equivalent to "Monospace 11". So basically a 11px font in our discussion.

And flathub gnome runtime also has a 11 px font (upstream default is overridden):

$ flatpak run --command=sh org.gnome.Platform//3.34
[📦 org.gnome.Platform ~]$ gsettings get org.gnome.desktop.interface monospace-font-name
'Monospace 11'
[📦 org.gnome.Platform ~]$ fc-match Monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

And flathub gnome runtime also has a 11 px font (upstream default is overridden)

Yes, that's right, upstream itself reverts the upstream default. The problem is that we don't have Source Code Pro in GNOME. We do have Cantarell, so reverting that one isn't strictly necessary, but sticking to what Fontconfig says are the default fonts makes a lot of sense to me. Setting gsettings-desktop-schemas's defaults to fonts that users can uninstall, or that distros might not have installed, seems to be causing more trouble than it's worth.

And flathub gnome runtime also has a 11 px font (upstream default is overridden)

Yes, that's right, upstream itself reverts the upstream default. The problem is that we don't have Source Code Pro in GNOME. We do have Cantarell, so reverting that one isn't strictly necessary, but sticking to what Fontconfig says are the default fonts makes a lot of sense to me. Setting gsettings-desktop-schemas's defaults to fonts that users can uninstall, or that distros might not have installed, seems to be causing more trouble than it's worth.

That's due to a somewhat different issue from the one that was reported here (and I think that the plan is to add Source Code Pro to the GNOME runtime?)

Sure, the reason for that is different, but the practical consideration is that GNOME apps installed from Flathub are going to have an 11 px font vs rpm apps that have a 10 px font.

Sure, the reason for that is different, but the practical consideration is that GNOME apps installed from Flathub are going to have an 11 px font vs rpm apps that have a 10 px font.

But then if the GNOME runtime gets Source Code Pro, then we'd have the reverse. Would Fedora then add it back again, having already added it and then removed it six months later?

The solution is obviously that Flathub GNOME runtime should continue using 11 px font as it's doing now.

The solution is obviously that Flathub GNOME runtime should continue using 11 px font as it's doing now.

As far as I'm aware, that's not the solution that the runtime maintainers are currently planning on...

To be clear: I'm not saying that there aren't potential issues here to be worked through. Rather, my argument is that we should take the time to resolve them upstream, rather than rushing to make changes downstream, when we don't have a clear shared plan for the future.

Cantarell 11 has 8 pixels x-height, Source Code Pro 11 has 8 pixels x-height, Source Code Pro 10 has 7 pixels x-height. So Source Code Pro 11 matches the default UI font’s size better than Source Code Pro 10. That probably explains people’s perceptions (which is also mine) that Source Code Pro 10 is too small relative to Cantarell.

An associated change to help with legibility in the terminal:

https://bugzilla.redhat.com/show_bug.cgi?id=1814645

Sure, but that should be orthogonal to fixing this in F32. I can't see GNOME upstream changing the default so late in the GNOME 3.36 release cycle; we should instead make a decision for Fedora 32 here and then consider if GNOME should follow in 3.38 or not. The Fedora side of this is entirely in Fedora Workstation WG territory.

@chrismurphy, could you put this on a meeting agenda please so that we can have a chance of fixing this before the F32 final freeze if it's something that we want to change?

Yes no problem; I'll add it to next week's agenda.

Anyone can use the 'meeting-request' tag for an issue, and I'll work it into the schedule. This is not a gatekeeper tag, but rather due to the calendar app notification sending an agenda URL using 'meeting' tag as a filter. The separate tags is to make sure the calendar app link for the agenda is consistent with the actual agenda I email each week to desktop@; and also to make sure I don't lose track of requests.

Discussed at the meeting. No consensus to change the behavior given the short time frame, but no objections to revisit a more holistic strategy for Fedora 33.

Some related terminal legibility work: https://gitlab.gnome.org/Teams/Design/app-mockups/-/issues/20

Can relevant parties post an update on this issue, please?

Personally, I'm sympathetic to a very simple argument: all fonts should be 11pt by default so that they're all the same size. 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. But most importantly, I'd like to see this resolved in upstream GNOME rather than by the Workstation WG.

If I compare the font in Terminal and Gedit to the font in Nautilus or Help, the Terminal/Gedit font it smaller and uncomfortable. F32 Workstation. Disclaimer: I prefer larger fonts.

Text contrast should hopefully have improved in gnome-terminal master (see this issue). I'm still waiting on a change in coreutils that should hopefully improve the contrast situation further.

I'm hoping to re-review the situation once I've been able to test the latest changes, with a view to deciding about the default monospace font size.

Since my last comment we've pushed to get the desired colour changes in place, and the following commits have gone in:

• https://gitlab.gnome.org/GNOME/gnome-terminal/-/commit/b6282897d3136f8bfd045976a12c84f0c9204e4a
• https://gitlab.gnome.org/GNOME/gtk/-/commit/cd0b9a2359275f320301705a4aaa0a8d1c4483ec
• https://gitlab.gnome.org/GNOME/vte/-/commit/a737e397e391761546dd9356ec99f499ccaa4cf8

These should all make it into the GNOME 3.37.90 beta release.

It's been hard to test these changes and I haven't been able to properly use them. I would have liked to have had wider testing before returning to the font question itself.

The ls change in coreutils is still outstanding, though I think we're making progress.

Can this still happen for Fedora 33? Or punt milestone to Fedora 34?

Can this still happen for Fedora 33? Or punt milestone to Fedora 34?

The colour changes made it into F33, but the text size/style is probably out of scope.

I'd like to review for F34 once we've had chance to test the changes so far.

The exclamation mark especially looks much better with Source Code Pro 11 than Source Code Pro 10.

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.

I agree, but the ui-monospace generic family might be more appropriate than monospace. 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. 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).

Have people noticed any improvement on this, or is the size still an issue?

I haven't worked with Rawhide much yet, but I started Fedora-Workstation-Live-x86_64-Rawhide-20210113.n.0.iso which I had lying around and played with gnome-terminal and gedit. In the terminal, the background is darker, which improves contrast (even though I liked the grayer background more). I don't think readability changed much, honestly (but I played with it just a short while). When I switched the terminal and gedit to either Source Code Pro 11 or Monospace 11, the font was of course easier to read. Even Monospace 10 was a little better, because even though it has smaller spacing vertically, its lines are thicker. I tested this on my 14" laptop screen (on my external 24" screen, I don't have any issues even with the default Source Code Pro 10 font).

The increase in contrast is an improvement, but readability was poor to begin with and font size makes a bigger difference.

I don’t think there’s much objective argument that can be made for the tradeoff between readability and information density. 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 96 ppi 1080p screen, and a font size of 18 in Pango and GTK) for the text body of websites.

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. Not nearly enough to avoid text wrapping.

A 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. Still not enough to avoid all wrapping, and there are still many screens with smaller resolutions.

Source Code Pro 11 matches exactly Cantarell 11’s x-height.

I personally care more about avoiding wrapping (in code, tables, and terminal output, not in text) than seeing more lines. 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. That’s probably enough in most cases?

This is a very long issue to discuss a one-point font size change.

Proposal: ask upstream to change default monospace font from "Source Code Pro 10" to "Source Code Pro 11" in order to match "Cantarell 11," which is our default for everything except monospace.

+1 to the proposal

I can do a new upstream proposal.

We discussed this again upstream. The feeling there is that while 10pt does feel small, 11pt looks big compared with the UI font. We looked into using 10.5pt or similar, but couldn't get it to work.

Fixed-width fonts take more horizontal space, but the x-height is exactly the same for Cantarell 11 and Source Code Pro 11. And at least for the lowercase x, the width of the letter is exactly the same as well (this isn’t necessarily true for all glyphs and it’s not true for the advance width):

Cantarell 11’s capital letters are one pixel higher than Source Code Pro 11’s.

Someone encountered this issue and complained about it on Twitter, since it made VS Code have small text compared to other platforms. Is there something we can do to make this better? :pray:

My take on this is that font size is a very personal preference, depending on eyesight, viewing environment, and other factors. The terminal has font preferences for that reason, and there's also a large text option in the a11y menu.

My $0.02: the current 10-pt setting looks a lot better than 11-pt to me. 11pt is just so big.

But like Matthias says, I understand this is all very subjective.

We discussed this again upstream. The feeling there is that while 10pt does feel small, 11pt looks big compared with the UI font. We looked into using 10.5pt or similar, but couldn't get it to work.

Problem is gedit (or perhaps gtksourceview) rounds found size down, so it converts 10.5 to 10. But gnome-terminal does not do that. I think 10.5 is perfectly fine. 11 looks very big to me.

Proposal: change from 10 to 10.5 so we can close this issue. That will help in the terminal, even if gedit ignores it.

So we discussed this at today's meeting. The Working Group does not believe we can find a default font size that works well for all displays: while 10pt is too small for some displays, 11pt is too large for others. We've agreed on two things:

• Defer default font size to upstream
• The real underlying problem here is no support for fractional scaling. Fedora Workstation should expose support fractional scaling and select a reasonable scale factor by default. We will track this issue separately.