Search the Community

FWIW I had some weirdness in Affinity where I had one document I had opened that used a static version of a font, while I then created a new document that used the variable version (but only having the static or variable version of a font active at one time). I ended up Affinity picking up the 'correct' font, but there were visual glitches in terms of tracking, kerning, metrics, etc. Even copying between Affinity documents was creating some confusion. I'm not entirely sure if this problem is down to only some variable fonts, or if it's potentially a larger problem in the way that Affinity handles these fonts in general. I'll do some more testing later, and try to come up with a solid reproducible test case.

Feature request... A keyboard shortcut (Alt or Cmd) to disable the defined stepping when dragging the sliders, i.e., to enable the completely smooth transition of the variable between values as per Google Fonts sliders...

I've noticed some issues with some variable fonts, such as Ohno Softie (Adobe Fonts) where the kerning and tracking is way off from the actual settings. Apple Pages renders the font as you would expect, while Affinity squishes everything (and often inconsistently) together. Example from Apple Pages (above) and the same text in Affinity Designer (below).

I really like how responsive Affinity is with axis changes, it redraws the font in real time as I drag the axis sliders without any lag whereas Adobe only redraws after I've let go of the slider and after a full second pause which seems like forever on fast hardware. The axes work great. I was surprised that when I created custom instances that the Font Style control was blank. I was confused at first because blank is already used for mixed state. Perhaps you didn't want to repeat what Adobe did, listing all the axis changes in the name (e.g., "Italic Monospace-0.429 Casual-0.130 Semibold") but perhaps something else could be shown such as <Custom>? I'm on a M1 Pro, too, and choosing fonts and changing variable font axes are both instantaneous for me. I don't have a huge number of fonts installed. I have the standard set plus about two dozen others. Do you have lots of fonts installed?

There's a noticeable lag with variable fonts (it's there with regular fonts too, it's just not as noticeable) where the text is fuzzy (like a highly compressed JPG) for a moment before it sharpens while being edited/resized/etc. I realize this was probably designed this way for performance reasons, but it's rendered fuzzy for just long enough to be distracting. macOS 14.4, MBP M1-Pro, 32GB.

Hi @wtbusiness, Welcome to the Affinity Forums! None of the 3 Affinity apps offers the creation of HTML & CSS for web sites which appears to be required for a flexible layout, displayed with variable font size and column width for instance. Web sites use "responsive design" to take into account the user's device + screen size + screen orientation when displaying content. If you want to publish the newsletter as PDF or PNG for instance AND get the layout & font size auto-adjusted on the various devices you might use/need a workaround by creating several layout versions, e.g. one for mobile (portrait format, larger fonts), one for desktop (landscape, smaller fonts) and ideally even a third version for tablets, each layout with suitable font sizes … and make the web site code decide to deliver the appropriate version to a specific device and user. Although you may create several versions of a basic layout with the support of APub's "Constraints" panel for multiple sizes and page orientation you would still need to export each version individually with its fixed size, aspect ratio and orientation. If you only create + publish one layout version, you will have to choose a compromise with a layout + sizes somewhere between the possible screen resolutions / sizes that either results in an optimal display for one device but is less useful for other devices, or in a layout and font size that may appear too large/too small on any device.

Hi All, We have just made a new build available of a 2.5.0 beta live - version 2.5.0.2415 - This was created to address improve the new features announced in this post The fix list for this build is here There is one very significant change in that Variable Fonts are supported in this beta for the first time Ash

Hi @Affinityconfusesme, @Alfred, @Bobby Henderson, @Bryan Rieger, @kenmcd, @MikeTO, @ronnyb As you can see I have split these posts about the forthcoming Variable Fonts support made in this thread off into the Beta Members area. The original post by Ash will be repurposed to discuss the implementation of Variable Font support, and the talk here about other implementations (and OT discussion on Colour Fonts) would have got in the way of discussing the actual implementation and any bugs found. The new build 2.5.0.2415 including this feature will be made available soon, and can discussed here

Nope. The only fonts available from the cloud fonts are the basic RIBBI v1.05. Not even the Medium. And certainly not all of the 16 styles in the variable. The cloud fonts are kind of a mess. When I started doing a detailed inventory awhile back I found stuff missing, old fonts, misnamed fonts, etc., etc. Definitely a WIP. The lack of the Medium for the old static version is probably an oversight. But the lack of all the styles from the variable is likely a decision. Probably not what you wanted to hear. But variable font support is coming to your favorite Affinity app soon....

