jamessouttar

But I feel like I’m making a case here, when there is no case to be made. Variable fonts are a reality. All the big type foundries and most of the smaller ones are making them. Every major web browser can use them. Apple are using them for their operating system. Adobe support them on their desktop publishing apps. And supporting variable fonts doesn‘t affect support for existing PostScript and TrueType fonts. If Affinity doesn‘t get with the programme, it will get left behind. I’d like Affinity to stay ahead of the curve; I’m sure we all would. But to do that it can’t afford to be sniffy about emerging standards. (Support for web image formats is another area where it has fallen behind — we now have to use other apps to create WebP and AVIF, something that could easily have been incorporated into Photo.)

The difference is between those who are designing just for print and those who are designing across web and print. Variable fonts are becoming essential for good typography on the web, because each additional weight/style of a font family adds to the page overhead and this can cause the site to slip in its Google rankings. Since variable font files can be accessed through named instances which are the same as thin, light, regular, medium, semibold, bold, black etc. (and since type designers increasingly create a family of fonts by designing a thin and a black and interpolating between them, which is what a variable font does), a variable font file can deliver what the font family does, but from a single file. What the font family can‘t deliver are the infinite range of intermediates between styles that the variable font is capable of. And when we have more than one axis (e.g. optical as well as weight variations) the possibility of replicating the same look as the web gets further removed — weight 740, optical 67 can end up being a long way away from 700 Bold Display (assuming there even are optical styles in the family).

Figma now has support for RTL fonts (for Arabic, Persian, Urdu, Hebrew etc.) and has supported variable fonts — through a plug-in — for some time already. Over the last few years I’ve been a big Affinity fan, and supporter, but Affinity is slipping behind when it comes to typography (there are still some rough edges with font support, especially for those with lots of alternatives and contextual features). Type is central to what most of us use Affinity applications for (especially Publisher) and I’d like to see their type handling be ahead of the curve, rather than perpetually languishing behind it.

Yes, but that‘s the point. PDF has been made more accessible, but this requires adding accessibility features through Acrobat Pro, and exporting an Accessible PDF. That‘s certainly something to celebrate. Nonetheless it contrasts poorly with the Semantic Markup approach which is implicit in markup languages such as SGML, HTML and XML (and even Markdown). PostScript is a page description language, and its primary concern is where things are on a page, and how they look, rather than what they are. That‘s why when one imports a PDF into, for instance, Designer, text can be broken up into separate segments (and why Designer has to try to reassemble paragraphs) — it‘s not together, as a semantic entity, in the original file.

Currently, if you export a PDF with variable fonts from InDesign, the software creates static instances of the variable font according to they choices you made. PDF doesn‘t currently offer native support for variable fonts — meaning that the whole font is embedded and remains editable. Adobe don‘t forsee that happening for some time. But as long as the conversion from variable font to font instances works, this is not really an issue. In any case, because of its lack of accessibility, PDF is increasingly being seen as a legacy format. It’s fine as an interchange format for printed documents, but it‘s far from ideal for digital publishing. Given the nature of the PostScript language, which is the very opposite of semantic coding, it‘s hard to see how Adobe could address this (but they still have Framemaker, and perhaps XML and DITA will ultimately become a replacement for PDF).

You might remember that the first incarnation of variable fonts, Adobe‘s Multiple Master format, was developed for PDFs. Two families, based on Myriad and Minion, were used to substitute fonts that were not embedded. Since MM fonts were variable, Acrobat produced instances of the fonts on the fly to match the width and weight of the font. Twenty-eight years later, this is still how Acrobat handles substitutions.

Indeed. But many font vendors offer print and webfonts as an either/or/both option, along with licences for other applications, such as apps (MyFonts being the biggest of these). Variable fonts can be in .ttf, .woff and .woff2 formats (as well as .cff2, but this is currently not well supported). Typically one would install the .ttf on devices where one is using the font (e.g. for print) and the .woff or .woff2 format on web servers. This is the same whether one is using static or variable fonts. Variable fonts are just easier to keep track of, since there are one or two files (usually depending on whether roman and italics are included in a single font, or split). Again, though, I will emphasise that I’m not advocating for variable fonts as a good idea. Variable fonts are happening. They are being driven by the web, but they are beneficial to designers working in physical media as well.

Bear in mind that the variable font standard was built on Adobe’s Multiple Master and Apple’s TrueType GX formats, both developed in the mid-nineties for print applications. The point of using variable fonts in print (as with MM and TTGX) is the precision and control they provide across the range of axes (weight, optical size, width etc.) and so they can be co-ordinated with fonts used on the web. I‘ve set out some of the arguments for the former, but it‘s also worth considering the latter. Increasingly print and digital projects are intended to go hand-in-hand — printed documents link to websites, websites provide PDFs, etc. It doesn‘t make any sense having different fonts, and font formats, across different media. Variable fonts also conveniently bundle all of the variations within the font into one file.

