Search the Community

Variable fonts are not supported by any Affinity apps.

How is that any different from what @Old Bruce demonstrated? Different fonts have different proportions of width to height and it can vary by character. In order for the text to have the same bounding box it will frequently need to be stretched in one direction or the other. This opens up an entire range of possible interpretations of what you are asking for: Should the height be fit, the width, or both? If both, then the text needs to be stretched; if one or the other, then this is not a simple checkbox on/off state but you would need an interface to select which way the fit should occur. Should the fit consider ascenders and descenders so that it is a simple match of the bounding box, or should it simply fit the x-height above a matched baseline and allow the ascenders and descenders to ride around that? Should the match be for the entire string, or should each character be matched individually in order to maintain the spacing of the characters of the text (as there can be differences in how characters compare to each other and this could throw off alignment of the characters to other visual elements of the document)? Differences in available ligatures and stylistic alternatives could also come into play... If Serif ever gets around to supporting variable fonts, should the settings for each font axis be adjusted to try to obtain an optimal match between them? ... ...

From the appearance of the font list within the Affinity application, my guess is that you have installed Variable fonts. Affinity does not support them. You need to install the Static version of the fonts, not the Variable, if Cooper Hewitt supplies one.

You may have had both the static fonts and the variable fonts installed - which is really going to confuse things and perhaps result in the odd font menu order you had. Google Fonts requires that the instances in the variable fonts (Regular, Bold, etc.) be named exactly the same as the static fonts. That way if you are looking at a web page using Open Sans (which is going to be the variable font) and you have the static fonts installed locally, your browser will use the local fonts and there will be no web font download needed (so it is faster and less traffic). The downside is that you cannot have both installed locally because of the name conflicts. Some designers make a separate VF font, such as Open Sans VF, and because the family name is different you can install both without conflicts.

Welcome to the forums @Ben Coe You can uninstall Windows updates via Settings / Updates & Security / View update history / Uninstall updates. The Affinity applications cannot use, or can only partially use, certain fonts because of various reasons – variable fonts, coloured fonts, old fonts, broken fonts, etc. If you cannot see the font in your application font list then you cannot use that font, at least in the form it is on your machine (and you can’t force it to). You can search the web for <fontname> alternative (change <fontname> to the name of your font) to see if you can find up-to-date TTF and OTF versions of those fonts.

Hi @mat.loughnaneand welcome to the forums… The Affinity software suite doesn’t currently support variable width fonts which will be why you are seeing the discrepancy in the kerning between the variable width and true type versions of the typeface…

It took me a long and frustrating journey to understand why after upgrading to Ventura and now to V2 suite of affinity, suddenly most of my projects started to complain about missing fonts that I didn't even intentionally installed. Turns out I was using a lot of Apple fonts or other fonts I added long time ago that are now Variable. Because many of those fonts are not available as TTF I have now to start looking for alternatives, going back to design stage of a project that I thought was print-ready and small changes to old layouts now mean having to spend hours of research for a similar-looking font. And what is more frustrating is to know that, if my documents were made with Adobe, I wouldn't have any problem with the fonts now. This also made my font selection much more restricted as now, from my operation system, the compatible font library is much more limited and I need to spend time and money to get alternatives.

You probably have the Raleway variable font installed. Affinity applications do not support variable fonts. When variable fonts are not supported you get the default master. In Raleway the default master is Light. So when you do the Export to PDF that Light is what you get. Use the static fonts instead.

It does not seem to be as much a question of "old" vs. "new" apps, but the level of support for different standards, some legacy (like non-Unicode Windows or Mac encodings), some new (like variable fonts). All browsers on Windows that I tested (Chrome, Firefox, Edge) can render the SVG test file provided (the one created by AI CS6) without problems, as can apps like LibreOffice Draw, VectorStyler, CorelDRAW (after PANOSE font matching and showing all codepages), Xara Designer, and Krita. But Affinity apps are not alone, so e.g. Inkscape and GIMP cannot, nor can Adobe Photoshop CC 2023. And it seems nothing on macOS can render it correctly (except VectorStyler, after manual fontname mapping; UPDATE: Google Chrome can, without any issues while Safari cannot), so having the support and then capability to change to something more universal (even if just converting to curves, but having correct rendering) and up-to-date is a useful and important feature.

