A_B_C

You can always store predefined instances (locations in a variation space) to a variable font. Not sure what additional value a “snap to discrete values” function would provide.

I've animated a drawing I made on paper 27 (!!) years ago in 1997.
Did all the cutting, slicing and editing in Affinity Photo. Long live the Affinity Photo Clone Stamp, non-destructive vector masking and the great exporter which directly exports to Spine, which is just wonderful! 😀 
I've used Esoteric Spine Pro to Animate it. 
Hope you like it!
 
Original Drawing on Paper (scanned):
 

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
 

A modest suggestion that would improve UX in the present framework: please add Collapse-all and Expand-all by Alt-clicking the section headers inside a panel.
This would at least provide a workaround for many orientation problems in crowded panels and reduce search time.

While you are at improving the UX by turning the Typography dialog into a panel (thank you very much for that, it is highly appreciated), would you mind reconsidering the overall panels layout too?
I still find that the current approach to draw panel sections is not very apt to visually keep things together that belong together, especially in the typography-related panels that have a lot of sections. The z-dimension (depth) management is not really compelling. Visually, the section headers are one level deeper than the panel surface, which creates a hierarchy problem that has been present from version 1.0.

A section heading should never sit inside a groove, for when you do it this way, you cannot create the impression that the heading starts a section whose contents will be subsumed under the heading. If you need a section inside a panel, there are much better, time-proven ways to do this.
To take a (really just random) example, here is a panel stack from Blender. I hope you can see that the visual depth management that is much clearer than Affinity’s. While it may not be perfect in any respect, it is clear at first glance what contents belong to the sections “Restrictions”, “Instancing”, “Line Art”, and “Custom Properties” respectively:

Now confer this example to your visual depth management in the following example. Can you tell at first glance that “Justification” opens a new section? Or doesn’t it rather seem that the bar in which the section heading lives is the footer of the dark area for tabulator settings above? Especially when the scroll bar is present on the right?

I hope you can see that there is room for improvement in this area. I know it’s not likely that you will overhaul your entire panel layout on occasion of reorganising the Typography panel, but maybe this change is a good occasion to take a step back and make notes for further improvements in future versions. So I just wanted to mention the problem here (again).

While you’re at it, would it be difficult to add the following feature for collapsing and expanding panel sections to all panels?
https://forum.affinity.serif.com/index.php?/topic/202656-please-improve-panel-visual-depth-management/#comment-1205284
A better explanation of the feature is provided by fde101:
https://forum.affinity.serif.com/index.php?/topic/202656-please-improve-panel-visual-depth-management/#comment-1205349
 

While you’re at it, would it be difficult to add the following feature for collapsing and expanding panel sections to all panels?
https://forum.affinity.serif.com/index.php?/topic/202656-please-improve-panel-visual-depth-management/#comment-1205284
A better explanation of the feature is provided by fde101:
https://forum.affinity.serif.com/index.php?/topic/202656-please-improve-panel-visual-depth-management/#comment-1205349
 

While you are at improving the UX by turning the Typography dialog into a panel (thank you very much for that, it is highly appreciated), would you mind reconsidering the overall panels layout too?
I still find that the current approach to draw panel sections is not very apt to visually keep things together that belong together, especially in the typography-related panels that have a lot of sections. The z-dimension (depth) management is not really compelling. Visually, the section headers are one level deeper than the panel surface, which creates a hierarchy problem that has been present from version 1.0.

A section heading should never sit inside a groove, for when you do it this way, you cannot create the impression that the heading starts a section whose contents will be subsumed under the heading. If you need a section inside a panel, there are much better, time-proven ways to do this.
To take a (really just random) example, here is a panel stack from Blender. I hope you can see that the visual depth management that is much clearer than Affinity’s. While it may not be perfect in any respect, it is clear at first glance what contents belong to the sections “Restrictions”, “Instancing”, “Line Art”, and “Custom Properties” respectively:

Now confer this example to your visual depth management in the following example. Can you tell at first glance that “Justification” opens a new section? Or doesn’t it rather seem that the bar in which the section heading lives is the footer of the dark area for tabulator settings above? Especially when the scroll bar is present on the right?

I hope you can see that there is room for improvement in this area. I know it’s not likely that you will overhaul your entire panel layout on occasion of reorganising the Typography panel, but maybe this change is a good occasion to take a step back and make notes for further improvements in future versions. So I just wanted to mention the problem here (again).

Ah, I see, thanks for clarifying.
Sounds good to me.

