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.

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

It’s interesting that there already is a Blender-like solution (confer my screenshot above) for the new Typography Panel, as shown in Ash’s announcement. So the UI framework basically seems to allow transferring a rendering logic for sections from dialogs to panels. Remember that the above rendering of panel sections in the new Typography Panel is essentially the same as it is in the current dialog (and also the same as it is in the current Preferences Dialog), so I wonder whether this new approach could be transferred to all other panels.

@fde101, I couldn’t have explained my suggestion any better … 😀

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

Out of sincere interest, what specific aspects of color fonts make this technology interesting for you as graphic designers and typographers?

Find and Replace is your friend here. Make a Character Style with only the No-break Attribute set, and replace any sequence of three periods by a sequence of three periods formatted with this Character Style.

Cool. Thanks for looking this up. 😀

Many thanks! 😀

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

Publisher 2.3.1, latest MAS version, macOS Sonoma 14.3.1 (23D60), MacBook Pro 16'', 2019, 2.6 GHz 6-Core Intel Core i7

Please take a look at the attached files. The .zip archive contains a Publisher file and a test font. The test font contains six glyphs /A/B/C/A.sc/B.sc/C.sc/, all of which are just rectangles of the same width (but different heights). There is something strange with the computation of tracking. In the screenshot below, there are two text frames, one containing the text string /ABC/ with the OpenType Feature c2sc applied to the text (blue text), the other one containing the string /A.sc/B.sc/C.sc/ where the small caps glyphs were entered through the Glyph Panel without using the OpenType Feature (red text). Additionally, a tracking value of -50 per mille is applied to both frames. Now, one would expect that the glyphs should perfectly line up. It shouldn’t matter whether the uppercase letters are replaced by the small caps letters through an OpenType feature or whether the small caps letters are directly inserted by the user through the Glyph Panel. The text should look identical. Yet, the two text frames look different. So there seems to be something wrong with your text shaper when tracking is applied. The glyph positions are not computed consistently. Please take a look. Thank you. 🙂 Test files: Tracking-Issue.zip

Thumbs up! Thank you for the great work. 😊

This is a super-tiny request, but it would help in recurring instances. Could you turn the Lock Children checkbox on the context toolbar into a toggle button with an icon, such that you can get rid of the label text? This way, the toggle would not require so much space on the context toolbar and could be shown in a situation like the one below. This is the full-width of a 16" MBP screen with these settings: It happens so often that I use a rectangle with child content, and Lock Children is always hidden in that instance. Please consider. 🙂