Thanks. That may indicate that you installed the Variable fonts rather than the Static fonts.

Still no variable fonts? This is crazy. The variable font is just sat there staring at me and I'm having to diick-around with strokes to try and create the effect I need.... It makes Designer feel like a really poor cousin to Illustrator.

Technically wrong as in the days of metal type each size was individually tailored and adjusted for the size - also known as optical correction - which static fonts do not do but is an option with variable fonts.

The Mac "font list" is based on font support by the OS, which would ordinarily make those things work for apps that leverage the OS functionality to render the fonts, even if the apps do not support variable or color fonts directly. The fact that Serif opted to go their own way on font management and rendering means that they are failing to take advantage of functionality the OS is trying to hand them on a silver platter but are still using one tiny piece of it that is engineered with the assumption that the rest is being used, creating a mismatch of functionality. This is not a flaw in the design of macOS, but rather a highly questionable design choice by Serif. They are asking the OS to give the user a choice based on what the OS can do, but then taking the choice from the user and applying it to what the application can do, which happens to be less in this case. No, to fix this, Serif would need to either leverage OS-provided functionality, or implement their own functionality to be at least on par with the OS feature set. Writing their own font picker code (not a separate app, that would serve no purpose) would eliminate the mismatch but would leave them in their current position of inferiority.

I had a look on the extract you posted and could not find anything that could explain this. It would be interesting to have a look on e.g. p.14 extracted from the actual production PDF, if you still have that, just to see how exactly it was exported. I had one possible explanation for this, assuming that a variable version of a font might have been used instead of static, but it seems Lato only comes as static versions (as for Lora, it includes also variable versions in the same package). In theory, if using Affinity Publisher on macOS, it would be possible to use the variable versions even if Affinity apps do not have full support for them (the glyphs are rendered correctly but use wrong metrics). That (or having installed both variable and static versions of a font) could cause surprises when exporting to PDF, even if everything appears to be fine when viewing the file, and even if the actual problem is caused by another font than one that shows the problems (as using Lora variable version but having problems with Lato static version). But based on tests with static and variable versions of Lora, it does not appear that this could have happened. I also produced PS and PRN (HP-PCL XL) print files destined to a pretty old PostScript device (Dell 3130cn) from a PDF produced from the Publisher document with standard print settings that embed sub sets of fonts, and there were no problems with the fonts with either print file when distilled to PDF or rendered using a PCL viewer [I am currently out of office and could not send the file directly to the printer]. I used Google OpenType (TrueType flavor) versions of the fonts. Based on these tests there does not seem to be room for other explanations than ones that assume that something went wrong because of the print technology used, so I would try to resolve the problem with the printer. It may well be that not allowing subsetting, or producing the print file e.g. using a specific method (e.g. PDF/X-1a:2003) could resolve this -- or using the PostScript flavor of the font created by @LibreTraining in the post above -- but there is really nothing special about the original document nor in the resources it uses that could explain the error. That a commercial printer would use technology that cannot handle Google fonts, seems really odd, but when other possible causes do not seem to explain the error, it is a well-based hypothesis.

To test it, I saved a page in the latest version of Illustrator to PDF. The page contained several variable fonts in various configurations of weight and width axis settings. It worked fine. Furthermore, I opened the PDF in Illustrator and the variable fonts were still there, still useable and hadn't been converted to outlines.

It's not quite that simple, though. They need something that works on Mac and iPad and Windows. Even if they had a layout engine that handles Variable fonts, the PDF format does not support Variable fonts. Essentially, any app creating a PDF needs to create a static version of the subset of characters used in the PDF, and embed that newly created static font subset into the PDF.

Congratulations, the static fonts are downloaded with the variable fonts but are in the static sub-directory.

