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.

Be aware that there is a variable version of Open Sans. Affinity can't use variable fonts, so make sure you are installing the static versions. You could also try using a font manager, rather than installing the font(s) directly into Windows. (Personally I use the free version of FontBase.)

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).

are these variable fonts?

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…

Hi @Hangman, first and foremost thank you for taking the time for my issue. The pdf files aren't in my belongings anymore, I will take them out of the file and see if that changes anything. That normally shouldn't be an issue though. The font is indeed from google fonts, whether it is variable or not I can't tell you. One last question: What also doesn't work is saving this file as an affinity document. I go to "Save as" give in the file name and click "Save". The window disappears but no file is saved. Is this a known issue?

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.

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.

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)

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

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.

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.

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.

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.

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.

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.

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?

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. 🙂

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

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.

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.