Changing main content font to Valkyrie?

by habryka1 min read24th Aug 201810 comments

24

Site Meta
Personal Blog

(Probably not interesting to 90% of people, but would love to get input from our local typography nerds)

We've been using Warnock Pro as our default font for body-text and content-related elements for a while, and I've been quite happy with it on my Mac, but on Linux on Windows machines the font renders as a bit spindly and thin, and can be hard to read at some smaller font-sizes.

Given that we've been refactoring a bunch of our Typography anyways, it seems like the best time to maybe switch to a new font. In most typography-matters I tend to defer to Butterick's Practical Typography who has a good set of recommendations for fonts similar to Warnock, and my favorite one I've found so far is Butterick's one creation Valkyrie. So changing to that seems like a thing we might do in the next few weeks.

Stylistically, my favorite font continues to be ETBook, but that one sadly has a variety of rendering issues that make it impossible to use on Lesswrong. Valkyrie is about as good as Warnock in that respect, but renders much better on Windows and Linux machines in that respect, but I would love to hear recommendations for other fonts if people have any good ones (commercial fonts are fine, as long as they don't come with weird "amount of user" limits).

10 comments, sorted by Highlighting new comments since Today at 9:47 PM
New Comment

I’m a big fan of Butterick’s fonts, and Valkyrie (which I guess is new? I hadn’t seen it before) is no exception. I can find no fault with this font. (Note, though, that Valkyrie seems to default to old-style figures; I would suggest setting the requisite OpenType CSS attributes to switch to lining figures, as these are more generally appropriate.)

(That having been said, there are a number of tricks one can use to solve the “font renders as spindly and thin on Windows/Linux machines”; if you’re interested in expending a relatively minor amount of effort to be able to stick with Warnock, let me know, and I’ll describe several approaches to solving the problem without switching fonts.)

As far as other fonts go, here are some fonts you might consider on the basis of their similarity to ET Book (links go to a page where you’ll see each font side-by-side with ET Book):

(Adobe Jenson Pro should be available via Typekit; I’m not sure about the other two, but they should be available elsewhere.)

I am definitely willing to invest time into fixing this, so I would be quite glad about help. My first guess was to serve a heavier font-weight to Windows machines, but Warnock Pro sadly doesn't have a 500 font-weight available, and instead goes directly from 400 to semibold (600), which is quite a bit too bold, even for Windows machines.

I've also experimented with all of the font-rendering and font-smoothing options, but none of them seemed to help.

So, here’s the easiest and most flexible way to do this. This will depend on you being able to serve slightly different CSS to different clients (there are, of course, any number of ways to do this—server-side according to user agent, via JS, etc. etc., so I’ll leave that part up to you).

What you’re going to want to do, to “bulk up” the rendering of the text on the offending clients, is to add this to the post body:

text-shadow: 0 0 0 rgba(0,0,0,0.87);

That’s right: a zero-offset, zero-blur text shadow. The alpha value should be at most equal to the alpha of the text color itself, though you’ll want to adjust it for different combinations of browser/OS. (For example, Chrome on Linux seems to render thicker/darker than Chrome on Windows, so you may want to set the alpha for the text shadow to be much lower for Chrome-on-Linux clients; and Firefox is different, etc.)

This lets you correct for rendering differences across browsers/platforms in a very fine-grained way.

So, it'd be really nice to be able to use the text-shadow trick (I really want to be able to adjust how post-titles look slightly to improve the overall site contrast)

It's the sad case that while this trick looks excellent on my high resolution macbook, it looks kinda pixelated and cruddy on my desktop monitor. I'm curious if you've looked into that at all.

I sure have. What you do is, you use the resolution media query to set different styles for hi-DPI and low-DPI devices (I use a threshold of 192ppi, which includes all Retina screens from Apple, and all 4K monitors I’ve seen, and of course all smartphones from the last 5 years or something).

Then, as I said, you may want to serve slightly different CSS to Linux/Windows clients, and also use another media query to adjust things for Firefox, etc.; adjusting the alpha of the text shadow is the easiest way to do this tweak. (Whether it will in fact be necessary will of course depend on details; you can test that on the platforms/browsers in question and use your judgment.)

Then, you’ll want to provide an exception for Safari (setting for it the same style as you use for the low-DPI displays for Mac clients—regardless of target device), because (so far as I am aware), Safari’s text-shadow support is still buggy. (See, e.g., this GW style sheet, and Cmd-F “Compensating for Safari being terrible”, to see how to target Safari to make such an exception.)

Warnock Pro sadly doesn't have a 500 font-weight available, and instead goes directly from 400 to semibold (600), which is quite a bit too bold, even for Windows machines.

Oh, I hadn't realized it literally didn't exist (as opposed to we didn't happen to load the 500 weight version). It's actually been grating on me a bit that the bold is a bit too bold, and this moves me towards interest in a different font rather than fixing Warnock.

(On my shortform feed awhile ago Said had some additional thoughts on using bold for skimmability that might be worth revisiting if we're thinking about fonts more seriously)

Belated comment on this particular aspect of the problem:

It is an unfortunate fact of digital type design that the mapping between “which of the weights that this font comes with are called ‘Regular’ or ‘Medium’ or ‘Semibold’ or ‘Heavy’ etc.”, and “how thick the letterforms actually are / how heavy does the text look when rendered in that weight” is… horrifically inconsistent from font to font (even among fonts from the same designer or publisher!). In other words, you can easily find two fonts such that one or both of the following hold:

  1. The first font’s “Regular” and its “Bold” differ only mildly, whereas the second font’s “Bold” is massively heavier than its “Regular”
  2. The first font’s “Regular” is about as heavy as the second font’s “Light”, and its “Bold” is comparable in weight to the second font’s “Regular”

(And don’t even get me started about inconsistent weight naming! “Regular” vs. “Book”; what the heck is “Medium”; “Semibold” vs. “DemiBold”; is “Heavy” heavier than “Black” or vice-versa? etc., etc.)

The consequence of this is that if you use the publisher-provided CSS files for fonts (which map designer-provided weights to CSS font-weight values according to the established convention of “Regular” = 400, “Medium” = 500, etc.), then setting the CSS font-weight property of your text to, say, 500 offers you no guarantee of how heavy the text will actually look! (This is compounded, of course, by the fact that not all fonts—much less all digital releases of fonts—come with all nine of the “standard” weight grades.)

And this is why I write my own @font-face rules for every one of the fonts I use. I never use the publisher-provided ones; I look at each font I use, and I determine a custom mapping from provided weights to CSS font-weight values, and write the CSS to define that mapping. This lets me guarantee a much greater degree of consistency when switching fonts, or using alternate fonts for different client platforms, etc. (Of course, this does require hosting the font files myself, rather than relying on a service like Google Fonts or TypeKit; but that is easy.)

(If you’re interested in trying this, I’d be glad to make my custom-written CSS files for many of the popular fonts—such as many of Adobe’s offerings, among others—available to you guys.)

Edit: There are other benefits to rolling your own @font-face rules: you can take advantage of CSS features like unicode-range (as explained, e.g., here) to, e.g., specify the use of one font for most of your text but another font for certain mathematical symbols (note that this is different from using font stacks to define a fallback font, as the latter only comes into play if the primary font doesn’t have glyphs for the given characters, whereas unicode-range also works in the case where the primary font does have those glyphs, but you don’t like the way they look, or they render poorly on certain systems, etc.). This, too, affords you greater flexibility in choosing which fonts to use.

Yep, Valkyrie is new, which is one of the reasons why I got excited about moving to that. And agree on lining figures.

I've experimented with Bembo Book before, but also found it to be a bit too spindly on Windows machines, and it sadly doesn't have a Medium (500) weight that we could set for Windows machines as an alternative (I think). I will experiment with the two other ones, and maybe also try out Bembo again.

Note: I am on Windows and find the font fine. I am wondering how many people on Windows find it hard to read?

It renders pretty decently (though I don't love the actual letterforms, at least not at sizes appropriate for body text) for me both on my laptop, which has a high-DPI display (4k at 15"), and on my desktop machine at work, which has a much lower-DPI display (2560x1600 at 30"). It is a bit spindly on the high-DPI display, but not so badly so as to make the text hard to read at any sensible size. (I've checked these things on both Firefox and Chrome.)