Search the Community

Affinity doesn't support variable, just static. Variable fonts come as a single file, or a handful of files. With a static font, you'll have one for regular, one for italic, one for bold, one for bold italic, etc.

My point in asking the question above was that the Affinity applications do not, today, support HTML or ebook (which is a form of HTML) output. And the uses you've mentioned (which I've highlighted above) seem to be in HTML/ebook contexts. Until that is supported by the Affinity applications, whenever that may be, the only use for variable fonts for Affinity users is in exporting to raster formats, or to vector formats (EPS, SVG, PDF) that also do not support variable fonts. And therefore even in the vector formats the user would have to choose to convert the fonts to curves (losing editable/translatable text) or the Affinity applications would need to turn into font generators and produce subsets of the variable fonts in a fixed-font format for embedding in the PDF files. That sounds very complex for an implementation, and I doubt it would happen.

I can confirm that using variable fonts doesn't work, I had problems with my kerning in designer and publisher too. Using the not variable version of the font and everything is normal now! I'm on Mac Ventura and Affinity Publisher 2.0.3 right now

@elipso97 If you use the fonts from an Adobe subscription it is possible, that it is the variable version of the font. If you download it from Google Fonts, you have the choice between variable and static version of the font.

Hello, It seems that Affinity recognises the Instances in a variable font. That is good. Also the contours of these instances are looking okay! The problems is with the advance width of the glyphs. These stay the same though-out all the instances. That is wrong. The advance width can also be variable and need to be addressed. Hope it helps! Thom

If Athelas is not showing up in Font Book then it is not installed and you'll need to reinstall it. But it sounds like you've tried to install it only for macOS to tell you that it's a duplicate so it should show up in Font Book. Is it possible that you've installed a variable font and not a static font? Affinity is not compatible with variable fonts. To fix this, you'd have to find the font in Font Book and uninstall it and then install the static version, but you can't find it so I'm unsure what do advise. This isn't an Affinity issue since the font isn't showing up in Font Book for you but more of a Mac issue. I think Apple just gave up and sent you to Serif for help. Sorry.

You installed the variable font - Affinity apps do not support variable fonts. Per the OpenType specs, when an application does not support variable fonts the default master is shown. The Rubik variable font has two masters - Light and Black - and the Light is set as the default (by the font designer). So that is what you see - Light. The fix is to un-install the variable font(s) and install the static fonts (from the same ZIP you downloaded). Note: most of the time variable fonts include a Regular master so that is the more common master chosen as default. So instead of them all saying "Light" they will all say "Regular."

Welcome to the Serif Affinity forums. You have a Variable version of the font installed on your system. Unfortunately, the Affinity applications do not support Variable fonts. You'll need to install a Static version of the font.

Photoshop, Illustrator, InDesign, CoreDRAW, Sketch. They all have support of variable fonts. While XD and Figma (and Affinity) still lacking support for it. More and more type foundries are releasing their typefaces in variable format now in addition to usual family sets these days. From the web development point of view, utilizing the only one font file in css and tweaking its axes could be more convenient than handling a bunch of different weights. Also, less resources to request from server. However, variable font files a bit more heavy than usual single weight as they contain more data. So, there are things to consider. From pure organizational point of view, it might be more comfortable for someone to have just one font file installed locally, which actually covers the whole family. For type foundries, sometimes it could also be more convenient to just have one main master curve set in a working file, rather than tweaking and applying changes to individual weights across multiple working files. Unification, standardization, linearization and simplification of the process. But the truth is, that almost every type foundry will raise the prices significantly when they all will decide to provide variable fonts only. So customers will no longer have control over how many individual weights they want to purchase. Either you pay full price or you wouldn't get it at all. Most of the times you don't need the whole family of 20+ styles but 2 or 4 styles only. So, of course, it would be great to see variable fonts support in Affinity suite. But I'm totally fine without it for now, as long as I can still purchase individual weights from type foundries.

