Search the Community

The sliders are correct and as expected for both fonts...

Dank voor uw opmerkzame reactie. Ik gebruikte eerst Sabon Lt STD. Dat is een gratis font met restricties voor publicatie. Toen besloot ik toch maar Sabon LT Pro roman aan te schaffen. En wel bij MyFonts. Dit kostte mij wel een rib uit mijn lijf: € 65,33. Na veel gedoe met Adobe dat het laatstgenoemde font gratis aanbiedt, wil het lokaal installeren van Adobe fonts voor andere niet-Adobe programma's niet lukken. Helaas... Ik krijg van Adobe niet de ondersteuning die ik had verwacht. Ik laat het hier maar bij en neem mijn verlies.

OpenType and Variable are not synonymous. You can have Static or Variable OpenType fonts, so you do need to make sure which you have installed.

One question again when we use Variable Fonts - there’s sometimes an Max/Min on Axes, why? If I want get a lower or higher value on a specific axes, is that also an restriction that can be unlocked by any Font Manager app?

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.

Hello and thanks for your response. Evey document does that, even in a new one. Hardware acceleration is disabled because of my older GPU (GCN 1). Edition Windows 10 Home Version 22H2 Installed on ‎4/‎1/‎2024 OS build 19045.4291 Experience Windows Feature Experience Pack 1000.19056.1000.0 The rest of the System: CPU R5 5500 2X 8GB DDR4 2666 RAM Mobo Asus with B450 OS and Apps on M.2 nVme Crucial P3 1TB have a couple more drives but are only for storage and not working any files from there. After I posted this it also started hanging on startup with 20% usage of CPU just to open designer, not to open any file. At first I suspected the high amount of fonts but this lag in tools happens even if I make a box and convert to curves. Also tried with fonts disabled, same lag in opening and while selecting tools in the doc. After the first time it goes away but there is just a bit of activity in the CPU and that's it, no reading from any disk or anything. Also the % of CPU may change, one time I open and it goes 20% and still hangs for 10-20s, the other time it may be at 10%. As I said this was not present since the very last update I got. Since it updated in app I think I have installed the msix version of designer. edit: this is not happening in my home system that is similar, but I don't know right now which windows version it have. It have slower SATA m.2 crucila, slower DDR4 (still 2X 8GB ) but a much more powerfull RX 5500XT 4GB as a GPU. I will also test in my laptop later which have an AMD APU 5425U I think.