That is the older v1.01 from 2015 - only had four fonts (RIBBI). The two Medium were added in 2017 (v1.05). What version of Office do you have? You should be able to get all the font styles from the variable font from the cloud fonts. And the cloud fonts are all static. Hmm... let me check the cloud fonts json file to see if they are in there. If they are, then Office can be coaxed into downloading them. Office 2019, 2021, and 365 should all work. It should have the six styles at least, and maybe all 16 like the variable. Lets check... "I'll be back."

That family was changed in Windows 11 to be a variable font. If you get the Pan-European Supplemental Font Pack from Windows 10, the fonts are still separate static fonts - so they work in Affinity now.

The current SVG table format does not support it. So at a minimum that would have to change - or a new table added. SVG has some advantages but COLR is adding those. Similar to... the current CFF table for OpenType-PS fonts does not support variable - so they added a CFF2 table to be able make variable OTF fonts. But one of the things in the boring-expansion-spec is to be able to put PS curves in the glyf table where the TT curves are now. So the OTF variable fonts may end-up being an Adopey-only thing and not catch on widely. That is being discussed for COLRv2. And perhaps images too (so virtually all SVG advantages would be gone). Behdad posted a summary of the ideas for COLRv2 in the colr-gradients-spec repository on GitHub. SVG fonts are not likely to go away any time soon. They are easy to make and also support a monochrome fallback. SBIX does not have that fallback. Hopefully it will go away. CBDT - Google put that out to pasture in favor of COLR. COLR is the future of color fonts. COLRv0 is stable. COLRv1 is still being tweaked, fixed, and added to. But people can and are making COLRv1 fonts now, both static and variable. You download them from GF, and there are some others in GitHub, and you can find them more and more in places like CreativeMarket, etc. Once COLRv1 is stable then the focus will turn to COLRv2. Color-SVG fonts which are only vectors can fairly easily be converted to COLRv0 and COLRv1. The COLRv0 fonts already work in Affinity. We tested quite a few. Hopefully Affinity will add support for COLRv1 - the sooner the better. Microsoft converted the Win11 Segoe UI Emoji font to COLRv1 a few months ago. So 100% perfectly scalable with gradients. Update Note: an article said the new font had both the v0+v1 formats. But I just dumped the COLR table and it only has COLRv1. So I am not sure how Affinity is currently handling that emoji font on Win11. Guess going forward Affinity is going to have to support COLRv1 to still support color emojis in Win11. It's very late here. I'm rambling... Hope when Affinity adds variable support that it also includes at least COLRv0 variable.

Thanks for the correction. I'm obviously not as well-versed in this as Sérgio. As for them not being able to be made variable, I wasn't sure of that but half-suspected already, and I don't see why it doesn't belong in this discussion, at least as a starting point, because after variable fonts… it's the next obvious omission to tackle. I kindly invite the mods to split the relevant posts into a new thread if need be, of course. I would also add that said fact is not guaranteed to always be the case. If both formats take off, there can certainly be ways of making Colour-SVG fonts support variable axes. As a matter of fact, that same philosophy could be applied to the format and turn colours, and maybe even texture and gradients, into editable “axes”, instead of the format relying exclusively on Stylistic Sets as it still does, and those Stylistic Sets might even work as sub-fonts instead of the system, with their own axes, instead of being just presets of sorts. Regarding that newfangled Open Font Format spec, I like it, though I fear will face a bit of an uphill battle against OpenType. Anyhoo, I'll be watching Behdad Esfahbod's (impressive CV, by the way) stream when I get the time, but I looked at his presentation deck already (he mentioned advantages for the UFO format, which is a good thing, and clearly knows well the history of formats, including arcane stuff such as METAFONT), and the fact that all these bright people are putting their minds to these issues fills me with confidence. I'll be sure to check out all those resources, thanks!