My statement is correct that they do not support SBIX fonts. And I do not expect them to anytime in the future. There are better alternatives that support open standards. SBIX fonts contain color images in the sbix table, and they can have multiple sizes. Apple Color Emoji has five sizes - all very small. So they do not scale. There are just much better alternatives. The upcoming COLRv1 supports gradients, and opacity, and a bunch of other stuff. And it scales, and it can be variable. Affinity may need to support COLRv1 fairly soon as I think the next generation emoji font from Microsoft is going to be COLRv1. They and the Google fonts folks have been been working non-stop on the tools and the standards. Already added to OpenType 1.9.0, and more changes coming in v1.9.1. They have been added very quickly. It appears that Affinity supports the Apple Color Emoji font by just getting the images out of the SBIX table - that's all. There is no "font" support. There is no text. It appears it is being accessed as an image container. The ZWJ sequences you mention are basically ligatures. Character1 + ZWJ + Character2 = Character3. In normal standard OpenType fonts this character substitution is done using the GSUB table (Glyph Substitution). Apple Color Emoji does not have a GSUB table. It uses Apple's MORX table which has a similar function, but it is not the same. Affinity does not support MORX tables as they are not standard OpenType. Why waste precious time and resources to program a non-standard parallel system to support a few Apple proprietary fonts? Makes no sense. So in my opinion there is not going to be support for Apple Color Emoji as a font ever.

Having a really odd issue with variable fonts. I downloaded 'Inter' font in the variable version, typed out the word 'Digital' for a logo I'm making in Affinity Designer, and it didn't look right. The A and the L being too close together is what initially caught my eye. I went back to Google Fonts and it wasn't displaying how it does when I typed sample text on there. So I downloaded the static font too, and that shows exactly as expected. Initially I tried reinstalling the fonts etc but nothing worked. So then it occurred to me it might be an issue specifically with Affinity, and it turns out it is! If I do this comparison in other software (e.g. Apple Pages) both the variable and the static font look identical. I've attached a screenshot from Affinity Designer to show the problem. Can anyone help?

Just for the record, I am very interested in variable fonts, and as they are really starting to gain momentum, I look forward to being able to finally use them for layout work. I have been meaning to post a couple of thoughts of how they can improve the work we do, so now seems like my chance: 1. Back in the days well before my time, when fonts were sold as chunks of metal type, they would necessarily be fixed sizes, and you would purchase particular sizes according to need. No question about the disadvantages of the way it was in those days, but there was an advantage to that method if it came from a quality foundry: the different sizes in a single family would have subtle variations on weight and other features (ink traps, for example) so that the optical characteristics of the font would be tuned to its own specific size. Although our fonts today are vastly more convenient, we have lost a little something in quality with a one-size-fits-all approach to scalable fonts (consider the difference between true versus “faked” small caps for a rough comparison of the idea I am talking about). Here is a quote from an old but good article over on CreativePro.com (link). The main article is about adjusting tracking for different point sizes, but this part also describes the issue I am talking about. Variable fonts gives us a way to apply fine-tuned adjustments for weight to suite different sizes. 2. Different print mediums have different characteristics. About five years ago at my little publishing operation, we got a new production machine, and one of its features was how accurate the fine details were as compared to older models. I printed a test page to compare against the same layout as printed on the previous machine. My boss looked briefly at the two specimens, then said simply, “I don’t like it.” The new machine was technically more accurate, but the type looked a good deal thinner, especially fine typefaces like Baskerville. (Perhaps the older fonts in use were also designed with machines of the era in mind.) In order to adjust, we either had to change fonts or use the workaround of applying a very fine character outline (something like .04 pt) to be able to continue using the same fonts as before. On our machine, that workaround does the job for printed results, but I have to be careful with the settings lest the outline can have a disconnected ghosting appearance, and the PDF version where every character has an outline is much bigger, performs poorly, and basically looks bad onscreen. Here too, variable fonts could be a good solution. If it prints a little too faint on our machine, we would just adjust the weight by fine amounts in the text styles and print again. Summary: I can be patient with Serif, as there is room to grow the suite in multiple directions, and they can’t do it all at once. Maybe they should focus on other things first while variable fonts spend a little more time maturing. But if ignored indefinitely, it would really start to seem a great loss.

For a guess: the fonts you have installed are Variable fonts. As the Affinity applications only support Static fonts, you just see the basic version of the font when the Variable fonts are used.

