Search the Community

No. M365 gives you access to the cloud fonts. And the cloud fonts include static versions of the Bahnschrift instances/styles. APub does not support variable fonts (or you could use the Bahnschrift VF as is). So you coerce M365 into giving you the static versions, which you can then install and then use in APub. Once you have the static versions, this requires disabling the variable version - because the static style names will conflict with the instance names in the variable font. Cannot have both installed. (This would be really easy if APub had an application fonts folder! ! !). So if you just-gotta-have Bahnschrift in APub, this does work. I can explain step-by-step if you are interested.

I guess that it is the degree of co-operation and co-work that dictates which tools need to be used. If the idea is that your team can share common native file format for cross editing, and that file format for the rest of the team is AI (even if including PDF streams), or Illustrator EPS, or PDF that preserves Illustrator editing capabilities, you really need to have Illustrator as your tool, since AI and (Illustrator) EPS support of Affinity apps is very limited (as is support of these formats in other apps). [Even pure PDF support of Affinity apps is not complete, and even if it were, would not support many of the features that would be important for cross-editability, starting from layers.] This is pretty much the same situation as if the rest of the team worked with Affinity apps using .afpub, .afdesign and .afphoto (which are one and the same format), but one of the team members needs to have files sent as PDFs. Exchange of information would be severely limited and much of the editability lost. It is unlikely that this will improve in the future because proprietary file formats guaranteeing full editability will stay that way. Working with variable fonts however is not necessarily very common within Adobe app based team work, either, even if the most prominent Adobe apps support them well. Adobe Fonts, e.g., as far as I know, still only offers static fonts. As long as projects involve printing, use of variable fonts, IMO, is a bad idea.

As we speaking about fonts/typefaces, what font/fonts is your favorite? Also, which variable fonts is most awesome? My favorites is Scala, Pitagon, Officina and Literata… Use to like Bookman in the past…

No. Nothing wrong with the variable font. Not a font specific issue. The issue is with those applications not being able to apply a stroke properly. (which I wrongly assumed they would be able to do if they support variable fonts)

I think PixelPest mentioned Vectornator Pro. I assume that what was meant is that enumerating fonts should be in the hands of the developer so that irrelevant fonts can be skipped. If defaults are used, or library functions that are not customizable, you get bulk lists. But as shown there seems to be more than just this, some old caches, etc., and also anomalies related to OS updates (e.g., so called Document support fonts that were revealed in earlier OS versions but are now hidden; or system fonts that were formerly distributed as static fonts but are now distributed as variable fonts).

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.

Patrick's comment is regarding variable fonts, not font collections. I tested a TTC file which also includes two font families, but has nine weights instead of just two, and includes italics. The results are quite bad. Affinity Publisher v2.1.1 - exported to a PDF, and then exported to an image. Bold does not appear, and all the Italics are corrupted. LibreOffice v7.5.5.2 - exported to a PDF, and then exported to an image. Looks as expected.

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.

@LibreTraining Brilliant! Thanks so much for this entire illustrated discussion lesson and for sharing the post FontCreator conversion of the (2) circa 1994 fonts. Looking at the metadata for my old fonts, with the help of Phil Harvey's amazing ExifTool; something I've used forever with images, but never thought that it would work with fonts, the spreadsheet was produced via the command line: exiftool -csv -r "c:/Windows/Fonts" > "L:/Serif Software/font related/fonts.csv" Out of the 1600+ files, there are 250 files copyright tagged FontBank, Inc. ROE which include the GaramondAmerica and BodoniExtraBold examples. But what isn't revealed by ExifTool are the bits about the character encoding; i.e., Unicode 1.0 (0,0), Windows Symbols (3,0), etc., presumably hidden in the Private Use Area (PUA). I'm guessing that none of them can be correctly rendered by Affinity applications without first doing the quick font fix you spoke of using font editors such as FontCreator and FontLab to convert these fonts to Unicode by using the glyph names, and then assigning the correct Unicode codes based on those names like your examples in fixed-fonts. For now, and probably forever, there's no burning need to consider doing this quick fix, even for the nerdy fun of trying. I probably should instead focus on the greater parts of Affinity Photo during this trial period in the 7 days that remain. So back to the general issue of Affinity non-supported fonts, including what Walt first introduced, Variable fonts, which I have not played with yet. Font substitution allows for some means of still being able to make sense out of a character string when the application; e.g., Affinity Photo, can't otherwise display the string. That's nice, but there ought to be something communicated to the user detailing 1) why the intended font was unable to be correctly rendered by Affinity Photo, 2) why font substituere was chosen, 3) maybe suggested methods to remedy the situation, and 4) maybe allowing the user to choose the default substitution font. The latter would readily facilitate /communicate /flag the issue to the user once the popup notice had been dismissed.