I'm accustomed to looking for overlaps when using Variable Fonts (in either Adobe Illustrator or CorelDRAW). It's surprising finding overlaps in static fonts (note, I've seen these overlaps in static versions of Roboto Serif and Roboto Slab as well as the sans Roboto). For most users this is not a big deal. But if you're creating lettering that will be sent to a vinyl cutter or cut out of aluminum on a computer driven routing table the overlaps can be very bad. Out of habit I'm looking at every project in outline view.

The Roboto Condensed static fonts still have the overlaps. Most of the time font developers will remove the overlaps when the static fonts are created. But some of the GF tools do not remove overlaps by default. Developers using their tools can switch-on "remove-overlaps" and usually do. But since being able to properly handle overlaps is required when using GF variable fonts, GF will often leave-in the overlaps. If you are on a Mac, Core Text did/does have a rasterizing issue when two lines are on top of each other - it shows a bit of a halo where the overlap is. Do not know if this has been fixed or not (probably not). But the big jaggies you are seeing are an Affinity issue with the overlaps. They are going to have to solve dealing with the overlaps to support variable fonts. Variable fonts are never going to remove the overlaps. Note: As a work-around for now, you can remove the overlaps from the Roboto Condensed static fonts yourself.

The COLR table was added in OpenType 1.7, in 2015, (for the COLRv0 format). The COLRv1 format was added in OpenType 1.9, in Dec. 2021 (so that part is newer). Color fonts using either COLR format can be variable. Color-SVG fonts cannot be variable - so they really do not belong in this discussion. Proposed changes and updates to the OpenType spec can be followed on GitHub. Here: https://github.com/MicrosoftDocs/typography-issues Future font technology is also being developed on GitHub, and in an ISO group. The code development and specs are here: https://github.com/harfbuzz/boring-expansion-spec?tab=readme-ov-file They have been interacting with the ISO for developing the Open Font Format specification. There is a newsgroup set-up by the ISO where this is discussed. Note: the Open Font Format will actually be open, unlike other ISO "public" standards which must be paid for (people made a lot of noise) so you can download the current version from the ISO "free" standards page. No patents involved as far as I can tell.

Variable fonts are coming soon to the 2.5 beta: https://forum.affinity.serif.com/index.php?/topic/202284-variable-font-support-coming-soon-to-25-beta/

That is an extremely interesting, patent- or OpenType-spec-worthy feature. But, as you may guess, I suspect that would only happen if Serif/Canva brought that idea to the table, perhaps, again, along with another company and set of developers like those at FontLab Inc. or Glyphs GmbH. You see, the Variable OpenType font format is a bit of free-for-all, anything goes! They are axis-based, and there aren't exactly standards set in stone. As a matter of fact, it is impossible to anticipate everything and anything type designers may come up with. LTR Beowulf by LettError and Chee by OH no Type Company should tell you all you needed to know about just how wildly creative they can be once they become proficient with this technology. Surely we can band together and crystallise all the historical, most obvious axes (like width/weight, optical size, slant, etc., as defined in the OpenType Design-Variation Axis Tag Registry…), but if we were to stay true to Variable OT's (and, indeed, Gerrit Noordzij's and Catherine Dixon's) infinitely flexible and expandable conceptions of typography, we would have to come up with an equally and inherently flexible “standard-less standard”, which type designers themselves could use as they saw fit and make visible on various software packages' UIs. I have been mulling over the use of private use area/OpenType-specific and non-Unicode glyphs dedicated to UI elements for axis labelling on Character/Variable Font interface panels (type design apps are, after all, vector editors par excellence, and type designers are obviously expert vector designers, which means the results would be, in general, very decent and compelling). That might mean that conceptually similar axes could have slightly different (and, in some cases and for a while, wildly different) labels across different fonts but, as with all other things, over time some new standards (mirroring what Dixon calls, in her advanced typographic categorisation/taxonomy system, “patterns”) would eventually emerge. Could we use the same ideas and tech for, say, custom cursors? Toolbar button icons? Direct axis control nodes? Hover labels/interface aids/naming for the latter or even all of them? Could we even take all of these principles and help solve the mess that are currently the heretofore cryptically-numbered OT Stylistic Sets in one fell swoop? Maybe. Your additional ideas regarding direct manipulation are very intriguing, and if you're willing to cooperate with our Typography research group on a future paper/patent (or, at the very least, provide me with your real name so you can be properly credited for the idea), hit me up. None of this can happen in a vacuum, and requires some degree of cross-disciplinary cooperation (scholars, type designers, and type design and DTP software developers – Serif, once again, I'm also looking squarely at you, and I suspect my exclusivity agreement doesn't preclude from working on or even receiving royalties from IP), followed by some industry-wide agreement. Ultimately, the arbiters of any proposed extensions will be Microsoft and Adobe themselves, as they're the ones who created OpenType in the first place (I don't fully understand exactly which company actually controls it, but it seems to be Microsoft). If you want to see how things stand right now, take a gander at the OpenType 1.9.1 Alpha spec page. There's a lot of interesting stuff there, including, incidentally, a new “colr” table for colour fonts… I would also recommend that @Ash and the team keep an eye on these developments, especially if you think waiting for the final spec to be published is a sensible approach to supporting colour OpenType-SVG fonts in a future version of Affinity.

