Subscribe: Clagnut
Added By: Feedage Forager Feedage Grade B rated
Language: English
axes  champion  chrome safari  chrome  design  fonts  https  safari  sans  source sans  text  variable fonts  variable  variations  weight 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Clagnut


A blog by Richard Rutter. Root through a heap of web design and development stuff and a few other tasty morsels. (latest 5 posts in full)

Copyright: Copyright 2003-2018, Richard Rutter

How to use variable fonts in the real world

Thu, 25 Jan 2018 17:18:51 PST

A variable font is a single font file which behaves like multiple styles. (I wrote more about them [here]( in an extract from my Web Typography book). There are plenty of sites out there [demoing the possibilities]( of variable fonts and the font variation technology within, but for the new [Ampersand conference website]( I wanted to show variable fonts being using in a real, production context. It might well be the first commercial site ever to do so. Two months ago browser support for variable fonts was only 7%, but as of this morning [support was at over 60%]( This means font variations is a usable technology right now. But not all support is equal, as you’ll see. Variable font capable software is already more pervasive than you might think. For example, the latest versions of Photoshop and Illustrator support them, and if you’re using macOS 10.13+ or iOS 11+ the system font San Francisco uses font variations extensively. That said, the availability of variable fonts for use is extremely limited. At the time of writing there are very few commercial variable webfonts available ([Dunbar](​ and [Fit](​ are notable exceptions), but there is a growing number of free and experimental variable webfonts, as showcased in the [Axis Praxis]( playground. From this limited palette of fonts, we (by which I mean Clearleft designer [James Gilyead]( chose [Mutator Sans]( for the display text, and [Source Sans]( for the body text in a Saul Bass-inspired design. Both fonts enabled us to make use of their variable weight axis. Fonts chosen now came the tricky, multi-step business of implementing variable fonts into the website. I’ll take you through how we (by which I mean Clearleft developer [Mark Perkins]( did it, using simplified code snippets. ## 1. Link to the fonts Getting your variable fonts working in a basic fashion is fairly straight forward. At the time of writing Safari has the most complete support. If you’re following along with these steps, that’s what you’ll need to start off with. We downloaded the Source Sans variable font from its home [on Github]( and used @font-face with a format of `truetype-variations` to link it up to the stylesheet: @font-face { font-family: 'SourceSans'; src: url('source-sans-variable.ttf') format('truetype-variations'); } We could then set the variable Source Sans font as the main typeface for the page in the usual way: html { font-family: 'SourceSans', sans-serif; } ## 2. Set the weights The variable font implementation in CSS is designed to use existing properties for certain pre-defined variation axes. We’re using three weights within the body text: regular, semibold and black. We set the bold fonts using `font-weight` in the usual way: .hero { font-weight: 900; } .blurb { font-weight: 600; } With variable fonts, your weight doesn’t have to be limited to intervals of 100. It can be any integer in the range 1–999. For the main heading, set in Mutator Sans, we used subtle differences in weight for each letter to give a more hand-drawn feel to the design: b:nth-child(1) { font-weight: 300; } b:nth-child(2) { font-weight: 250; } b:nth-child(3) { font-weight: 275; } ## 3. Fix for browsers which are not Safari The code outlined above is enough to get variable fonts working in Safari exactly as we’d want. It shows the correct way to do things (and the way things will be able to be done in the future). Chrome 62+, Firefox 57+ and Edge 17+ all support variable fonts (Firefox only on a Mac and if you s[...]

Getting started with variable fonts

Tue, 21 Feb 2017 19:47:49 PST

The following is an unedited extract from my [forthcoming book]( In October 2016, version 1.8 of OpenType was [released](, and with it an extensive new technology: OpenType Font Variations. More commonly known as variable fonts, the technology enables a single font file to behave like multiple fonts. This is done by defining variations within the font, which are interpolated along one or more axes. Two of these axes might be width and weight, but the type designer can define many others too. Gingham variable font with continuous variation along width and weight axes The preceding image shows a variable font rendered in 36 different styles, all from one file. If you were to pick four styles and serve them as normal fonts, a variable font file capable of providing the same styles would be significantly smaller than the four separate files, with the added speed advantage of requiring just one call to the server. The illustration varies width and weight. Those two axes alone mean that, according to the OpenType Font Variations specification, theoretically 1000×1000 (one million) variations are possible within the one file with no extra data. A third axis could increase the possibilities to one billion. At the time of writing the technology is in its infancy, but it potentially opens up tremendous opportunities for new kinds of responsive typography. The file size savings and fine precision means that many small adjustments could be made to the rendered font, potentially responding dynamically to the reader’s device and environment, as well to the text. Within the design space created by the axes of variation in a font, the type designer can define specific positions as named instances. Each named instance could appear to users of design software as if it were a separate font, for example ‘regular’, ‘light condensed’ or ‘extra bold extended’. In the OpenType specification, five common axes of variation have been pre-defined as four-character tags: weight `wght`, width `wdth`, italic `ital`, slant `slnt` and optical size `opsz`. These font variations can be enabled by the `font-weight`, `font-stretch`, and `font-style` properties. [CSS4]( adds new values for the properties to work with font variations: `font-weight` takes any integer from 1–999 (not limited to multiples of 100 as in CSS3). `font-stretch` takes a percentage number in a range where 100% is normal, 50% is ultra-condensed and 200% is ultra-expanded. `font-style` takes an oblique angle value from `oblique -90deg` to `oblique 90deg`. `font-optical-sizing` is a new property taking a value of `auto` or `none` which turns on optical sizing if it’s available as an axis in the variable font. Continuous variation along an optical sizing axis in Amstelvar Font designers can also define custom axes with their own four-character tags. This enables designers to vary almost any imaginable aspect of a typeface, such as contrast, x-height, serif-shape, grunginess, and even parts of an individual glyphs, such as the length of the tail on a Q. Using a syntax similar to `font-feature-settings`, custom axes as well as the predefined ones, are available through the low-level `font-variation-settings` property. For example, this would render text with a variation that is very wide, light weight and optically sized for 48pt: h2 { font-variation-settings: “wdth” 600, “wght” 200, “opsz” 48; } Visit Laurence Penney’s []( to play with variations and design instances of some variable fonts (requires [Safari Technology Preview]( As with regular OpenType fonts, variable fonts can be used as web fonts as-is, or preferably wrapped up as a WOFF. If you want to use to a variable font as a web font, in your `@font-face` rule yo[...]

The importance of putting your champions on a pedestal

Mon, 15 Aug 2016 23:02:06 PST

Over the past few years I’ve had the pleasure of working with a [London council]( In a nutshell the job was to completely redesign the web site to make it far easier for residents and professionals to use: no small task. It was a hugely rewarding and successful undertaking, but none of it would have been possible without one person in particular. Our main point of contact at the council was the ‘web manager’. Let’s call her Samantha. At our first meeting it was clear Samantha was someone who was passionate and knowledgeable about the needs and potential of the redesign. She could see the points of view of both the council and the residents. She was also aware of the scale of the task, but not daunted by it – Samantha had that rare quality: a black belt in can-do. It was evident she could be a great ally to the [Clearleft]( team and to the success of the project. She would be our champion. I’ve been working in the digital design industry long enough to know that many an agency’s past is littered with good work clients paid for but which never saw the light of day – a wasteful and dispiriting occurrence. Many times work is offloaded to the client, the agency runs away, crosses its fingers and hopes for the best. As a designer, especially one working for an agency, it is your job to ensure that your work ends up in the hands of users. An important aspect of that is identifying your champion as the person in the client organisation who can pinpoint the barriers to a great solution going live, and who has the drive and wherewithal to overcome those hurdles. But even champions need help. Soon into the engagement ask your champion about their worries and where the blockers might be. These are almost always deemed political and come down to individuals. As a third party you have a privileged position: you’re not bound by the same politics. Go and talk to the people your champion has identified as potentially blocking the road ahead. Make those people part of the solution. Frame your conversation as a formal stakeholder interview if that helps get the meeting, but a good old-fashioned chat might actually do the job better – you can bypass the formalities and convince them you actually care about their opinions. Seemingly obstructive people or departments are very rarely being deliberately awkward or ignorant. It’s likely they just have other priorities. Those people are probably unaware that they are being a problem and consequently will be willing to make amends. If that’s not the case you will at least know to find another tactic. This pro-active, personal approach is what making change from within is all about. It’s the practical upshot of getting design to happen. Thinking about your champion’s perspective is key. Your champion is not just a client, they are a person. They may have got you the gig in the first place, they may have heard of you already and are excited to be working with you, or they may simply be pleased to have some additional help. Live up to their expectations and try to make their life easier. If your champion’s life is easier, your work as a designer will be smoother and less compromised. Set up an honest, equitable relationship with your champion. Talk person-to-person with them, not consultant-to-client, and form a friendly partnership. Put an arm around their shoulder when necessary. Help your champion get the design message across – often its their job to get buy-in from stakeholders, so go out of your way to help them craft a convincing story and manage the difficult conversations. You know you’re on the right track if you’re making sure your champion looks good. Champions grease the wheels of change. They are obstacle clearers, problem insulators and praise singers. Treat them with the reverence they deserve. Thinking back to Samantha at the council, without her the redesi[...]

Choco Leibniz

Fri, 24 Jun 2016 15:37:42 PST

In a rare excursion we delve in some Friday political commentary from Half Man Half Biscuit:

I try to put everything into perspective
Set it against the scale of human suffering
And I thought of the Mugabe government
And the children of the Calcutta railways
This works for a while
But then I encounter Primark FM
Overhead a rainbow appears
In black and white

Shite Day
I guess this must be National Shite Day
This surely must be National Shite Day
Don’t tell me, it’s National Shite Day

from National Shite Day on CSI Ambleside.

Read or add comments


Chrome just got darker

Fri, 15 Apr 2016 12:46:34 PST

A couple of days ago, my installation of Google Chrome updated itself from version 49 to version 50. The timing was fortuitous and relieved me of a growing headache. A few days before the update I had been looking closely at how a draft of [my book]( was rendering in browsers on my Macbook (non-Retina, running OS X 10.11.4 El Capitan). I was confused to see that Chrome was rendering text much lighter than Safari: ![Screenshots of Chrome 49 and Safari](/images/2385/safari-chrome49.png) left: Chrome 49; right: Safari My immediate thought was that for some reason Chrome was using greyscale anti-aliasing while Safari was rendering with subpixel-antialiasing as per its default. To verify this I changed Safari’s rendering to greyscale using: -webkit-font-smoothing: antialiased As expected this lightened Safari’s text rendering and to the naked eye made the text look the same grade as in Chrome. I don’t approve of turning off subpixel-aliasing – I believe [it’s there for a reason]( – so I tried forcing subpixel-antialising in Chrome with -webkit-font-smoothing: subpixel-antialiased; but it had no effect, so I tried to find out why Chrome was using greyscale smoothing. I use Chrome as my everyday browser. I don’t often open Safari on my laptop. Somehow it had escaped my attention that text everywhere on the web was being rendered lighter in Chrome, and not because it was using greyscale smoothing. In fact Chrome was still using subpixel-antialiasing almost everywhere, including on my book page, as a closer inspection eventually revealed: ![Zoomed rendering in Chrome 49](/images/2385/chrome49-zoom.png) ![Zoomed rendering in Safari](/images/2385/safari-zoom.png) Coloured subpixels in Chrome 49 (left) and Safari (right) That was even more confusing, but at least it gave me a different vector of investigation. I duly uncovered this bug report in Chromium: [Font rendering is lighter than Safari / Firefox on OS X El Capitan]( In turns out Firefox had a similar bug reported: [Text is thin on OS X]( These two reports combined seemed to explain everything. Safari uses Apple’s proprietary Core Text for rendering text. Chrome and Firefox (and Opera) all use the [Skia Graphics Library]( The way Skia was being used to render text meant that text ended up lighter in weight than with Safari’s use of Core Text. Less than an hour after I finally pieced that together, Chrome updated itself with a fix that changed the way text rendered and the problem went away. Text is still a slightly lighter grade in Chrome than Safari and Firefox, but not problematically so: ![Screenshots of Chrome 50 and Safari](/images/2385/safari-chrome50.png) left: Chrome 50; right: Safari Thank you Blink and Gecko contributors for caring enough to notice and fix this issue. Read or add comments [...]