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:
The first font’s “Regular” and its “Bold” differ only mildly, whereas the second font’s “Bold” is massively heavier than its “Regular”
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.
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:
The first font’s “Regular” and its “Bold” differ only mildly, whereas the second font’s “Bold” is massively heavier than its “Regular”
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-weightvalues according to the established convention of “Regular” =400, “Medium” =500, etc.), then setting the CSSfont-weightproperty of your text to, say,500offers 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-facerules 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 CSSfont-weightvalues, 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-facerules: you can take advantage of CSS features likeunicode-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, whereasunicode-rangealso 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.