The best thread to discuss font-related functionality would now be the sub-thread related to the upcoming variable font support in v2.5 beta. IMHO, I would say it is a feature worth adding, because it's something that Adobe offers and is becoming trendier, and could be very popular among big sectors of Affinity's and Canva's userbase. I provided Ash with a recommendation of one of the best experts in colour OpenType-SVG fonts in Europe – and one used to work in the UK, no less –, so the ball is on their court and let's see just how loaded with cash and willing to expand Serif is now, post-acquisition. I take it that they still have to have a bit of restraint in their recruiting process (be it for full-time employees, contractors or consultants), project management and goals, etc., but we should indeed expect speedier development from now on. The ball is on their court, in any case. Interesting as this feature may sound, I highly doubt it will ever be available. It's extremely niche, and might result in quality control issues if lower quality, user-made localisation files ended up on the web. Also, with Affinity potentially becoming bigger, hiring more people for their localisation efforts would render said feature redundant for a lot of communities. And, if I may say so myself as someone from a minority community of one of top languages globally (Portuguese from Portugal, not Brazilian Portuguese), while it saddens me to see the technical design and typography jargon in pt-PT wither away (I do fight against that by recommending technical dictionaries to my students, mind you), I don't see people defaulting to English on technical software as that dire of an issue when it comes to serving a global market (RTL and Indic script support, on the other hand…). These apps' UIs are usually very sparse on text, and YouTube and the web are chock-full of tutorials using the English terminology anyway. My €0,02.

Well, it is a Beta, after all… 😂 Anyway, thanks for the laugh and the historical architecture trivia, I had never heard of Fonthill Abbey (interesting name, by the way, seeing how variable fonts were always the proverbial hill I was going to die on 🙃)… Looking at its design, it makes me wonder if it served as an inspiration for the design of Sauron's Barad-dûr, and reading the text, all with the tower collapsing twice before finally being made out of stone and surviving and whatnot, it also reminds me a bit too much of Monty Python and the Holy Grail's Swamp Castle and makes me think it might've also been a true source of inspiration for the latter's troubled development legend… After all, Terry Jones was a historian and, despite having specialised in the Middle Ages, he surely would've been no stranger to that kind of cultural reference. 😉

Variable fonts are a useful addition also with regard to use in web designs. But there is something strange i found when using the "new" Roboto Condensed from fonts.google.com. I guess this is not a bug, it also appears in the current v2.4.2. https://fonts.google.com/specimen/Roboto+Condensed For compatibility reasons with current web projects i installed the 18 "static" font styles, not the single variable font itself (RobotoCondensed-VariableFont_wght.ttf). Here is the test file: 2024-04-19-variable-fonts-roboto-artefacts_1-1.afpub As soon as a drop shadow or other effects are applied to the text frame, visible artifacts occur depending on the letter. This doesn't seem to be an affinity bug, but rather due to the way certain letters in variable fonts are constructed. Instead of the usual compound paths, the letters consist of individual shapes that only visually merge into an overall shape through overlapping. Your can see this in the wireframe view even without converting the text frame to pathes. The problem now seems to be that for certain letters, especially the bottom and top edges, the effects are applied to the internal individual shapes instead of to the entire letter (composite shape). Depending on the font size, this results in “bumpy” outlines. This doesn't just seem to be a display problem in the editor only. Some of the artifacts are retained even when exporting for the web (PNG, JPEG). Did the developers also experience such artifacts during the integration of the real variable fonts? Or is this a special case that occurs when a variable font is broken down into individual font styles ("static") for compatibility reasons. Like Google did with the Roboto Condensed variable font.

Actually currently for SVG we will always convert a variable font to curves. For PDF as Walt suggests we effectively create a new static font with the attributes applied which we embed within the PDF file. i.e. if you use 5 variations of the same variable font within your document, the PDF will have 5 'different' static fonts embedded.

For SVG you can use variable fonts if the rendering application supports it. ie: you can use variable fonts in most web-browsers available today. For other contexts such as importing into other applications; CAD, 3D tools, cutting tools, etc I suspect most SVG implementations in these contexts won't support variable fonts and converting text to curves will likely produce much better results.

For PDF, presumably the same as every other application that supports Variable fonts and PDF: the application must generate a Static subset of the Variable Font and embed that in the PDF. Or it must Convert to Curves. I have no idea about SVG, except perhaps using Converting to Curves.

<mod edit> The replies below were made in relation to a post pre announcing Variable Font Support </mod edit> An important step, but don't discount that color font support is also important. If not in parallel to variable fonts, please make sure these are not neglected either!