Who's they? Adobe? I honestly don't know the ins and outs of the spec, but as far as I understand nameID 25 is optional. A type designer can also add a custom PostScript name to each variable instance in fvar. Then nameID 25 isn't used (for those named instances). This is the most straightforward in my opinion, you can directly identify a named instance by its custom PostScript name. Adobe has a spec that defines how a PostScript name should be constructed if there is no custom one (and for custom axes values), but all this doesn't (shouldn't?) really matter for Affinity. I have no knowledge of the internals of Affinity, but this is how I expect it to work: Affinity loads available fonts on launch. This list is given by macOS. Each font in the list has a PostScript name, as provided by macOS. When a user uses a font its PostScript name is written to the document. When the document is reopened Affinity asks macOS for the font with the saved PostScript name. Variable axes don't matter, because those are applied on top of the loaded font. Affinity doesn't have to construct any PostScript names in this case. InDesign might store the constructed PostScript name in their document. Such that it can identify the exact var axes, for example: RobotoFlex_20.000slnt_372.000wght.

Arend, Als je niet meer afhankelijk wilt zijn van adobe, op welke manier dan ook, zou ik gaan zoeken naar een alternatief. Oftewel ga bij google fonts(vrij voor zowel persoonlijk als commercieel gebruik of bekijk de licentie voor de zekerheid) kijken of er een vergelijkbaar lettertype is en gebruik deze in vervolg voor je publicaties. Dan kun je deze hele toestand met dit lettertype achter je laten.

I believe InDesign uses custom font loading. Fonts are typically identified by their PostScript name. It doesn't really matter how to identify a particular instance of a variable font, as the variable axes are applied after loading the font file.

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.

I'm not sure what you mean about no positive result. What were you expecting to happen in the new (only in the 2.5 betas!) variable font support that does not happen? What variable font are you testing with?

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.

I did not even notice that in the video (the hard to follow video). Given the variable support in 2.5 they had to make changes to how they process the names. With static fonts it is all in the name table. With variable you are still pulling the texts from name, but there are more "name" fields from the fvar and STAT tables. Think of it as Family&Style (from name now) vs. Named Instances (from fvar). So something had to change in how they process all the name fields. BUT, that font is broken either way. Not surprised there are issues in Affinity. Probably issues in other applications too. The font could be fixed so it works perfectly in any application, including Affinity. With properly working localization.

Hi @walt.farrell, While I've not tested it exhaustively it appears to affect numerous fonts, all available on 'Ye Olde Google Fonts'... though Montserrat seems to be ok so unsure whether this is a Font Design issue or an Affinity issue. Variable Italics.mp4

Can’t seem to install variable fonts on the iPad?

I'm just dropping myself into this string here, hoping you or somebody can help me figure this out. I am experiencing the exact same thing as some others. The Variations option is greyed out for me as well. The way I am understanding things is... All I should have to do is just simply choose any of my fonts that are 'Variable' aka 'OpenType' (not TrueType I am assuming) and be able to use the variations option. It's just as simple as that, correct? I have an endless amount of OpenType fonts installed and I continue to get the greyed out 'V'. What am I missing here? ((FYI- I'm on a Windows desktop - just in case that makes any difference))

Hi @Dezzallier welcome to the forum, great that you joined. As for your question. Publishers often ask to convert fonts to curves if they request files in graphics program formats such as Illustrator (.ai files) or Indesign (.indd files). Why are they doing this? Because the fonts used are not saved in these files, which may result in missing fonts and replacing them with other, basic ones. When sending a file in PDF format, there is no need to convert fonts to curves because all fonts can be embedded in this format, but many publishers ask you to convert them anyway. For this reason, it would be best if you asked the publisher you want to print from what their requirements are when it comes to preparing the file for printing to avoid misunderstandings and frustration on both sides. Personally, I send files for printing with fonts converted to curves because that's what my publisher wants. I hope this cleared up your doubts a bit. Regards.

FontGoggles is another variable font testing tool funded by Google Fonts. And they mention using it (in the issues tracker) all the time. Unfortunately (for me) it is macOS-only.

This is where I'm a little confused... Yes, e.g., on Google Fonts (other variable font websites are available) differing numbers of axes for variable fonts are marketed/promoted but I'm slightly unsure how one determines which axes the font designer has actually specified should be hidden... Why does Roboto Flex advertise 13 variables but only choose to make five available? I'm sure I'm likely missing the obvious but interested to know...

I had the Typography panel open. I was choosing fonts from the top panel and at some point the Publisher crashed. The document contained only one page and a paragraph of text was highlighted. Windows

Where are they shown as hidden? Also, what other software are you using that offers all 13 axes? Probably not relevant but I did a quick check in a Rich Text document in TextEdit version 1.15 on my Mac & that app does not support variable fonts at all. Pages.app supports the preset defaults but does not offer any axes for adjustment.

Hartelijk dank voor uw uitvoerige antwoord. Ik stel dit zeer op prijs! Helaas krijg ik in Affinity Publisher - bij Font Manager - alleen de gratis versie van Sabon LT Pro te zien, na het verwijderen van de Pro-versie. Namelijk Sabon LT STD. Het Adobe font Sabon LT Pro Roman heb ik dus op de manier waarop u dat uitlegt toegevoegd aan mijn systeem, maar Affinity ziet hem niet. (Ik heb de versie van MyFonts by Monotype dus verwijderd in C:\Windows\Fonts). Ik heb - dacht ik - exact de stappen gezet zoals u heeft beschreven. Na verwijdering van het font van MyFonts by Monotype is mijn hele boekbestand blanco. Heel misschien kunt u nog eenmaal een bericht achterlaten met daarin een antwoord wat u denkt dat ik fout doe. Nogmaals heel veel dank voor uw geduld.

If I understand you correct here, we could buy FontCreator, load our Variable Fonts there, “unlock” the hidden axes and then resave the fontfiles - then we freely could reveal whatever axes we want. Is that correct? FontCreator is 200 bucks, and only Windows… Wonder if FontCreator work in CrossOver Mac edition?

Hi @Affinity-Inspiration, That's simply because the New York font only includes the two axes seen in the dropdown. Different variable fonts will include differing numbers of axes based on those the font designer has: a) included in the font design b) wishes to make accessible to the user

You find yourself confused because it is inherently confusing! I think it would be wise to avoid having the static and variable versions of a font family installed at the same time, in much the same way as it’s best to avoid having TTF and OTF versions installed concurrently.