Search the Community

Version 1.8 of OpenType was released in 2016, it included Variable fonts. The feature is mature and widely used nowadays. It would be great to have support for variable fonts.

Hi there! New to the forum, long time user of design software. I thought I'd throw my $0.02 into the ring here as this has recently been a pain point for me. Variable font support isn't only about what cut of a typeface you prefer using, it's also massively helpful when authoring typefaces. Whereas users get the option of interpolating between different axes, typeface designers no longer have to create and maintain as many individual letterforms and can also rely on interpolation to generate different cuts of the font, either statically or through a variable font file. Don't need that when designing? That's cool! Stick to the regular weights from 100-900 or use static exports (currently the only option we have in this software), but variable fonts are unquestionably the direction the industry is going in because of the flexibility offered to users and lower effort required from type designers for the same product. Another key advantage of variable fonts hold over static cuts lies in web design and animation, two fields that aren't currently served by Serif's software. These use cases don't matter when exclusively using the Affinity suite of tools, but it's not acceptable to be unable to match styles used elsewhere — especially when required by brand guidelines. On our website, variable fonts allow us to serve a single .WOFF2 file with support for both sans and semi-monospaced text at any weight we choose while using a fraction of the size that would otherwise be required when serving static cuts. We also get to smoothly interpolate between weights for things like hover states. In this specific example, we use Recursive as one of our brand fonts. Currently I am unable to use the Affinity suite to set text with Recursive's monospaced axis set to 0.51 (semi monospaced with added slab serifs) due to lack of variable font support. We use Recursive set to mono=0.51 for the better spacing afforded in instances where a monospaced font is good to convey information (this text is data or for branding reasons, we use it for titles), but doesn't actually benefit from actually being monospaced. It's become such an issue when creating graphics for our brand that I'll probably have to buy Illustrator again, what a bummer! In closing, I feel like I read somewhere that this would require a fairly significant overhaul to the entire type rendering engine. As somebody who works in software I understand that changes like this may seem small to end users but can actually be quite a large undertaking to implement. Something that I've been very impressed with regarding Affinity's suite of tools is the care put into creating a software package that is both cohesive for end users while remaining technically consistent, generally with a focus on doing things correctly — especially regarding colour. All I ask is when prioritizing future features, maybe consider bumping variable font support up the list? I'm excited for the day your already pretty good type rendering engine becomes best-in-class!

For some fonts problems arise in Designer in the font style dropdown. As you can see in the images below Windows shows the several types of the Bahnschrift-font the correct way, but in Designer there's only a list full of 'Regular's for this font. The font is included in the attachments. Bahnschrift Bold Condensed.otf

Un-install the variable fonts. Montserrat-VariableFont_wght.ttf and Montserrat-Italic-VariableFont_wght.ttf The Live Text Layers PDF shows the font embedded is Montserrat-Thin. This is the default master in the variable font. The variable font named instances names are the same as the font names in the static fonts, so it is confused and embedding the variable font, but since variable fonts are not supported, you get the default master - Thin. Un-install the variable fonts and you should be fine. p.s. to everyone - Never install both the static fonts and the variable fonts from Google Fonts at the same time - there will be name conflicts like this (because they purposely make the names the same so the static fonts and the variable fonts are interchangeable). Sometimes the font developer has a different variable version with a different name in the source repository (like commercial fonts).