Some other users have reported similar results. I think it is because of the Mac being able to display the SBIX font, but the APub and/or the PDF library not supporting it. The Mac font picker will display SBIX fonts, SVG fonts, variable fonts, etc. but they are not supported in APub (which confuses users). But can you print it or Export-to-PDF? If you can, that is more confusing. Why is the .notdef box appearing sometimes? There have been multiple posts regarding the LiebeHeide SBIX font not working in APub. So I have assumed SBIX is simply not working. If you are interested, I can send you the font to test (view, print, export to PDF, PNG, etc). I would certainly like to know (and others too) and have no way to test SBIX fonts. Also have Scrapbook Custom which is also SBIX/OTF. There is also an SBIX version of the free Bungee fonts (which I will attach below). Like to get Mac user test results on that font too if anyone wants to test. Yes, but I am not sure exactly what that means - "most emoji" It would be nice to know exactly which emoji fonts work on which platform. On Windows the default emoji font is Segoe UI Emoji, which is a COLR color font. And we can see from tests that other COLR color fonts also work (but not 100%). On the Mac the default emoji font is Apple Color Emoji, which is an SBIX color font. So what I would like to know is ... are other SBIX fonts also working? From the other posts about the LiebeHeide SBIX font it appears it is not working. LiebeHeide is also an OTF/SBIX not a TTF/SBIX (like Apple Color Emoji), and it also has an SVG back-up in it - so are those structural differences an issue? Or has something changed with some update and it works now? Bungee Color fonts for testing The free Bungee Color fonts include COLR, SBIX, and SVG versions in TTF format. You can get the originals from GitHub: https://github.com/djrrb/Bungee/releases/tag/1.1.0 I have renamed them so you can install all three at the same time (name conflicts in originals). BungeeColor.renamed.zip

People are being too nice. That guy is full of 💩. You still have not really explained why you want to do this. And what exactly you mean by "practical use in typesetting." Text type is generally proportional for multiple reasons (as mentioned above). The nonsense in that article about old monospace texts and justification, etc., etc. is just that - a bunch of double-speak nonsense. There is no way to automatically convert a proportional font to monospace - and end up with a high-quality result. Simply stretching and squeezing results in distortions which must be fixed by the designer (e.g. diagonals often have the wrong width, characters with slanted contrast axes can get very distorted, serifs can get distorted, and on-and-on). This is why there has been substantial debate and differing opinions regarding stretching/squeezing characters for justification. And some character shapes must change dramatically (e.g. i, l, t, 1, etc.). So any automatic method conversion is not going to be the same quality as a font designed as monospace, with character shapes optimized for that purpose. The free Recursive variable font has a mono axis which can demonstrate the transition from proportional to monospace. Demo: https://www.recursive.design/#toolbar We may be able to help if you will explain your goal. Are you trying to mix mono Latin text with a mono CJK font? There are many free CJK fonts which already have mono Latin characters included. Hopefully this is not just trying to follow the nonsense in that article. So what is the final goal?

For a short time I was tempted to purchase the upgrade from 1.x to 2.1. but having seen all those complaints about very very basic features being broken or still missing completely: nope, sorry. I am not asking for AI-stuff but basics like variable fonts support or an option to set the color of every guide - perhaps even an algorithm that automatically finds a color that differs from all/most colors the guide crosses on the screen..? Actually I am not asking for any new features but having the UI completely redesigned to meet state of the art usability requirements. But as it seems, the Brits will prefer to add some more "nobody asked for"-filters. sad story.

The short version - the font info required is simply not there in the PDF, so supporting variable fonts is not going to help. The font info required is in the AI file, which cannot be accessed, and/or it is encrypted in the PDF, which cannot be accessed. So supporting variable fonts is not going to help (in this case).

It's kinda sad how the discussion went from "we want something that's getting popular" in 2020 to "why do you actually need it?" and "do you want it that bad? take a look at an app hat turns your variable font into a static font". Affinity sofware ain't getting any updates related to variable fonts, the users themselves seems to prefer questioning other users about the need for those fonts instead of making this discussion a whole request for Serif to move forward on implementing variable fonts. Sad. Really sad.

Variable fonts don't work yet (PS & TT flavored). In MS Word I can choose from endless named instances, in Publisher all styles are named Regular and look the same.

Found it> https://forum.affinity.serif.com/index.php?/search/&q=variable fonts&quick=1

Hi and welcome to the forum. I believe these are variable fonts and Affinity doesn't support variable fonts at this time. You'd need to track down the conventional version of this font family.