@GarryP that is not what @A_B_C is asking for - I understood the request quite clearly, and it is an obvious thing to have in place, which I definitely believe should have been there from the beginning.
The request is not to open or close the entire panel, but the individual sections within the panel, all at once.
In other words, clicking the triangle to collapse or expand "Ligatures", "Figure Position", "Capitals", etc. - but instead of just one of them, when a modifier is held down, collapse or expand all of them at the same time.
The idea is that if they are all expanded, you could collapse all of them at once, then expand individually the one you are interested in, without having to go hunt through the expanded sections that might have the one you are looking for scrolled out of view.

A modest suggestion that would improve UX in the present framework: please add Collapse-all and Expand-all by Alt-clicking the section headers inside a panel.
This would at least provide a workaround for many orientation problems in crowded panels and reduce search time.

A modest suggestion that would improve UX in the present framework: please add Collapse-all and Expand-all by Alt-clicking the section headers inside a panel.
This would at least provide a workaround for many orientation problems in crowded panels and reduce search time.

While you are at improving the UX by turning the Typography dialog into a panel (thank you very much for that, it is highly appreciated), would you mind reconsidering the overall panels layout too?
I still find that the current approach to draw panel sections is not very apt to visually keep things together that belong together, especially in the typography-related panels that have a lot of sections. The z-dimension (depth) management is not really compelling. Visually, the section headers are one level deeper than the panel surface, which creates a hierarchy problem that has been present from version 1.0.

A section heading should never sit inside a groove, for when you do it this way, you cannot create the impression that the heading starts a section whose contents will be subsumed under the heading. If you need a section inside a panel, there are much better, time-proven ways to do this.
To take a (really just random) example, here is a panel stack from Blender. I hope you can see that the visual depth management that is much clearer than Affinity’s. While it may not be perfect in any respect, it is clear at first glance what contents belong to the sections “Restrictions”, “Instancing”, “Line Art”, and “Custom Properties” respectively:

Now confer this example to your visual depth management in the following example. Can you tell at first glance that “Justification” opens a new section? Or doesn’t it rather seem that the bar in which the section heading lives is the footer of the dark area for tabulator settings above? Especially when the scroll bar is present on the right?

I hope you can see that there is room for improvement in this area. I know it’s not likely that you will overhaul your entire panel layout on occasion of reorganising the Typography panel, but maybe this change is a good occasion to take a step back and make notes for further improvements in future versions. So I just wanted to mention the problem here (again).

Apps: All
Platforms: macOS and Windows
As has been requested numerous times we have now converted the typography dialog from a pop-up dialog into a panel so you can now easily dock it / keep it available should you wish. 
This is available both fro the Window menu (note: this is currently at the bottom of the panel listing, but will be changed to be a sub menu from the Text panel options next week), and also from the typography button in the context toolbar  when you have text selected.
 

Variable fonts
Apps: Affinity Designer, Affinity Photo, Affinity Publisher
Platforms: All
You're now able to use variable fonts in all Affinity apps, providing a plethora of new typographic design possibilities.
As well as providing predefined font styles, such as light, bold and condensed, variable fonts give you fine control of specific design aspects known as axes of variation, or just axes for short.
To try out variable fonts in Affinity, apply one to some text and then:
- On desktop, click the Font Variations button on the context toolbar (or on the Character Panel).
- On iPad, tap the arrow to the right of Bold/Italic/Underline/Strikethrough on the Text Panel and then tap Variations.
Variation settings on desktop.

 
 
Variation settings on iPad.

 
You'll see settings for each axis that the font designer has made individually adjustable.

Axis' slider being dragged.
Many variable fonts allow you to adjust their width and weight axes, and possibly italic, optical size and slant. These five axes are common enough that they're defined by the OpenType specification.
All manner of other axes may also be adjustable, such as:
- the height of ascenders and depth of descenders to better fit your chosen line spacing.
- the stem terminals, to choose between straight and swelling.
- the width of counters, which are enclosed and partially enclosed spaces within glyphs.
For examples of other possible axes, check out the axis definitions that are available for variable fonts at Google Fonts.
You may see fewer axes in Affinity than are mentioned by a font provider's marketing. For example, Google Fonts lists 13 axes for Roboto Flex and Affinity exposes five of them. This is because we respect font designers' ability to specify that an axis should be hidden. This is part of the OpenType specification and means that software isn't meant to provide an interface for such axes.
Why would a designer do this? Well, a variable font might adjust an axis internally based on your choices for other axes that you can directly adjust. For example, observe how counter widths change when the weight axis is adjusted in the animation above.

Variable fonts and PDFs
PDF doesn't support variable fonts. So, when you export a PDF of an Affinity document that uses a variable font, we create a static instance of the font with fixed settings.
We've taken steps to ensure static instances of fonts are well named. You should find this minimises the need to identify the original variable fonts if you later import or place the resulting PDFs.

