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.

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

Improve consistency of type rendering weight across OSes #1677

Merged
merged 2 commits into from Mar 11, 2023

Conversation

DavidOliver
Copy link
Contributor

@DavidOliver DavidOliver commented Mar 9, 2023

Fixes #1675

As the sidebar type is thinned in Mac OS via the alternative anti-aliasing, its weight can be increased from light to normal to avoid overly thin type in Linux and Windows.

The thin weight is preserved/used in places where differentiation from normal/bold is warranted.

Additionally, the normal/400 weight font was not being loaded, which resulted in type set to normal being rendered light. We're now loading light/300, normal/400 and bold/700 for the Lato sans serif font.

Screenshots

All Firefox/Ubuntu, before followed by after. (@josevalim to make sure he's happy with Safari/WebKit in Mac OS.)

Light: Sidebar

Screen Shot 2023-03-09 at 15 25 32
Screen Shot 2023-03-09 at 15 14 25

Light: Settings

Screen Shot 2023-03-09 at 15 26 02
Screen Shot 2023-03-09 at 15 14 48

Dark: Sidebar

(Same as light theme sidebar.)

Screen Shot 2023-03-09 at 15 26 08
Screen Shot 2023-03-09 at 15 15 03

Dark: Settings

Screen Shot 2023-03-09 at 15 26 11
Screen Shot 2023-03-09 at 15 15 08

Fixes elixir-lang#1675

As the sidebar type is thinned in Mac OS via the alternative anti-aliasing, its weight can be increased from light to normal to avoid overly thin type in Linux and Windows.

The thin weight is preserved/used in places where differentiation from normal/bold is warranted.

Additionally, the normal/400 weight font was not being loaded, which resulted in type set to normal being rendered light. We're now loading light/300, normal/400 and bold/700 for the Lato sans serif font.
@josevalim
Copy link
Member

Thank you @DavidOliver !

Yeah, unfortunately the regular text appears to thin on Mac now :( So we have two options:

  1. Change the font for the regular text
  2. Check if the user agent is a Mac and load heavier fonts if not

@josevalim
Copy link
Member

I think second option may be simpler. If Mac, we set font-weight in the sidebar to 300, otherwise 400, and we don't modify font smoothing in any case.

@DavidOliver
Copy link
Contributor Author

DavidOliver commented Mar 9, 2023

Screenshots in Safari/Mac OS for reference follow.

Before:

Screen Shot 2023-03-09 at 17 06 01

After:

Screen Shot 2023-03-09 at 17 06 24

I'm also having doubts about grayscale anti-aliasing now. The subpixel anti-aliasing (the default, as before) seems to result in more refined tracking/spacing between letters, as well as better letter shapes, in the sidebar in Mac OS.

It seems a shame to resort to UA string sniffing, but maybe that's the only way we're going to get the results we'd like. It looks like we should check whether or not 'Macintosh' is in the string.

So:

  • No anti-aliasing modification.
  • Load both 300 and 400 Lato font weights. (Both are used.)
  • Font weight choices set with Mac OS in mind by default.
  • If 'Macintosh' is not present in UA string, switch certain instances of Lato text, such as sidebar links, from 300 to 400.

Does that look right to you?

@josevalim
Copy link
Member

Yes! I am also fine to be safe and render with heavy font by default and convert to 300 if MacOS. I think we will only need this change on the sidebar. Can you think about any other place we may need to change?

Thank you! ❤️

@DavidOliver
Copy link
Contributor Author

DavidOliver commented Mar 9, 2023

No, as far as I've seen it is just the sidebar where the light weight is an issue in Linux. There are some other uses of the light weight here and there, but they're either large enough or minimal enough to not be a problem in my opinion.

I was thinking about asking which the default should be. There may be a visual change after the initial render once the JS UA detection has run. I don't suppose you happen to know which OS is most commonly used for Elixir/Erlang documentation?

@josevalim
Copy link
Member

If we can use the Elixir website as representative:

image

Which reminds me we likely want to detect for iOS as well.

@josevalim
Copy link
Member

Amendment: hexdocs has very similar numbers.

@DavidOliver
Copy link
Contributor Author

Ha! About 50/50 Apple/others then. Thanks for the info.

I think iOS is covered by 'Macintosh', but I'll check.

…sidebar based on OS

Grayscale-only anti-aliasing, which we set in order to lessen the difference in type rendering across OSes, resulted in suboptimal type rendering in Mac OS. We now use normal/400 instead of light/300 in the sidebar if the UA string indicates a non-Apple OS.
@DavidOliver
Copy link
Contributor Author

New approach as discussed pushed.

Safari/Mac OS:

Screen Shot 2023-03-11 at 12 57 52

Firefox/Linux (representing non-Apple):

image

@josevalim
Copy link
Member

Amazing, thank you so much! ❤️

@josevalim josevalim merged commit 8d9cf7c into elixir-lang:main Mar 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Text rendering: weight and consistency across OSes
2 participants