I'm seeing a difference between the kerning for variable fonts. I've captured these two images to show the differences, Google fonts: Montserrat and Josefin Sans. Both fonts are identical size and kerning settings, but the BOLD versions of these fonts show the X and A closer together (alongside other issues, notice the closeness of the 'T's), it appears to be a problem with vairable fonts files only. I was using the Google fonts repo inside my Fonts on the newer machine, however after looking into it further my older machine uses separate .ttf files versus the Google fonts repo (https://github.com/google/fonts) which uses [wght].ttf files. I've managed to transfer the original .ttf files from my old machine that I need, but wanted to flag to the Affinity team since the Google Fonts github repo and website provide these problematic [wght].ttf and similarly other websites with variables fonts files as default. I tested the issue with another variable font: (https://github.com/github/hubot-sans) > For anyone facing a similar issue, you can download the family of fonts from Google Fonts and they provide a 'static' folder where you can use the individual .ttf files.

@Patrick Connor Ha! Mixed direction text is always fun. We haven't thought about that yet for our applications and I'm sure I'll be dealing with it in the years to come! Lucky for me, ours is web based with all of the affordances and limits that brings. 🙃 @walt.farrell Output format utility would mostly remain the same I think? There's not a lot regarding variable fonts that change the format one might deliver something in. As I understand it, Affinity Designer does not aim to be a 1-1 SVG spec adherient editor so while SVG can include things like animation, I wouldn't expect that to be editable through Affinity's software. As such if I wanted to animate a variable font's axes in an SVG exported from Designer I would expect the ability to edit the file in an external text editor with text exported as <text> objects (not paths) which is something the program is capable of doing today. The axes controls would have to be added to the CSS export that Designer already performs reasonably well. In any case, SVG and PDF are probably the most relevant formats to worry about regarding variable fonts due to the different way type can be embedded in the files. Other than that — as far as I know — exporting is the same as with regular cuts of typefaces. It's less about the specific format and more about having the feature consistency across my pipeline which involves software like Figma, web browsers, Blender (through Coldtype st2), and of course Affinity's software.

I'm a somewhat new user of Affinity Design. I signed up to join this forum just because of this issue involving OpenType Variable Fonts. I've been working in the sign industry for nearly 30 years, mainly designing outdoor electrical signs but also lots of other things too. I've used at least half a dozen or more vector graphics applications over the years, but have done most of my work within CorelDRAW and Adobe Illustrator. I haven't considered Affinity Designer as an acceptable replacement for either one of those applications at this point. But I have been experimenting with Designer because I think the potential is there for the application to become more popular, particularly for anyone doing design work on a limited budget. Lots of small businesses and individuals will try to "home brew" their own logos and other graphics materials. Just in case I start receiving customer provided artwork in Affinity Designer format I want to be able to handle it properly. For my own design purposes OTF Variable Font support is very important. I really like variable fonts that offer weight and width axes. Such typefaces will give me more flexibility to create a design that has to fit in a fixed space, such as a replacement face for an existing tenant sign cabinet. There is a lot of truly horrible quality sign design out in the field. Quite a bit of it features default Arial artificially stretched and squeezed to cram into a spot in the layout. The "designer" can't bother to scroll down the fonts list to find a typeface with styles whose proportions fit in the space. I think sign designers have a certain civic duty to not visually poop on the commercial landscape. A badly designed sign may be visible on a building or next to a street for many years. Badly designed signs and poorly maintained signs help fuel public backlash and inspire severe anti-signs ordinances. Variable type can allow designers to deal with space limitations far more gracefully. A variable font that has a width axis can be "squeezed" yet maintain the proportional balance of its vertical and horizontal strokes. I spend a pretty decent amount of money on commercial type. Most type families I've purchased lately have included variable versions along with a folder filled with many static instances. Some purchases had only variable fonts in the package. For instance when I bought a copy of Proxima Vara I downloaded just one font file. I was pretty happy to see the arrival of the OpenType Variable format. I remember using Type 1 Multiple Master fonts in the 1990's (within Adobe Illustrator). The OTF Variable format brings back the Multiple Master concept, but with the much larger OpenType character set capability. I really don't care whether Variable Fonts are supported by PDF or not. With a lot of the design work I do I tend to convert the type objects to outlines during the design process or when I finish it. But the Variable Fonts have become an important tool for the design process. It's worth noting Adobe recently added more than 140 Variable Font families to its Adobe Fonts service. Out of vector drawing applications I think Adobe Illustrator has supported the OTF Variable Font format the longest; it's also one of very few that support OpenType SVG (aka "color fonts"). CorelDRAW has supported OTF Variable since its 2020 release IIRC. Even Inkscape supports OTF Variable Fonts now. I think it's pretty important for Affinity Designer to add Variable Font support sometime soon.

UPDATE/Solution: Hey, folks. I've managed to resolve my issue. While I'm still looking into this further, the culprit seems to be a single font. I use FontBase to help organize and curate my many fonts by project and it seems that in loading a particular project collection - which had previously worked without issue - triggered the never ending crash cycle. As I had already cleared the cache and uninstalled/reinstalled the software multiple times - and the font hadn't been an issue before - I never thought of disabling FontBase. The font in question is Ellen Luff's Hackney. The font comes in both OTF and TTF flavours, with the latter being vector and the former SVG. It is the SVG OTF version that was causing the repeating crash. I have confirmed that this is the culprit behind my woes and am able to trigger the issue by toggling the OTF font on/off. I thank you all for having read my lengthy post and hope that this adds one more piece to the potential puzzle of future problem-solvers. CRASH DETAILS - In the event another user should find themselves in a circumstance that sounds familiar. ---- RePost from Franny49 Topic ---- Yesterday Affinity Designer 2 unexpectedly crashed while working on a project. I've had the odd crash, but this was seemingly out of the blue. I started the program again and shortly after loading the project it crashed again. So, I followed the instructions provided: - Disabled openCL - crashed. - Cleared all user data - still crashed. - Uninstall, cleared user files and appdata and reinstalled after a restart - still crashed. - Rolled back last Windows update - crasheroo! - Got desperate and updated to Windows 11 - crash-test-dummy... "Crash" Behaviour: The app crash is not dependent on any particular operation/execution and can be repeated/reproduced with every launch. There appears to be some variable to the runtime stability, but it doesn't appear to be related to any particular action. Even if you don't interact with the program at all after launch it will still crash. Sometimes its 10 seconds after launch - other times its been as much as a minute. Either way, it crashes. There are a couple noticeable stutters exhibited prior to the program locking-up and subsequently crashing. I'm hoping the screen record helps to some degree for diagnostic purposes. No crash report has been produced. I'm using a Surface Book 3 with 32gb ram and NVIDIA GeForce GTX 1660 TI - now operating on Windows 11 (sigh). Other Trial & Error Details: - Tried to launch Photo 2 and Publisher 2 (2.0.4) - also same results. - Tried Designer 1 (last updated version) - crashes. - Tried Designer 2 Beta (latest build) - crashes. - Tried launching software with Surface Book screen dethatched from base (uses internal Intel Iris GPU when separated) - Johnny Crash. I'm really at a lose here, folks. I've used Affinity for several years now and truly love it. But this is a problem that I don't know how to resolve and am desperate (clearly - Windows 11 desperate). If anyone has any help or suggestions - please share. I'll try anything. My only other thought is a compete computer reformat. That's far from ideal, but if I knew it would work, I'd do it now. Thank you in advance.

Gimmicky? There are many gimmicky typefaces of every sort, and I suspect some variable fonts will follow the same path. I have noticed that the demos of variable font capabilities often show the gimmick potential of variable fonts. However, there's nothing inherently gimmicky about variable fonts. I increasingly depend on them for dealing with tight space requirements or adjusting display-sized type, such as headlines, to achieve exactly the right balance of weights and widths. As someone with a self-described conservative outlook (on type and design, I suppose), variable fonts will enable you to fine-tune those classic typefaces to their best advantage for the job at hand.

Hmmmm... had no problems. Had the original Open Sans (v1.10) fonts installed so tried that first. Both the IDML file and the APub file exported to PDF - and both looked fine. Even checked the PDF and the single ligature characters are there. Replaced my installed fonts with the Google Fonts version (v3.001). Exported both to PDF again - both look fine. Poked around the IDML content XML files, and saw no odd characters around where the ligatures would be. Sooooo... not sure what is happening on your end. Just to be sure - do not have the variable fonts installed at the same time as the statics. Google Fonts makes them interchangeable so there are name conflicts. But I doubt that is an issue here, but just never do that.

Ugh. Don't do that. 😬 Make yourself a set of "corporate brand" static fonts with the settings you want. This would also be good for sharing with other company employees, etc. who may not be using advanced applications. Slice is a free open-source GUI tool. https://github.com/source-foundry/Slice https://slice-gui.netlify.app/ or Google fonttools (FOSS) runs in Python https://github.com/fonttools/fonttools https://fonttools.readthedocs.io/en/latest/varLib/instancer.html or Samsa - free online tool https://lorp.github.io/samsa/src/samsa-gui.html or Dinamo Font Gauntlet - free online tool https://fontgauntlet.com/ or just open the variable font in a font editor, add the instances you want, and export them as statics. Take about 15-20 minutes in FontLab. Love Recursive. Fully uniwidth. Rare.

Welcome to the Serif Affinity forums. Thanks for your input, and for understanding that it may be more difficult to implement than some of us users seem to recognize I'm curious (as I'm still educating myself in this area) what output formats you're using where it would be useful. For example, you've mentioned web design and animation, but if Affinity could support Variable fonts, what output formats would you be using where you would find the support useful?

