The real power of variable axes is that it's not related to weight in the slighted. That's the most obvious use-case, but it's just a mechanism to control "which points in a glyph's outline go where based on what one or more variables are set to", so just using it to change weight is... kinda obvious and boring? Let's kick it up a notch:
Also Recursive (https://www.recursive.design) which has the usual weight and slant axis, with cursive alternates which can be toggled explicitly or used automatically when the slant is strong enough, but also a monospace axis (which allows for semi-monospace) and a "casual" axis which changes the whole character of the font.
I like tabular numerals. But you really need a small set of other glyphs to be tabular to really make them work. In particular, you need the plus and minus signs to be the same width, so that in a table like:
gold +1.2%
oil -6.4%
corn +5.2%
everything lines up and looks nice. At the moment, with CSS, there's no way to make that happen, and in normal typefaces the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.
It occurs to me that contextual alternates could make this Just Work. I haven't used any typefaces expensive enough to do that though!
> the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.
In this case, an alternative to "-", U+002D HYPHEN-MINUS, is "−", U+2212 MINUS SIGN. On Linux, I considered mapping the keypad substract key to it, but instead I configured a xcompose alias.
It vexes me that almost no one uses the real minus sign. But you also can't blame them since it's never been made readily-available. So you really have to be pedantic and spend time going to get it if you want to use it.
Most people aren't even aware there's a "real" (or rather, fake) minus sign. I didn't know until reading this thread. The hyphen is right next to the +/= key, so it's not unreasonable at all to think the _/- key is minus.
Yeah I had no idea either, but I'm sorry to say it's going in the same bucket as using a real em-dash vs a double hypen--if it's not on my keyboard it's not gonna happen.
Mac OS has option+- for en dash and option+shift+- for em dash. I used to add similar bindings on Windows via AutoHotkey (which is an amazing app all around...)
There's also option+space for and other goodies. I recently added option+x for "checkmark x" and option+v for "checkmark v" since I like dropping those around more often than I should...
This. Em dashes are—as punctuation goes—downright sexy, so I committed shift+opt+- to muscle memory long ago. And it's arguably less work than a bucked-toothed double hyphen.
Btw, if you haven't already, check out Karabiner on macOS for AutoHotkey-esque functionality.
Re “configured”—what's your locale? In en_US.UTF-8 on my Arch system it's in the system file (/usr/share/X11/locale/en_US.UTF-8/Compose) as <Multi_key> <minus> <underscore>.
HTML 4 was still in this weird in-between time where there were styling attributes in HTML coexisting with the upcoming CSS. Afair no browser ever implemented character alignment and in Google’s HTML it is only written up as obsolete:
Styling in general is of course a CSS thing – but thinking about it arranging alignment in multiple interdependent elements is a problem which not just need a property but a layout algorithm which browsers then need to implement. So we still don’t have nice things.
> It occurs to me that contextual alternates could make this Just Work.
The replacement mechanism in OpenType fonts is surprisingly useful. I remember Apple’s San Francisco font switches between different variants of the colon if it follows text characters ("my proposal: nuke it from the orbit") or if it exists between numbers as in a time ("23:52"); in the latter it is more centered.
I hear you. Back when I was in Investment Banking, I was guilty of replacing hyphens with en dashes in all sorts of labels to make them line up properly in a table... It wasn't perfect, but it was a decent improvement
Generally, numbers were right-aligned in cells, so the % at the end was consistent (when present) and the plus/minus before the numbers didn't make a difference because of the alignment. But labels on the left like in some P&L or Cash Flow statement were always annoying
It's an improvement until someone wants to copy and paste a negative number, then suddenly the closest heavy object to the user is travelling rapidly towards your head.
I suppose one way to make it work in CSS would be to split the numbers on the decimal points, and align the parts as necessary. Though there's no way to get around the <td>/<span> soup, unfortunately.
The easiest solution is to make a custom font with all the glyphs you want to be tabularized given the same advance width. Then you aren't subject to the vagaries of getting advanced font rendering to work.
Also U+2012 FIGURE DASH (for things like phone numbers), and probably U+2212 MINUS SIGN (aligned with plus). Everyone usually defaults to hyphen-minus though, and all bets are off.
Tabular numerals are very useful in certain cases, but I find even more useful the old-style numerals.
By default, I always use old-style numerals, because they are much easier to read, especially for big numbers, for the same reason why the lowercase letters are easier to read, by having ascenders and descenders that break the uniformity of the characters.
I use lining numerals only in the same places where I would use uppercase letters, e.g. in titles or when a sentence begins with a number.
A font of antiquated faſhion doth boaſt moſt excellent and ſubſtantious qualities, yet prithee, what of olde ſtyle figures doſt thou deem hath benefit that I, in mine own diſcretion, might chooſeth?
Caveat: Google Fonts, and by extension Fontsource which mostly just mirrors Googles files, strips out nearly all of the advanced OpenType features to reduce the filesize. It's worth checking the upstream version of your font to see which features it actually offers.
e.g. Wakamai Fondue lists 11 features for Googles version of Inter (some essential ones plus fractions, tabular numbers, numerators, denominators and contextual alts), while the full fat version of Inter has a whopping 44 features (too many to list, see https://rsms.me/inter/).
it's the year of the lord 2024 and OSes still don't ship with a common set of open license fonts with most of unicode like nerdfonts. shameful.
I wish all the effort the big four wasted fighting for emoji supremacy would have been used to normalize a decent set of full unicode fonts once and for all.
Wow, is Inter ever a beautiful typeface. A rare find when there seemed to be a glut of corporate NIH typefaces for a while.
macOS used to ship with a beautiful Hebrew typeface that was like the open-source font Shofar, but it seems to have been removed. I do not see similar Hebrew letters in one of the remaining typefaces. I imagine that it is not easy to give a typeface a consistent feel, in all Latin and non-Latin character sets, to the fluent readers of those languages.
The number of fonts that include even two good alphabets is pretty low. I have run into needing english and greek or cyrillic in the same document. I know of like three good fonts that have a good english and a good greek. My eye isn't as practiced at looking at cyrillic fonts but it seems even rarer for that combination.
Which honestly makes sense and there may not be a solution for. Different alphabets and writing systems have their own typographical histories and conventions. It's reasonable that there is a very limited design space where you're adhering to the conventions of two separate systems as well as maintaining interior consistency.
English is a language, Cyrillic is an alphabet, and Greek is both. The alphabet one finds in the range U+0000 to U+007F is called "Latin", not "English". If any alphabet has a claim on being "English", it's Shavian. (Found at U+10450 to U+1047F.)
Inter quickly became my go-to sans serif font for the web. In A/B tests it somehow always looks better than anything, frequently by wide margins—which is saying something when you’re basically running through a dozen variations on Helvetica.
Can't expect the big four to use their immeasurable wealth for the common good, now can we?
If anyone, then distro creators and maintainers will have to make that step. Google surely enjoys getting so much information due to hapless users loading Googlefonts on websites.
In some important areas France has better laws than other EU countries. Another example I believe was about avoiding wasting food on the supply chain of food to supermarkets and what happens with food afterwards.
Proprietary OS problem. Linux distributions package and distribute all the fonts they're legally allowed to ship. Every font I ever cared to use can be found in the repositories. And they don't strip out features either. I get to customize everything about Fira Code.
> Every font I ever cared to use can be found in the repositories.
If you have to download/install them separately then it means it doesn't ship with it. The fact that you can install it from the distro repositories means nothing to a third party website that can't assume you have done so.
Websites can't really assume anything that's not a web standard. If this is important to them, they should be lobbying the web standards bodies to come up with a list of fonts that browsers are required to make available. Then the browsers will pull them in as dependencies when they're installed.
The Linux distributions did their jobs with excellence. The fonts are all there and installing them is a oneliner. The web folks made their own OS though so if anyone is to be blamed it's whoever is in charge of that OS called the web platform.
Who's in charge of the web as a platform these days? Google. Who is no doubt profiting from the Google Fonts thing.
correct. that's why I mention the nerdfonts as the holy grail.
but without the big OSes agreeing on a new unicode, today it's technically impossible to have a single unicode font (see how noto ships 200 variants on linux, all having some 500mb and only differing a few chars from one another. it's a monstrosity)
Noto doesn't ship with OS, and users need multiple fonts for different use cases.
Grandparent comment is saying that Microsoft, Google, Apple could settle on a common set of open licence fonts and bundle them with the OS (and Linux distros / other OSS OSes could also do the same). Then web design & dev could rely on those fonts without having to locally serve them, or embed with Google fonts, etc. Noto could indeed be one of the bundled fonts in this alternate reality.
But no real incentive for any of those big players to do so, and disincentive for Google who gain surveillance data from font embeds as noted elsewhere in thread.
Although if you're not too picky about the finer details or being perfectly consistent across every platform, the system fonts are generally good enough nowadays to put together a pretty decent stack without having to resort to serving web fonts.
Wow. Do you happen to know if that just for API-based usage, or for downloads too?
> The Google Fonts API currently does not support requesting the inclusion of optional (also known as discretionary, or opt-in) OpenType Features, such as Stylistic Sets (salt) or Small Caps (smcp, c2sc). Instead the glyphs contained in these features may be published as a separate family…https://googlefonts.github.io/gf-guide/requirements.html#ope...
Sometimes they might also ship outdated versions, e.g. the last released version of Fira Sans is 4.301, but Google still only serves version 4.203. Plus technically Fira Sans has been superseded by Fira Go, which includes additional scripts, but Google doesn't offer that one at all.
Not really related: to get VSCode to support comments, jsdocs, other syntax highlighting features using different fonts, you will probably have to use the extension vscode-custom-css from be5invis: https://github.com/be5invis/vscode-custom-css
Why are font features so difficult to support correctly?
Because the standards are mostly a result of slapping the name "OpenType" on existing behavior. There's maybe three or four ways to encode any given piece of information. The standards are a mess.
You can identify a font as italic in four different places with varying semantics. Off the top of my head, three different places to mark a font as bold (and this may not jive with the weight). Three different ways to specify vector glyphs (five if you include 'COLR' and SVG). Raster glyphs? Do you want PNG, JPEG, TIFF, or raw bytes? Should the raw data be bit or byte aligned?
The result of that complexity is that fonts often have all sorts of conflicting information. Depending on what behavior you're referring to specifically I'd be that the fonts themselves may be to blame. TrueType style glyphs specifically put a lot of burden for getting the hinting right on the font designer. CFF/CFF2 doesn't.
Noto went full Google. Noto Display was abandoned a few years ago. In their own words it's not intended to be what most folks would consider a display font so there's no good replacement. The metadata in last release is all kinds of fucked up.
Names are a hilarious shit show, what constitutes an appropriate name varies from font to font leaving app makers to come up with their own magic and leaving font selection a huge mess. Plus names can be encoded in any number of encodings. Apple still has MacRoman encoded strings in some of their fonts. Is Arial Black the black weight of Arial or a whole new font family?
Yeah, I'm waiting to see if BM condensed ever arrives. I am thinking it won't. I don't think it would take this long if they really intended to get v2 out the door. It's vaporware.
Would also love to see v2 finally get released, since I'm a big fan of Berkeley Mono and would like more weights and widths to make my Emacs look nicer.
From their update in february[1] this year it seems like it is basically complete but personal things got in the way and maybe they struggle to set up the systems for custom builds, ecommerce, etc. to ship it. People are constantly asking for the release, so I think it will eventually arrive, but good things often take longer than expected. :)
I've bought v1 and I'm quite happy with it as it is. It's just that I've been looking forward to the tweaks that'd been described for the last year and a half, like[0]:
"We threw away almost all of v1.00X, Berkeley Mono v2.000 improves substantially on legibility, fitting, and cohesiveness, especially for bold weights."
If I hadn't heard of v2 I wouldn't be missing it. But I have heard of it, goshdarnit, and now I want to see the new shininess!
What is going on with the wght (weight) axis? When I slide to the left of 400, the text condenses as it gets thinner. But to the right of 400, the text does not expand, it just gets thicker. So it would not appear to be a continuous variable, as the slider would suggest.
If you like typography, check out Butterick's Practical Typography: https://practicaltypography.com/ It's full of good, pragmatic advice on how to make printed and digital documents look wonderful.
I've bought two fonts from him and his font license is easily the most permissive of any paid professional font I've seen: no restrictions on the number of page views or anything, unlike most other pro fonts. Are his fonts open source? No. Are there good open source fonts? Of course. But are his fonts beautiful? You bet. I've got Valkyrie and Concourse. Concourse is particularly flexible when it comes to contextual alternatives and such.
Nice thanks! I'm happy to pay for a good font but the page view restrictions and all have always bothered me. Not a fan of the idea that they might end up extorting large sums out of you down the line if your site becomes popular or if you want to to build an app with the font to keep your branding consistent.
I made a video showcasing some advanced techniques to use fonts on the web, without compromising performance. Covers interesting font metrics like ascenders and descenders. Fascinating to see how much information is contained within a font file!
Fascinating that it's just now that someone got curious about this enough to write a post. I know if you looked for it you'd probably find this stuff but it is definitely scarce IMO. Thing is, not enough developers and designers that worked on this for many years bother to blog about it perhaps for reasonable reasons but still.
Hate to break it to you but there are whole conferences, 100s books and indeed websites about this stuff. https://www.typewolf.com/resources
Maybe it might seem like nobody is talking about this but if you are designer/student you know about this
Loading a font can cause multiple things including load time delay. For example, connecting to Google and downloading a Lato font is around 4-5 requests + js + CSS files + 500kb added download.
Processing the font itself also is at least 500ms to a second depending on the device type.
We keep the total requests under 25, which cannot be done after multiple 3rd party fonts are added.
Additionally, some fonts can introduce CLS (content layout shift) after the font is loaded. Especially H tags because they shift a lot. CLS = your SEO is dead.
For speed purposes, especially mobile, using a 3rd party font is SEO suicide.
The sites we build for our clients are below 1.2 second mobile and 0.2 second desktop load time which gives these sites an enormous SEO advantage. These load times are complete loads, not initial draws or TTFBs. (results are provided by Google page speed insights - https://pagespeed.web.dev/) These load times change when we use the client's own fonts or the ones they pick from Google fonts. We have this discussion almost every time we onboard a new client.
Processing the font itself also is at least 500ms to a second
depending on the device type.
I think that's off by quite a lot.
On my MacBook Pro I can dump one of the Helvetica Neue faces in one second with ttx (fonttools). If a python script can parse a font, create an XML representation, and write a pretty printed version of that to disk in a second then yea 500 ms seems really slow.
Hell, typst (rust) can render a PDF with two subsetted fonts (Apple Color Emoji + Cambria Math) in about 750 ms. I certainly hope Harfbuzz is at least that fast.
Emulated Moto G Power with Lighthouse 12.2.0 - Slow 4G throttling.
With slow download and rendering it is probably more than 500ms in my opinion. Either way, I won't leave money on the table and sacrifice 1% better-looking fonts, even if it is for 10ms. Mobile load time is the #1 SEO signal these days and will stay #1 for a long time.
Right, but your claim was that just processing the font would take 500 ms. No idea what a Moto G Power is or how fast it is, but 500 ms for processing still seems like a pessimistic estimate.
I've no idea what sort of overhead Google adds to font downloads either, but assuming WOFF2 format the font itself should be well under 100k. Granted WOFF2 is fairly new (2018), but it's fairly well supported these days. I'd expect Google Fonts to support it as WOFF2 was Google's attempt at wringing out a bit more optimization out SFNT fonts.
Alright, sorry to make it sound like that. Either way, it adds overhead (local or Google) but CDN-loaded ones cause more issues. Google Fonts is the web's standard for non-system fonts and indeed it adds CSS, JS, additional requests, and the font itself, including wait times due to download and load. SEO is a competitive environment, even a single request, and ms counts. Small blogs might not care but if your website gets traffic, those little millisecond differences rank your posts differently.
Our pages are around 80kb in total (yes you are reading correctly, not 800kb but 80kb including images of the blog posts, including the WebP images, javascript, CSS, and the HTML file itself. Imagine doubling or quadrupling it just for a font. That would be insanity. 100kb font size is absurd if you want your mobile speed (#1 SEO factor today) to be better.
Core Web Vitals scores us 100% for everything. This drops to 80%~ when we use external fonts. We tried 100s of different metrics. The font is a major factor (again, doesn't matter local or Google). Added overhead is going to sink your ranks like a rock.
For anyone reading this, do not use Google fonts if you want your SEO to be better.
Well, subset the fonts, remove unnecessary flavors, move the font to your own cdn. Problem solved. If this affects SEO... oh dear god, the internet became a sh*thole.
as a designer by education, this level of font control for web is delusional. and mostly a waste of time (both for the designers and the users receiving on unexpected screen ratios/resolutions/tech/era/etc and getting a worse experience if the designers hadn't wasted the time)
this brings me bad memories from the time websites were done by "desktop publishing" designers and html was crafted "pixel perfect" (with tables)
thankfully I can easily be a curmudgeon and just set all sites to use my favorite fixed width font and disable the designers choice with one checkbox on firefox.
> Since such numerals line up when typed on multiple lines, they're useful in, well, tabular data: tables, bills, reports, you name it.
Or things like showing a clock, countdown, whatever. A time that "jumps around" on the screen from one second to the next annoys the hell out of me...
The real power of variable axes is that it's not related to weight in the slighted. That's the most obvious use-case, but it's just a mechanism to control "which points in a glyph's outline go where based on what one or more variables are set to", so just using it to change weight is... kinda obvious and boring? Let's kick it up a notch:
https://v-fonts.com/fonts/extendomatic-variable
https://v-fonts.com/fonts/tatras-shaded
https://v-fonts.com/fonts/wavefont
Also Recursive (https://www.recursive.design) which has the usual weight and slant axis, with cursive alternates which can be toggled explicitly or used automatically when the slant is strong enough, but also a monospace axis (which allows for semi-monospace) and a "casual" axis which changes the whole character of the font.
Tabular numerals are such a valuable feature. It's a bummer they're not more prevalent.
I like tabular numerals. But you really need a small set of other glyphs to be tabular to really make them work. In particular, you need the plus and minus signs to be the same width, so that in a table like:
everything lines up and looks nice. At the moment, with CSS, there's no way to make that happen, and in normal typefaces the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.It occurs to me that contextual alternates could make this Just Work. I haven't used any typefaces expensive enough to do that though!
> the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.
In this case, an alternative to "-", U+002D HYPHEN-MINUS, is "−", U+2212 MINUS SIGN. On Linux, I considered mapping the keypad substract key to it, but instead I configured a xcompose alias.
It vexes me that almost no one uses the real minus sign. But you also can't blame them since it's never been made readily-available. So you really have to be pedantic and spend time going to get it if you want to use it.
Most people aren't even aware there's a "real" (or rather, fake) minus sign. I didn't know until reading this thread. The hyphen is right next to the +/= key, so it's not unreasonable at all to think the _/- key is minus.
That's hyphen-minus, which is both a hyphen AND a minus:
https://en.wikipedia.org/wiki/Hyphen-minus
Yeah I had no idea either, but I'm sorry to say it's going in the same bucket as using a real em-dash vs a double hypen--if it's not on my keyboard it's not gonna happen.
Mac OS has option+- for en dash and option+shift+- for em dash. I used to add similar bindings on Windows via AutoHotkey (which is an amazing app all around...)
There's also option+space for and other goodies. I recently added option+x for "checkmark x" and option+v for "checkmark v" since I like dropping those around more often than I should...
This. Em dashes are—as punctuation goes—downright sexy, so I committed shift+opt+- to muscle memory long ago. And it's arguably less work than a bucked-toothed double hyphen.
Btw, if you haven't already, check out Karabiner on macOS for AutoHotkey-esque functionality.
Re “configured”—what's your locale? In en_US.UTF-8 on my Arch system it's in the system file (/usr/share/X11/locale/en_US.UTF-8/Compose) as <Multi_key> <minus> <underscore>.
Back in the days of HTML 4.01 there was the idea of an align attribute where possible numerical data could auto-align on a specified character:
https://www.w3.org/TR/html401/struct/tables.html#h-11.3.2HTML 4 was still in this weird in-between time where there were styling attributes in HTML coexisting with the upcoming CSS. Afair no browser ever implemented character alignment and in Google’s HTML it is only written up as obsolete:
https://html.spec.whatwg.org/multipage/obsolete.html#dom-tab...
Styling in general is of course a CSS thing – but thinking about it arranging alignment in multiple interdependent elements is a problem which not just need a property but a layout algorithm which browsers then need to implement. So we still don’t have nice things.
> It occurs to me that contextual alternates could make this Just Work.
The replacement mechanism in OpenType fonts is surprisingly useful. I remember Apple’s San Francisco font switches between different variants of the colon if it follows text characters ("my proposal: nuke it from the orbit") or if it exists between numbers as in a time ("23:52"); in the latter it is more centered.
I hear you. Back when I was in Investment Banking, I was guilty of replacing hyphens with en dashes in all sorts of labels to make them line up properly in a table... It wasn't perfect, but it was a decent improvement
Generally, numbers were right-aligned in cells, so the % at the end was consistent (when present) and the plus/minus before the numbers didn't make a difference because of the alignment. But labels on the left like in some P&L or Cash Flow statement were always annoying
It's an improvement until someone wants to copy and paste a negative number, then suddenly the closest heavy object to the user is travelling rapidly towards your head.
I suppose one way to make it work in CSS would be to split the numbers on the decimal points, and align the parts as necessary. Though there's no way to get around the <td>/<span> soup, unfortunately.
The easiest solution is to make a custom font with all the glyphs you want to be tabularized given the same advance width. Then you aren't subject to the vagaries of getting advanced font rendering to work.
>you need the plus and minus signs to be the same width
I've never thought about it, but that is somewhat annoying that the math symbols aren't a consistent width with each other.
chuckle
Now throw in inline vs block equations into the mix.
Any font without tabular numbers is buggy, because it can't support U+2007 FIGURE SPACE  
Also U+2012 FIGURE DASH (for things like phone numbers), and probably U+2212 MINUS SIGN (aligned with plus). Everyone usually defaults to hyphen-minus though, and all bets are off.
Pretty sure most browsers render <ol><li> with tabular nums if available.
Bookman Old Style (my favorite font) seems to do this.
Tabular numerals are very useful in certain cases, but I find even more useful the old-style numerals.
By default, I always use old-style numerals, because they are much easier to read, especially for big numbers, for the same reason why the lowercase letters are easier to read, by having ascenders and descenders that break the uniformity of the characters.
I use lining numerals only in the same places where I would use uppercase letters, e.g. in titles or when a sentence begins with a number.
>I find even more useful the old-style numerals
A font of antiquated faſhion doth boaſt moſt excellent and ſubſtantious qualities, yet prithee, what of olde ſtyle figures doſt thou deem hath benefit that I, in mine own diſcretion, might chooſeth?
Set thy eyes on this excellent Font, for Inſtance: https://en.m.wikipedia.org/wiki/Georgia_(typeface)#/media/Fi...
As can be moſt clearly ſeen, the Numerals are not of equale Height, but poſſeſs Deſcendants, like the 4, and Aſcendants, like the 6.
Shouldſt thou deſire to embelliſh thy Layout with ſuch a Rendition of Numerals, thou canst: https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...
This Feature requireth though that the Font ſo employed containéd the proper Variants of the numeral Glyphs. Many a diſtinguished Font do.
(Pray note that the -th Ending of Verbs is for Singular Third Perſon Form, not to be uſed with "thou". I do, thou dost, he doth.)
You must be Welsh!
Have a font file you want to investigate? See if it supports whatever features? https://wakamaifondue.com is your friend
And if you want to work with fonts locally I recommend https://github.com/fonttools/fonttools
In particular the `ttx` tool is great for digging into the innards of font files.
That is an immensely cool site, thanks for linking it!
Caveat: Google Fonts, and by extension Fontsource which mostly just mirrors Googles files, strips out nearly all of the advanced OpenType features to reduce the filesize. It's worth checking the upstream version of your font to see which features it actually offers.
e.g. Wakamai Fondue lists 11 features for Googles version of Inter (some essential ones plus fractions, tabular numbers, numerators, denominators and contextual alts), while the full fat version of Inter has a whopping 44 features (too many to list, see https://rsms.me/inter/).
it's the year of the lord 2024 and OSes still don't ship with a common set of open license fonts with most of unicode like nerdfonts. shameful.
I wish all the effort the big four wasted fighting for emoji supremacy would have been used to normalize a decent set of full unicode fonts once and for all.
Wow, is Inter ever a beautiful typeface. A rare find when there seemed to be a glut of corporate NIH typefaces for a while.
macOS used to ship with a beautiful Hebrew typeface that was like the open-source font Shofar, but it seems to have been removed. I do not see similar Hebrew letters in one of the remaining typefaces. I imagine that it is not easy to give a typeface a consistent feel, in all Latin and non-Latin character sets, to the fluent readers of those languages.
The number of fonts that include even two good alphabets is pretty low. I have run into needing english and greek or cyrillic in the same document. I know of like three good fonts that have a good english and a good greek. My eye isn't as practiced at looking at cyrillic fonts but it seems even rarer for that combination.
Which honestly makes sense and there may not be a solution for. Different alphabets and writing systems have their own typographical histories and conventions. It's reasonable that there is a very limited design space where you're adhering to the conventions of two separate systems as well as maintaining interior consistency.
English is a language, Cyrillic is an alphabet, and Greek is both. The alphabet one finds in the range U+0000 to U+007F is called "Latin", not "English". If any alphabet has a claim on being "English", it's Shavian. (Found at U+10450 to U+1047F.)
thats the kind of nitpick that got us where we are today :)
if you're talking with users, you assume alphabets and map from the languages.
Inter quickly became my go-to sans serif font for the web. In A/B tests it somehow always looks better than anything, frequently by wide margins—which is saying something when you’re basically running through a dozen variations on Helvetica.
Can't expect the big four to use their immeasurable wealth for the common good, now can we?
If anyone, then distro creators and maintainers will have to make that step. Google surely enjoys getting so much information due to hapless users loading Googlefonts on websites.
Which is why France's interpretation of the GDPR banned it
In some important areas France has better laws than other EU countries. Another example I believe was about avoiding wasting food on the supply chain of food to supermarkets and what happens with food afterwards.
Proprietary OS problem. Linux distributions package and distribute all the fonts they're legally allowed to ship. Every font I ever cared to use can be found in the repositories. And they don't strip out features either. I get to customize everything about Fira Code.
> Every font I ever cared to use can be found in the repositories.
If you have to download/install them separately then it means it doesn't ship with it. The fact that you can install it from the distro repositories means nothing to a third party website that can't assume you have done so.
Websites can't really assume anything that's not a web standard. If this is important to them, they should be lobbying the web standards bodies to come up with a list of fonts that browsers are required to make available. Then the browsers will pull them in as dependencies when they're installed.
The Linux distributions did their jobs with excellence. The fonts are all there and installing them is a oneliner. The web folks made their own OS though so if anyone is to be blamed it's whoever is in charge of that OS called the web platform.
Who's in charge of the web as a platform these days? Google. Who is no doubt profiting from the Google Fonts thing.
correct. that's why I mention the nerdfonts as the holy grail.
but without the big OSes agreeing on a new unicode, today it's technically impossible to have a single unicode font (see how noto ships 200 variants on linux, all having some 500mb and only differing a few chars from one another. it's a monstrosity)
> a common set of open license fonts with most of unicode
I am (clearly) clueless here, but isn't that what Noto's supposed to be?
Noto doesn't ship with OS, and users need multiple fonts for different use cases.
Grandparent comment is saying that Microsoft, Google, Apple could settle on a common set of open licence fonts and bundle them with the OS (and Linux distros / other OSS OSes could also do the same). Then web design & dev could rely on those fonts without having to locally serve them, or embed with Google fonts, etc. Noto could indeed be one of the bundled fonts in this alternate reality.
But no real incentive for any of those big players to do so, and disincentive for Google who gain surveillance data from font embeds as noted elsewhere in thread.
Although if you're not too picky about the finer details or being perfectly consistent across every platform, the system fonts are generally good enough nowadays to put together a pretty decent stack without having to resort to serving web fonts.
https://github.com/system-fonts/modern-font-stacks
Even if you are using web fonts, those stacks make for good fallbacks.
Apple ships six Noto fonts (non-Latin alphabets) with the current version of MacOS.
first of, currently it is impossible to cover all of unicode because, surprise surprise, we still have page table issues!
the same char in zh, tw, jp, kr might use the same unicode id but have different glyphs.
secondly, yes, but even google fonts strip most things from noto it serves because they want the fine grain data of each site/user is using wink wink.
Wow. Do you happen to know if that just for API-based usage, or for downloads too?
> The Google Fonts API currently does not support requesting the inclusion of optional (also known as discretionary, or opt-in) OpenType Features, such as Stylistic Sets (salt) or Small Caps (smcp, c2sc). Instead the glyphs contained in these features may be published as a separate family… https://googlefonts.github.io/gf-guide/requirements.html#ope...
I think that might depend on particular font, but from what I tested, manually downloaded fonts do include OpenType features like smcp or swsh
Sometimes they might also ship outdated versions, e.g. the last released version of Fira Sans is 4.301, but Google still only serves version 4.203. Plus technically Fira Sans has been superseded by Fira Go, which includes additional scripts, but Google doesn't offer that one at all.
Nothing really to add... other than the type on that page looks gorgeous.
Really? The headings look mediaeval
Not really related: to get VSCode to support comments, jsdocs, other syntax highlighting features using different fonts, you will probably have to use the extension vscode-custom-css from be5invis: https://github.com/be5invis/vscode-custom-css
Mine is:
Which looks like the last picture in this comment: https://github.com/microsoft/vscode/issues/36512#issuecommen...Just be prepared to experiment a lot, VSCode's (Electron's?) font handling is buggy.
Why are font features so difficult to support correctly?
You can identify a font as italic in four different places with varying semantics. Off the top of my head, three different places to mark a font as bold (and this may not jive with the weight). Three different ways to specify vector glyphs (five if you include 'COLR' and SVG). Raster glyphs? Do you want PNG, JPEG, TIFF, or raw bytes? Should the raw data be bit or byte aligned?
The result of that complexity is that fonts often have all sorts of conflicting information. Depending on what behavior you're referring to specifically I'd be that the fonts themselves may be to blame. TrueType style glyphs specifically put a lot of burden for getting the hinting right on the font designer. CFF/CFF2 doesn't.
Noto went full Google. Noto Display was abandoned a few years ago. In their own words it's not intended to be what most folks would consider a display font so there's no good replacement. The metadata in last release is all kinds of fucked up.
Names are a hilarious shit show, what constitutes an appropriate name varies from font to font leaving app makers to come up with their own magic and leaving font selection a huge mess. Plus names can be encoded in any number of encodings. Apple still has MacRoman encoded strings in some of their fonts. Is Arial Black the black weight of Arial or a whole new font family?
This was my nudge to see if Berkeley Mono v2 is out yet.
It is not.
What I’d really love would be a proportional version of Berkeley Mono.
Yeah, I'm waiting to see if BM condensed ever arrives. I am thinking it won't. I don't think it would take this long if they really intended to get v2 out the door. It's vaporware.
Would also love to see v2 finally get released, since I'm a big fan of Berkeley Mono and would like more weights and widths to make my Emacs look nicer.
From their update in february[1] this year it seems like it is basically complete but personal things got in the way and maybe they struggle to set up the systems for custom builds, ecommerce, etc. to ship it. People are constantly asking for the release, so I think it will eventually arrive, but good things often take longer than expected. :)
[1]: https://x.com/usgraphics/status/1762128387483824160
Houston Mono has also been indefinitely delayed...
BM condensed, where does that land on the Bristol stool scale? Sorry I couldn't resist.
I am actually curious about this though, the Berkeley Mono font I found with a search does look quite nice. What's the deal with v2?
I've bought v1 and I'm quite happy with it as it is. It's just that I've been looking forward to the tweaks that'd been described for the last year and a half, like[0]:
"We threw away almost all of v1.00X, Berkeley Mono v2.000 improves substantially on legibility, fitting, and cohesiveness, especially for bold weights."
If I hadn't heard of v2 I wouldn't be missing it. But I have heard of it, goshdarnit, and now I want to see the new shininess!
[0]https://x.com/usgraphics/status/1629588764560625664
Small caps looks slick. I wish more websites used it.
I commented elsewhere on this; Butterick uses small caps for internal links in Practical Typography: https://practicaltypography.com/
I think he got this style from classic reference books like Elements of Style. It does look super sharp.
Yeah, that's where I first encountered them too and liked it a lot. I'm now using small caps for links in my Obsidian, I like it a lot
What is going on with the wght (weight) axis? When I slide to the left of 400, the text condenses as it gets thinner. But to the right of 400, the text does not expand, it just gets thicker. So it would not appear to be a continuous variable, as the slider would suggest.
It still expands, just not as much as before.
There is a step change of difference. Wondering why.. is that a glitch or programmed into the font
If you like typography, check out Butterick's Practical Typography: https://practicaltypography.com/ It's full of good, pragmatic advice on how to make printed and digital documents look wonderful.
I've bought two fonts from him and his font license is easily the most permissive of any paid professional font I've seen: no restrictions on the number of page views or anything, unlike most other pro fonts. Are his fonts open source? No. Are there good open source fonts? Of course. But are his fonts beautiful? You bet. I've got Valkyrie and Concourse. Concourse is particularly flexible when it comes to contextual alternatives and such.
Swiss typefaces https://www.swisstypefaces.com/ have similar licensing and are one of the highest quality foundries period
Nice thanks! I'm happy to pay for a good font but the page view restrictions and all have always bothered me. Not a fan of the idea that they might end up extorting large sums out of you down the line if your site becomes popular or if you want to to build an app with the font to keep your branding consistent.
I made a video showcasing some advanced techniques to use fonts on the web, without compromising performance. Covers interesting font metrics like ascenders and descenders. Fascinating to see how much information is contained within a font file!
https://www.youtube.com/watch?v=wSOIbdOaKR8
Fascinating that it's just now that someone got curious about this enough to write a post. I know if you looked for it you'd probably find this stuff but it is definitely scarce IMO. Thing is, not enough developers and designers that worked on this for many years bother to blog about it perhaps for reasonable reasons but still.
Hate to break it to you but there are whole conferences, 100s books and indeed websites about this stuff. https://www.typewolf.com/resources Maybe it might seem like nobody is talking about this but if you are designer/student you know about this
Maybe for print, it is important but for the web, we must stick to system fonts for SEO and speed.
How does font type influence SEO and speed!?
Loading a font can cause multiple things including load time delay. For example, connecting to Google and downloading a Lato font is around 4-5 requests + js + CSS files + 500kb added download.
Processing the font itself also is at least 500ms to a second depending on the device type.
We keep the total requests under 25, which cannot be done after multiple 3rd party fonts are added.
Additionally, some fonts can introduce CLS (content layout shift) after the font is loaded. Especially H tags because they shift a lot. CLS = your SEO is dead.
For speed purposes, especially mobile, using a 3rd party font is SEO suicide.
The sites we build for our clients are below 1.2 second mobile and 0.2 second desktop load time which gives these sites an enormous SEO advantage. These load times are complete loads, not initial draws or TTFBs. (results are provided by Google page speed insights - https://pagespeed.web.dev/) These load times change when we use the client's own fonts or the ones they pick from Google fonts. We have this discussion almost every time we onboard a new client.
On my MacBook Pro I can dump one of the Helvetica Neue faces in one second with ttx (fonttools). If a python script can parse a font, create an XML representation, and write a pretty printed version of that to disk in a second then yea 500 ms seems really slow.
Hell, typst (rust) can render a PDF with two subsetted fonts (Apple Color Emoji + Cambria Math) in about 750 ms. I certainly hope Harfbuzz is at least that fast.
Google's crawl emulation is based on this:
Emulated Moto G Power with Lighthouse 12.2.0 - Slow 4G throttling.
With slow download and rendering it is probably more than 500ms in my opinion. Either way, I won't leave money on the table and sacrifice 1% better-looking fonts, even if it is for 10ms. Mobile load time is the #1 SEO signal these days and will stay #1 for a long time.
Right, but your claim was that just processing the font would take 500 ms. No idea what a Moto G Power is or how fast it is, but 500 ms for processing still seems like a pessimistic estimate.
I've no idea what sort of overhead Google adds to font downloads either, but assuming WOFF2 format the font itself should be well under 100k. Granted WOFF2 is fairly new (2018), but it's fairly well supported these days. I'd expect Google Fonts to support it as WOFF2 was Google's attempt at wringing out a bit more optimization out SFNT fonts.
Alright, sorry to make it sound like that. Either way, it adds overhead (local or Google) but CDN-loaded ones cause more issues. Google Fonts is the web's standard for non-system fonts and indeed it adds CSS, JS, additional requests, and the font itself, including wait times due to download and load. SEO is a competitive environment, even a single request, and ms counts. Small blogs might not care but if your website gets traffic, those little millisecond differences rank your posts differently.
Our pages are around 80kb in total (yes you are reading correctly, not 800kb but 80kb including images of the blog posts, including the WebP images, javascript, CSS, and the HTML file itself. Imagine doubling or quadrupling it just for a font. That would be insanity. 100kb font size is absurd if you want your mobile speed (#1 SEO factor today) to be better.
Core Web Vitals scores us 100% for everything. This drops to 80%~ when we use external fonts. We tried 100s of different metrics. The font is a major factor (again, doesn't matter local or Google). Added overhead is going to sink your ranks like a rock.
For anyone reading this, do not use Google fonts if you want your SEO to be better.
Well, subset the fonts, remove unnecessary flavors, move the font to your own cdn. Problem solved. If this affects SEO... oh dear god, the internet became a sh*thole.
Crazy how most fonts don't support any of this... (update: oops, I'm wrong!)
Almost all fonts commonly used today support most if not all of this (except for variable axes, because that's still a relatively new development)
Variable Axes have been around since Adobe Multiple Masters in the mid to early 90s:
https://web.archive.org/web/20091223045132/http://partners.a...
But the "fvar" table [1], as part of the OpenType specification, has not.
[1] https://learn.microsoft.com/en-us/typography/opentype/spec/f...
Because not all typefaces are OpenType, and not all OpenType typefaces have features set.
I'm a bit surprised as I thought this was common knowledge for web designers and developers.
Though to check the features or variable ranges of an OpenType file, you can use something like fontdrop.info.
Beautiful letters?
Or ugly ones I want some high-quality Comic Sans font.
That live demo on the page is solid by the way.
[dead]
[dead]
TIL several useful things about typefaces!
as a designer by education, this level of font control for web is delusional. and mostly a waste of time (both for the designers and the users receiving on unexpected screen ratios/resolutions/tech/era/etc and getting a worse experience if the designers hadn't wasted the time)
this brings me bad memories from the time websites were done by "desktop publishing" designers and html was crafted "pixel perfect" (with tables)
thankfully I can easily be a curmudgeon and just set all sites to use my favorite fixed width font and disable the designers choice with one checkbox on firefox.
> delusional
Hard disagree.
> pixel perfect
I prefer that era of wob design to now.