Thanks @Hangman - if I'm honest, at first I thought it was an issue with the way I had imported the Google Fonts but as I was writing this topic I started digging a little deeper and found the common problem of the variable fonts. I had only researched "Google Fonts, affinity designer kerning". I'll just have to figure a better solution for getting fonts onto my machine and follow this topic

On the Mac Affinity applications use the macOS font picker, and that picker list does support variable fonts so it displays them - even though the application does not support variable fonts. Which is obviously confusing to users. On Windows the font picker displays the default master which according to OpenType specs is what is supposed to happen. Both methods are not ideal. Users should be told the variable font is not supported.

Welcome to the Serif Affinity forums, @Heidi.Gray. I don't see a screenshot attached to your post, so perhaps it did not attach successfully. Just guessing, but as you've mentioned installing fonts from Google Fonts, they are often available in two formats. When you download, the default you're likely to install are Variable fonts, but unfortunately those will not work with the Affinity apps. You should also have gotten a folder named "Static" (or something like that). The fonts in that folder are the ones you need to install if you want to use them with the Affinity apps. So my first suggestion would be to uninstall the fonts again, and make sure you install the Static versions. Then retest exporting again to see if the font embedding works better.

If variable fonts are definitely not supported in v2, perhaps the actual bug to report here is a UI issue. In other words, there are 15 duplicates of "Regular" for variable fonts, when there should only be one "regular". (I'd prefer variable font support of course, but at least fixing these duplicate "Regular"s will improve the UI.

Bahnschrift is a variable font, and variable fonts are not supported. When variable fonts are not supported the application is supposed show the default master - which in the Bahnschrift font is the Regular master. So that is what appears. Note: you should be able to use that Regular default master like any other static font. (I need to confirm this in v2 later today, but I expect it works).

But I wonder what’s your point, @fde101. All three operating systems (macOS, Windows, iOS) already support variable font rendering and offer the respective APIs, and the Freetype project provides a freely available cross-platform software library to render variable fonts. Personally, I’ve never heard what @DamienG said, namely that the Affinity apps would already use Freetype. I doubt they do, for they would probably have been able to add variable font and color font support already, if they did. It would be interesting to hear from a developer about the text layout engine currently used in the Affinity apps or receive any comment on this thread. Everything is just speculative to this point.

I wonder if those odd fonts were instantiated/created to handle text that was made from a Variable font?

My guess: You have installed the Variable version of that font, which will cause this problem as Affinity only supports Static fonts.

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?

It only appears to work on the Mac because the macOS font picker displays the variable font pre-defined styles (instances), even though you cannot actually use them. Try making a test doc with all those listed styles. Will not work. What is supposed to happen when variable fonts are not supported is the application is supposed to display the default master. The default master in the Audi Type Variable font is the Normal master. So that is what is displayed on Windows.

I guess I did not make my point very well. To me the process is nearly the same. And what ends up in the PDF is exactly the same. The main point is there is nothing preventing using variable fonts for creating PDFs. So to me that means they work now. The differences are in the font handling in the application, not the PDF. So to get back to the original request, Affinity applications could support variable fonts now if they add that ability, and there is nothing about PDFs which would prevent that. OK. Climbing down off my soapbox now. 🙂

Hmmm... Someone must have modified this font from the original (badly). All the character code-points are in the normal Basic Latin bloc, not in the PUA. 26 are in the lowercase and two alternate forms are in the uppercase. There are overlaps in many of the characters - which should be removed. And some basic characters are missing, such as space, etc. @uhebeisen I like this font so I will fix this for you (and everyone else). Just watched a documentary on the Hawker Hunter 2-days ago (go RAF!). May get to it today, maybe not. Documenting bugs in new variable font for a friend - which is going to take hours. To Do: - check all the outlines for any issues and fix - remove all the overlaps - put all 26 characters in both the uppercase and the lowercase code-points - put the alternates in a stylistic set, and in character variants - add a few missing basic characters - like a space - export as OpenType-PS (.otf) and OpenType-TT (.ttf) May get to this today. We'll see. Not sure what you mean by this. OpenType-PS (.otf) fonts are fully supported in Affinity.

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.