@Shrinks99 Welcome to the Serif Affinity Forums and thanks for your expert opinion on this topic. I think the overhaul of the engine would be needed for RTL (mixed direction) text, but I do not think that support for variable fonts is as difficult and I too hope it can be addressed before too long

Google Fonts is working on moving their library to variable font format: a sign of the times. Can we please prioritize variable font support in Affinity?

Ok, So yes there are some potential drawbacks with editing pdfs in Publisher. I think as a whole, Affinity is not ready for prime time. Presently I am having issues importing large pictures into Publisher, it needs to work like every other program that is a page layout program in that sense. Variable Fonts are a big deal too. I have to fiddle around with exporting to PDF too, it's not up to par. Mind you my critiques are not "don't get it" but "please fix it" to affinity. It;s a great product at a fair price and it does some amazing stuff, and some stuff is frustrating. I keep trying it to use it more and more. One thing is now that Adobe no longer has Pantone spot colors (for the most part) Affinity is the way to go. Not having spot colors was a big mark against a lot of ok programs.

There might be some individual variable typefaces that seem gimmicky, but that's a subjective judgement. I, for one, utterly detest the Arial typeface. I think it's harshly ugly looking, especially when set next to a far more "neutral" sans like Akzidenz Grotesk or Helvetica. That's my subjective judgment on it. My hatred for Arial is extended by all of its horrible over-use. It's the default font in many applications. In the sign industry Arial is perhaps the most misused and abused typeface there is. So many hacks out there just love artificially squeezing and stretching it to force-fit it into a tight space. That makes an already ugly typeface even more ugly. The tyranny of that typeface (and poor quality graphic design in general) helps fuel a growing anti-signs movement in many city governments. Variable fonts can help fight some of that problem. I have a few "work horse" variable typefaces in my collection that come in very handy when I'm working with very demanding space limitations. A single variable font file with weight and width axes can yield many thousands of possible combinations. The results look far more graceful and professional than taking a stock, static font and artificially distorting it to squish it into a space.