Mike, thanks so much for your answer! Interesting, didn't know it was because of the variable nature. I still wonder: Keynote properly calculates the different character spacing correctly, but I would definitely say I does NOT support variable fonts. What gives in that case?

Hi Jesi and welcome to the forum. Mona Sans is a variable font and isn't available as a fixed font. Unfortunately, Affinity doesn't support variable fonts at this time so you won't be able to use this font with it. Cheers

+1 I was also hoping/expecting variable font support in v2. As a typeface designer, my main use of this software is to make specimens and test my variable fonts. It's frustrating how low of a priority this still is for Serif (ironic that with the name 'Serif' they don't care more about the fonts 😂).

Glad I found this thread before I pulled the trigger - it's bad enough having to pay for .webp support but not having variable fonts is a deal breaker for me. I don't want to be waiting multiple years and paying again for v3 to get that. (Yes, I get there's a ton of new features and that v1 was supported and enhanced for years as well but when you don't use any of those features at all and just wanted .webp and variable fonts it's incredibly frustrating)

Unfortunately I do not completely understand your post. Lexend Deca includes both static fonts and a variable font. Make sure you do not also have the variable font installed as the instance names in it will conflict with the font names in the static fonts - which can lead to unpredictable behavior. What version of Lexend Deca do you have? And where did you get it? If that is not the issue, please clarify your question(s).

Ahhh ... that's the problem. You have the variable font installed (JosefinSans-VariableFonts-wght.ttf). Affinity apps do not yet support variable fonts. The Mac font manager fools you by displaying the variable instances as if they will work, but there is no variable font support yet. So what you actually get is the default master in the variable font - which is Thin. Un-install the variable font(s), and install the static fonts. Then it should work.

If you mean any of the GF variable fonts, yes, they will not work in Affinity apps. The GF static fonts work just fine. Note, the GF variable fonts are designed to have the same instance names as the static fonts. This is so if the user has either installed locally they will be used (saving the font download). Because of this it is not a good idea the have both the statics and variables installed. This will definitely cause conflicts in Affinity apps, and perhaps other applications too. This name conflict is why font designers generally use a different name on the variable version. GF does this on purpose as their goal is speed and to save the bandwidth.

@garrettm30 All of what you have described is really related to optical size. Bad faked small caps look bad because of the lack of optical size adjustments, and the lack of good kerning. Bad faked superscripts/subscripts look bad because of the lack of optical size adjustments, proper placement, and bad kerning. Same with faked or poorly created numerator/denominator figures. Some newer fonts have been built "more sturdy" to address the subtle reduction in visual weight in newer systems (e.g. STIX Two). But this sturdiness is really an overall optical adjustment, not an just increase in width or height or spacing. Which is what your current work-around of the thin outline attempts to address, but with some obvious drawbacks. So my point is that the most common variable axes of Weight [wght] and Width [wdth] will not actually solve this. Just make it a bit easier for you to do the work-around. But the end result will still not be a well designed optical size - which would look perfect. Out of the relatively small number of variable fonts out there, there even fewer which have the Optical Size [opsz] axis. In FOSS fonts - Source Serif 4, Franuces, Merriweather, and RobotoFlex are a few which come to mind. RobotoFlex even has the multiple axes which are the individual components of optical size. Variable fonts like these will actually address the issues you raised. So the solution being available and widespread is still a ways off ... but it is coming. In the mean time, if you find a variable font you like, you can export your own custom instance using some free tools. Less problems with embedding a static font. One of the issues not being discussed much is the somewhat spotty support for embedding variable fonts for output. Finally, if you have a variable font you want to use now, I can easily export a custom static instance for you. Only takes a few minutes and is really quite easy.

Thank you for confirming. I knew v1 didn't support them, but I'm surprised that v2 doesn't given the ready availability of variable fonts these days. Variable fonts have apparently been about since 2016 (Bahnschritt was released in 2017), so they're not that new of a thing to support. I'll keep my fingers crossed for v3.

You have probably installed a Variable version of the font, which Affinity did not support. You need to install the Static versions of the fonts, instead.

Hmmmm ... I see nothing ... wonder if that is a font replacement issue at my end. I have Josefin Sans installed, but my Avenir Next is a different version (LT Pro). Another idea - do you have the variable font also installed? Because when an application does not support variable TTF fonts, the default master is what appears for every weight. And the default master in that variable font is Thin. So that would appear for every weight. Like you have in your PDF. I assume you got the fonts from Google Fonts. Google Fonts insists that the variable font family name and the named instances are the same as the static font names (so the statics will work as a fallback). This causes name conflicts when both the variable and statics are installed. So you cannot have both installed at the same time. Is that the case?

Unless the font fits exactly within the pixel grid, there is always going to be some Cleartype visual adjustments. Which means sub-pixel rendering and anti-aliasing, which means "colored haze." Let's look at the Apple onscreen text situation by comparison. Apple knows the resolution of its screens, and they are typically of higher resolution than the typical Windows users' screen. This gives them an advantage right off the bat. They can, and do, make their fonts fit exactly within the pixel grid of this known small set of screen resolutions. OTF-PS fonts typically have a Units per EM of 1,000. OTF-TT fonts typically have Units per Em of 2,048. Apple SF fonts and New York fonts both have Units per Em of 2,048. Why? It is easier for them to fit the grid without fractional measurements, and it calculates faster (power of 2). Then they designed the fonts so the vertical and horizontal stems fit exactly in the grid (at the sizes they use). They know the resolution, they know the grids, they know the zoom levels, etc. So in the interface everything just fits. (usually) And if it does not fit for some reason, in some app, they just hammer it into the grid. Now let's look at Windows. Somewhere around a gazillion screen sizes, shapes, resolutions, zoom levels, etc., etc. Looking good is easy at HiDPI. But there are far more Windows users in offices, and schools, and government - without unlimited budgets. So rather than just requiring all users to acquire HiDPI screens, an attempt was made to look better at lower resolutions. By its nature this is a series of compromises. Often users have some unrealistic expectations based on their actual hardware. As much as I loved my old Toshiba laptop, at 1440x900 it just could not ever look crystal clear. On my Dell XPS laptop at 3,840x2400 everything looks crisp by comparison. (its easy) So between those two there are varying levels of what you can do. Even at 1920x1080 an interface look pretty good, with the right settings. Fonts can be designed for different screen resolutions, and zoom levels, etc. Above you mentioned that Segoe UI may look better on your screen if a Medium were available. There is a Segoe UI SemiBold, that may look better. It is all about getting the font to better fit the pixel grid. Programming fonts are very aware of this and are designed to fit the grid. Fira Code uses a Units per EM of 1,950 to make it easier to fit the grid at their targeted 13px font size. Each weight is designed to fit the grid, and they even have a HiDPI weight (called Retina, ugh) which fits better on HiDPI screens. They stopped providing OTF-PS fonts because they got tired of explaining why those un-hinted fonts looked so bad. Now only OTF-TT fully hinted are available. Cascadia Code, JetBrains Mono - also designed, and extensively hinted for screens (lower resolution). Inter is a font designed for interfaces. The Units per EM is set to 2,850. Which they did so they could more easily design the glyphs to fit the pixel grid at the different weights. It has an extensive set of static weights, and a variable font. Recursive is another font option with many statics, and a variable. Why all this background info? Because there is a font design, and font size, and zoom level - which is going to better fit your particular pixel grid. If you find that sweet spot, it will look crisp and clean. One Cascadia Code user who was using the font in Visual Studio 2017 commented the other day that setting his interface zoom to 110% and his font to 11 px was his sweet spot - it all became clear. It is possible to calculate the best settings. Based on OS zoom level, application zoom level, font size, font weight, font width, screen DPI, etc. But that can be a bit complicated. You can try looking at some of the variable demos in your browser to get an idea of what is possible. Inter has a "Lab" page where you can play extensively - including with a dark background. Like this: https://rsms.me/inter/lab/?antialias=default&invert-colors=1&varfont=1 Find the magic size and weight for your display - and we can export the custom font for you. Recursive also has a demo/test page: https://www.recursive.design/ It has more variable design options, but the basic Sans would be appropriate for UI.