I think it would be the best solution, if you just added a menu entry “Highlight Glyph Substitutions” to the bottom of the text menu, as shown in my mockup below. 

Of course, there is no issue in this case, because Publisher simply does not replace the uppercase glyphs by the small cap alternates when you enable Petites capitales (Small Caps). Both the uppercase glyphs and the small caps have the same metrics in my example font:

 
The reported issue is specifically about tracking in the context of applied OpenType GSUB features. And this is where Publisher goes wrong. 🙂

I recently illustrated a Zebra Swallowtail Butterfly (Protographium marcellus) for my brother. He wanted a photo, which I did not have, so I decided to create an illustration for him instead. I used AD v2.31., but spent a lot of time in the Pixel Persona. I also made a few trips to Affinity Photo for a few features that AD does not support. Hope you like it. 

The translation for Petite Caps is "Très petites capitales" which Affinity handles correctly. This is a rarely used font feature.

I don't see this mentioned, so I will mention it here (at least). Export potentially uses lot of processing power as its default. That's battery. So to make the applications more mobile-friendly, it really should not be the norm to eat up processes willy-nilly just because we can. (This can also lead to the impression the apps are un-optimized/"wasteful" as a default, but that's a deeper discussion...)

Disabling preview could also make the window quite a bit smaller, which may help people with getting through the options quicker.

Personally, I would also appreciate to have an option to disable export preview. For some jobs, export preview is essential, for others, it’s not. In the latter case, the presence of export preview creates needless friction to the workflow. We are all conditioned to perceive a spinning wheel (animated “busy” icon) as an indicator that we have to wait for a process to complete until we get the result we want.
Though we do not really have to wait in the present case, it still “feels” not right to hit the Okay (“Write export file to disk”) button before the preview is rendered completely. There’s a psychological hurdle to do so, originating from our experience with “busy” icons elsewhere. Inexperienced users who don’t know about modern CPU management might not even know that they can press the Okay button before the preview is complete.
For all of these reasons — and yes, they are “soft,” psychological reasons, in distinction to “hard,” technical ones, but nonetheless, they shape the user experience! —, I would suggest that you simply add a little checkbox to the export dialog allowing to disable export preview. Hope that makes sense. 🙂

Hi there,
 
that is a pretty good question, and I doubt there is a direct way which relies on snapping objects to objects only. But for an approximate way to do it (which might eventually become an exact way, as soon as snapping is improved), you might try this recipe:
Suppose you want to reflect a triangle across a line (1). Then duplicate the line and rotate it by 90 degrees. Hold Shift to constrain the rotation values (2). Select all, but make sure that the bounding box created by the lines alone encloses all other objects. This will make the intersection point of the lines the center of all further transformations. Now duplicate all your objects and flip the whole duplicated object group (3). Finally, with the mirrored duplicate still selected, rotate the object group around the center, until the lines coincide and the duplicate triangle will be the image of the original one under reflection. This is the approximate part, but if you calculate angles beforehand, you can achieve a fairly exact result here as well (4). Done (5, 6). I really wonder if there is another method …  :unsure:
Alex

Well, of course, you can zoom in on the export preview to inspect your fine details. So that’s not an argument in favor of the request that there should be a button to turn export preview off.
I think the main argument remains that (a) export preview is not necessary for all jobs, and in such cases (b) creates needless UI friction by imposing a psychological hurdle to the user against quickly pressing the Export button. It is a simply a psychological fact that we are all trained to wait and expect something when we see a spinning wheel icon on a screen, even if we know that, in a particular instance, this spinning wheel icon does not tell us anything and does not want to make us wait with respect to our next action. Good UI/UX design should understand the importance of such psychological facts.
A toggle switch, two lines of code to hide the left panel of the export dialog – this should be done in a moment. Would it be so difficult to add this?

This shiny look is due to the use of inks that contain effect pigments … nothing you can do by applying gradients …  ;)
 
http://designshack.net/articles/graphics/an-introduction-to-working-with-spot-colors/

In case you want to apply the metal effect just to the stroke and not the fill of the circle shape, the simplest way to do so might be to expand the circle stroke using Layer > Expand Stroke and apply the style afterwards.  :)
 
Please note, that doing so will currently create a lot of nodes, so you could also use the Donut Tool to create the circle (ring) around your letters and apply the metal style to the donut shape. And please be aware, that there are fabulous metal styles by evtonic3 and Chris van Cleve:
 
https://forum.affinity.serif.com/index.php?/topic/12199-assortment-styles-vol-1/?p=52758
https://forum.affinity.serif.com/index.php?/topic/16559-dream-styles-volume-2/?p=74993
https://forum.affinity.serif.com/index.php?/topic/3686-dream-styles/?p=14487
 
Cheers, Alex  :)