I was thinking about variable fonts a few weeks ago and came up with the question: "What is going to happen in a year or two when people are trying to figure out what all the settings are for a variable font which was used in a PDF they have been handed. Note that I am sceptical about the utility of Variable fonts, they seem far too gimmicky to me with my increasingly conservative outlook.

It is disappointing v2 doesn't offer OTF Variable Font support. I found out v2 didn't support the feature soon after it was announced. I waited until practically the last day of the introductory price discount period before caving in and buying copies of v2 for my PC and iPad. There is a decent number of other improvements in the upgrade. I'm still holding out some hope OTF Variable Font support will be added on a point-release update. Variable fonts are only gaining in popularity. They're not going to be a flash in the pan the way Type 1 Multiple Master fonts were in the 1990's.

The Affinity applications don't recognize Colour Fonts or Variable Fonts. They also don't have access to fonts which are from the Adobe Creative Cloud. And I would think other cloud services are offering fonts on demand as well, these won't be recognized either. Edit to reflect the information from Dan C.

You experience the "deadlock", I don't. The variable is the fonts. Just try replacing them with a TTF or OTF font like Arial and see if the "deadlock" still occurs. You may be able to find TTF or OTF versions of the fonts. Here are a couple of web pages about the demise of PostScript type 1 fonts, they are from two years ago. Sorry to be the bearer of bad news. https://helpx.adobe.com/fonts/kb/postscript-type-1-fonts-end-of-support.html https://www.extensis.com/blog/adobe-ending-support-postscript-type-1-fonts https://appleinsider.com/articles/21/02/15/adobe-is-retiring-type-1-font-support-heres-how-to-prepare-for-the-change