Yes, but support for the latest Apple processors doen‘t feature on my "most wanted new features" list — I’m nowhere close to upgrading my hardware yet. But I understand why Affinity needs to support them: hardware is moving on. My point is, so are fonts.

No, basically font designers have put — and are increasingly putting — this control into users’ hands. And that‘s the point: the font industry is moving over to variable. From a type designer‘s point of view, it‘s much more interesting and satisfying to create a variable font; typographically it‘s a much more sophisticated and powerful tool. I concentrated in my comment on the practical stuff variable fonts can do, but there are so many cool new things variable fonts can do — and not just with letterforms. For instance, because variable fonts interpolate between glyphs, animation in digital environments becomes incredibly smooth (Laurence Penney’s animated Muybridge horse, on his Axis-Praxis site, is an early case in point). It makes sense for symbol libraries (fontawesome, ionicons, etc.) to be in variable format too, to support the growing range of different looks for the same icon. And here‘s the situation with variable fonts. All the main browsers came out with support for them in 2018. Apple’s and Microsoft‘s systems support them (Apple‘s SF Pro system font *is a variable font*). Most of the other main graphics packages support them (Adobe Creative Suite, Sketch, Corel Draw etc.). They are not just the future, but the present too. But Affinity doesn’t see them as a priority. WAKE UP AFFINITY!!! You‘ve put yourselves into the same category as Internet Explorer! I’m a print designer by background, and fine typography on paper is my first love. But these days, like so many others, I work across physical and digital media. I want the user‘s experience to be consistent across media — I don‘t want to be using one sophisticated font format on the web and a more primitive one in Publlisher/Designer/Photo (which is, ironically, an exact inversion of the first ten years of the web!) Most especially, I don‘t want to be stuck in 2017 forever because I went with the stubborn, knows-better graphics software provider.

The fuss? Well, it‘s to do with variability as a design tool. Suppose I have a two axis seriffed variable font — it‘s got a weight axis from super-light to extra-bold, and it‘s got an optical size axis which varies from a hyper-legible ‘caption‘ master with big counters, chunky serifs and minimal contrast to use at tiny sizes to a ‘display‘ master with maximal contrast, hairline thin strokes and serifs, etc. And I’m setting some body text with a headline. At the size that I’m using, 300 feels too light while 400 is too heavy. Using the slider, the ‘sweet spot‘ is about 360. I also want to dial down the contrast — but just a bit. There is some slightly bigger standfirst at the start of the text. It looks better lighter (320) and with more contrast. The subheads I want heavier (760 looks right) so I push the optical scale (but not as far as the display end). The headline, on the other hand, I want with fine hairlines (the optical scale is also tightening the letterspacing — not globally, like tracking, but as the type designer has adjusted it with the left and right sidebearings and kerning for each character). And there is a point where the headline just begins to sing... Does that make sense? Variable is giving fine control to the things that are important to a print designer. Once you‘ve had it, even the Adobe Originals kind of type family with a range of weights and two or three optical variants doesn‘t cut it.

I am now switching over to variable fonts on the web, and I realise how valuable it is to use the weight axis (and optical axis, where the font has it) to find the ‘sweet spot‘ for text and headlines in each situation. It‘s frustrating not being able to do the same in print (if I’m using 440 on the web, 400 or 500 are not matches in print). I’m thinking that it may be a matter of moving back to Adobe for a while until Affinity catches up with this. I don‘t want to do this, but it’s becoming a must-have feature.

Just adding another voice for support for variable fonts. This is #1 on my list of priorities now.

Brilliant! I’m so impressed with Publisher already, but pinning is the feature I‘ve been really hoping to see. And it‘s fantastic to be able to watch the development of what will be a great application! (And you fixed the zooming problem, which will make a huge difference!)

Apologies if this is already reported somewhere else (I had a quick skim and couldn‘t see anything). Applies to Publisher build 1.7.249 (latest at moment of writing) on MacOS 10.14.3. When I zoom out of my current document, it always takes me to the bottom of the last page. In a long document that is annoying (I expect it to zoom in and out based on centre of document in the window). This next one seems to apply to all the apps (I think). When I zoom in or out using the keyboard (command space, Adobe-style) I can‘t then select anything until I’ve pressed the spacebar again. It‘s not a bug per se, but again it is annoying and counter-intuitive. Otherwise super impressed with this Publisher build.