Well, sort of ... There is no difference in sub-setting vs. not sub-setting (of the character set). Works the same way. When you embed sub-setted static fonts sometimes you may notice the font name multiple times with different prefixes of random characters - each of those is a mini static font. How this is done depends on the PDF library used to create the PDF. Different PDF libraries often embed the same fonts for the same doc very differently. So creating a "static sub-set" is SOP. Anytime you embed a font you have text character data and shapes. That does not change with variable fonts. If I select a pre-defined named instance from a variable font (such as Medium), the shapes embedded will match the static Medium font. The font name embedded from the variable named instance may also match the static font name. Depends on how the variable font is constructed. Google Fonts makes their variable fonts so the named instances are interchangeable with the statics (generally). The downside to that is if both statics and the variable are installed they may have name conflicts. Commercial font developers usually name the variable and statics differently to avoid the name conflicts. When the names are the same the PDF does not know that the pre-defined variable instance embedded (e.g. Medium) was not a static font. The shapes may have been computed from the variable font, but they are the same as the static shapes. So looking at the finished PDF you have no indication of the source being variable or static. You have embedded FontName-Medium, and the same text character data and shapes. When you select custom axis variations, then you have a font naming issue to deal with when embedding. There is not a simple list of 10 weights, or widths to select the font name to embed. Adopey has published their recommended naming guidelines for these custom-settings embedded fonts. And there are some other competing recommendations from some others. But embedding the text character info and shapes is still the same.

I highly doubt that. Please make a specimen page with various weights and widths. There are 90 different pre-defined instances - pick 10 or more. Then Export to PDF, attach the PDF here, and let's see what is actually in there. Just supporting variable fonts will not help here. First: The PDF has embedded all styles as AcuminVariableConcept - no styles specified at all, and the family name does not even match what is in the font (which is AcuminConcept). The way this is done does not follow Adobey's own recommendations. Based on past experience this is probably to sabotage other applications. The real font info is encrypted in the PDF, and/or in the AI file info. The variable font does include the PostScript Name for all of the instances (which Adopey recommends/requires) so if pre-defined instances were used, that is how each style should have been embedded. If completely variable styles are used, Adopey has published their guide on how best to embed the fonts, and they did not follow their own guide. And, the encoding for Unicode is complete garbage. This has to be intentional as the PDFs from ID are usually correct. Second: Acumin Variable Concept is an OpenType-PS variable font, not an OpenType-TT variable font (which 99% of current variable fonts are). Very few applications support this type of variable font because they require a new OpenType table (CFF2) which requires a lot of new programming to support. This is probably why there is garbage on the page in your first image. Third: The PDF library also has to support this new CFF2 table, and variable fonts. It has to know how to embed the characters/glyphs from that table. Fourth: All the Adopey "Concept" fonts are limited sub-sets of the character sets in the static fonts. The variable font has 348 characters vs. the 626 characters in the static fonts. This can result in unexpected character substitutions. The two other fonts in your PDF are there for bullet characters (not sure why as the VF has a bullet character). The "Concept" fonts are your basic "Nightmare." They should only be used if a truly variable style is needed (not a pre-defined instance), and the PDF output is going to the printer. If your colleagues are using pre-defined instances, they should just use the static fonts. And then Export that to PDF, and that PDF would hopefully have correctly embedded font names that would be easier for you to edit. @lacerto It is possible for the variable font named instances and the static font named styles to be interchangeable. The way Google Fonts configures their variable fonts - where both the variable font and the static fonts have the same family name - is done that way so if a web site serves a variable instance and it matches the static style installed on some user's computer, then font does not need to be downloaded (increased speed, lower bandwidth). But users had issues (browsers, etc.), so that local fallback is disabled for now in their recommended code (but web designers can still enable the local fallback themselves). It works the same way with desktop fonts in Word for example. The M365 cloud fonts will supply static versions of the Bahnschrift variable font if the user does not have the variable, and the two are interchangeable. So the documents can then round-trip back and forth between those users. The downside when the family name is the same is that for many applications (ie. Affinity) you cannot have both the statics and the variable installed or the names will conflict. Which is why most commercial font families name the variable font differently.

No, this is not the case, which I and others have repeatedly pointed out. I use variable fonts almost every day in various printed publications. An InDesign or Illustrator file will save variable fonts to PDF with no problems. I can, and have on many occasions, opened PDFs containing variable fonts in Illustrator and the fonts are still there and still editable. They haven't been converted to static fonts. They haven't been outlined, and they still function as variable fonts with adjustable axis. Now if you want to edit the PDF in an application that doesn't support variable fonts, such as Affinity Designer or Publisher, of course the variable fonts won't be editable, but that has nothing to do with the PDF — it's the result of the limitations of the editing software that doesn't support variable fonts. In addition, of course, the computer where any subsequent editing occurs must have the variable font installed, which isn't all that different from needing the locally installed .otf or .ttf font file when the file is edited.

Thanks for your help, @kenmcd! I un-installed both variable fonts ("Montserrat-Italic-VariableFont_wght.ttf" and "Montserrat-VariableFont_wght.ttf"), and now when I export PDFs of documents that use the Montserrat font family, the live text font weight doesn't change. Thanks again!

Every embedded font is a "new font." The original full static font is never embedded. The original full variable font is never embedded. A collection of text character data and shapes is embedded. That collection may be a full character set, or a sub-set of those characters. Characters (with a code point) does not include all the glyphs in a font. No OpenType alternate glyphs are included (except those shapes used for a character). So no full set of small caps, no set of alternate figures, no unused swashes, no unused character variants, no unused contextual alternates, no localization alternates, no discretionary ligatures, no stylistic sets, etc., etc. The application may embed the alternate shapes from some of those features. No OpenType code is embedded - so there is no OpenType connection between the embedded character codes and the alternate shape embedded. A character code is there, and a shape is there. The application may have substituted the shape based on some OpenType code. A particular character code may have many different shapes associated with it. With a static font, the application chooses which shape is embedded based on features selected. With a variable font, the application chooses which shape is embedded based on features selected. And what ends up in the PDF is exactly the same. Does a fully editable, full featured static font get embedded? No. Does a fully editable, full featured variable font get embedded? No. I do not know if OpenType font data will ever end up in the PDF specifications. But OpenType modified alternate shapes work in PDFs right now. I do not know if variable font data will ever end up in the PDF specifications. But variable font modified alternate shapes work in PDFs right now. So I do not know why there is this focus on "embedding a variable font." That would only matter if the PDF spec is someday modified to be a truly editable file format which supports font technologies that it does not support now - such as OpenType and variable fonts. I doubt that will ever happen. It is my understanding that in the very early days of PDF you could embed essentially an actual full font, but that practice was stopped many, many years ago. Adopey does not want their full fonts embedded in a PDF, ever. There is no limitation on the use of variable fonts because of supposed PDF issues. It works now. So Affinity could support variable fonts now.