A_B_C

Ah, I see. It was just a reference problem. I wasn’t sure what you were talking about. 😀
Oh, and yes, what I forgot to mention in my suggestion above: of course, we would need to have a way to create pattern presets for cross-references. Once the user is done with creating a cross-reference pattern (expression involving variables), they would need to have the option Save Preset, just as in other parts of the application. Basically, that goes without saying. Building the pattern over and over again is not much better than building the actual cross-reference itself. That would defy the idea of a pattern. 😉
In particular, it would be helpful if we could (a) store such pattern presets with a specific document only, (b) sync these patterns across parts of a book, and also (c) store the patterns also as application presets, just as we can do with color palettes.

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following:
Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀
 

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following:
Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀
 

Ah, I see. It was just a reference problem. I wasn’t sure what you were talking about. 😀
Oh, and yes, what I forgot to mention in my suggestion above: of course, we would need to have a way to create pattern presets for cross-references. Once the user is done with creating a cross-reference pattern (expression involving variables), they would need to have the option Save Preset, just as in other parts of the application. Basically, that goes without saying. Building the pattern over and over again is not much better than building the actual cross-reference itself. That would defy the idea of a pattern. 😉
In particular, it would be helpful if we could (a) store such pattern presets with a specific document only, (b) sync these patterns across parts of a book, and also (c) store the patterns also as application presets, just as we can do with color palettes.

Ah, I see. It was just a reference problem. I wasn’t sure what you were talking about. 😀
Oh, and yes, what I forgot to mention in my suggestion above: of course, we would need to have a way to create pattern presets for cross-references. Once the user is done with creating a cross-reference pattern (expression involving variables), they would need to have the option Save Preset, just as in other parts of the application. Basically, that goes without saying. Building the pattern over and over again is not much better than building the actual cross-reference itself. That would defy the idea of a pattern. 😉
In particular, it would be helpful if we could (a) store such pattern presets with a specific document only, (b) sync these patterns across parts of a book, and also (c) store the patterns also as application presets, just as we can do with color palettes.

Ah, I see. It was just a reference problem. I wasn’t sure what you were talking about. 😀
Oh, and yes, what I forgot to mention in my suggestion above: of course, we would need to have a way to create pattern presets for cross-references. Once the user is done with creating a cross-reference pattern (expression involving variables), they would need to have the option Save Preset, just as in other parts of the application. Basically, that goes without saying. Building the pattern over and over again is not much better than building the actual cross-reference itself. That would defy the idea of a pattern. 😉
In particular, it would be helpful if we could (a) store such pattern presets with a specific document only, (b) sync these patterns across parts of a book, and also (c) store the patterns also as application presets, just as we can do with color palettes.

Unfortunately, I’m not exactly sure what you mean by that. My idea was not about slices or reading meta-data from files, but about utilizing a UI logic that is already available elsewhere in the application and works great, as far as it goes. If “Page Number”, “Section Name” etc. were available as variables that could be used for building expressions just as it is possible with the path name variables in path name expressions for slices, it would be possible to recreate many of the features that are available in the cross-references systems of applications like Indesign.
Think of it from a practical perspective. As Paolo said, when you have hundreds of cross-references all of which are supposed to follow a complex pattern like 
See chapter <chapter number>, “<chapter title>”, on page <page number> of volume <volume number>,  you will currently have to assign four (!) cross-references to create a single (!) instance of this pattern. That means, you will not end up with hundreds of cross-references, but with 4 times as much cross-references in your document.
And from a practical point of view, it should be obvious that this is a pain:
First off, your Cross-References Panel will become overcrowded, making navigation increasingly difficult. You will easily lose track of which entries belong to the same quadruple and represent a single instance of the cross-reference pattern above.   And secondly, the current non-complex approach creates a potential error source of first rank. The reason being, that for each instance of the example pattern above you will have to check four pointers to locations in your document instead of a single one, where each of the pointers can be set independently from the others. By logic and economy alone, it should be obvious that the correctness of a complex cross-reference following the pattern above should not be a function of four independent data points. So, please, give us a variable-based system from the outset. I have the impression that the target of a cross-reference is already handled internally as a complex set of data, for otherwise the user could not switch between the “Display as …” options. But if that is the case, it should be not too difficult to expose the elements of that data set to the user in the form of variables that can be used to build complex expressions. Please consider these arguments. 😀
As a side note, it would be fantastic if each of the variables could be associated with an individual character style. This way, we could, for instance, automatically format expressions that represent chapter headings (titles) in italic style, or similar. 😀

Thank you Ash - I was not aware of the V2 caps lock toggle and this is a game changer for me; as a result, I've just spent the last four hours noodling happily with Paolo's DAUB brush sets and rediscovering what a subtle brush engine Affinity has. We can basically tick this one as solved... superb!
Wants I think would be subtle enhancements: nobody I am sure wants to copycat other platforms, but CSP obviously has a pretty mature context cursor system (i.e. eraser cursor for the eraser, the option to toggle the fill cursor to crosshair and so on) but these are possibly overkill. Obviously the likes of Rebelle, Artrage and the rest have their own solutions.
I'll pop a note in the existing brush options thread toward this solution.
Peter

Just to make sure you were aware we did add caps lock to toggle between brush outline and crosshair in V2. So the cursor options currently are outline only, crosshair only (caps lock on) or outline and crosshair (always show crosshair turned on in preferences). Plus of course being able to turn brush preview on or off. 
I thought that option at least covered the main subject being requested in that thread. What are the other main options you would like?



 

@A_B_C
Perhaps I should've expanded on the comment, but was basically agreeing the Slices panel is a great source of inspiration for expanding the potential using variable as it is currently underutilized.
Re: non-functioning: The user-defined variables portion is in the panel on bottom right of your graphic, but it's not visible as it's in the bottom. As-it-is, even if the user defines it there, it can't be used outside the scope of that slice, so it's basically not a global variable and thus no reference can be made to it.
For example, here I defined "@randomVar", but it's not able to be used in any other sliuces than this one so other than highlighting the component in a long string maybe? to aid readability, it serves no other purpose as far as we can tell.


To add another aside to the above suggestion, if we could somehow build references using individual points of data (references, meta, file data and alike) and have that made available to the user for insertion, it could open up the possibilities to create complex strings that could be reused, re-compiled on repetition. For instance, if the above example ("See chapter <chapter number>, “<chapter title>”, on page <page number> of volume <volume number>") is repeated numerous times, that string itself could also be saved as a reference and those <var>'s could already be referenced* and work/link fine...
Hopefully that's clear. If not, it's not critical.

Unfortunately, I’m not exactly sure what you mean by that. My idea was not about slices or reading meta-data from files, but about utilizing a UI logic that is already available elsewhere in the application and works great, as far as it goes. If “Page Number”, “Section Name” etc. were available as variables that could be used for building expressions just as it is possible with the path name variables in path name expressions for slices, it would be possible to recreate many of the features that are available in the cross-references systems of applications like Indesign.
Think of it from a practical perspective. As Paolo said, when you have hundreds of cross-references all of which are supposed to follow a complex pattern like 
See chapter <chapter number>, “<chapter title>”, on page <page number> of volume <volume number>,  you will currently have to assign four (!) cross-references to create a single (!) instance of this pattern. That means, you will not end up with hundreds of cross-references, but with 4 times as much cross-references in your document.
And from a practical point of view, it should be obvious that this is a pain:
First off, your Cross-References Panel will become overcrowded, making navigation increasingly difficult. You will easily lose track of which entries belong to the same quadruple and represent a single instance of the cross-reference pattern above.   And secondly, the current non-complex approach creates a potential error source of first rank. The reason being, that for each instance of the example pattern above you will have to check four pointers to locations in your document instead of a single one, where each of the pointers can be set independently from the others. By logic and economy alone, it should be obvious that the correctness of a complex cross-reference following the pattern above should not be a function of four independent data points. So, please, give us a variable-based system from the outset. I have the impression that the target of a cross-reference is already handled internally as a complex set of data, for otherwise the user could not switch between the “Display as …” options. But if that is the case, it should be not too difficult to expose the elements of that data set to the user in the form of variables that can be used to build complex expressions. Please consider these arguments. 😀
As a side note, it would be fantastic if each of the variables could be associated with an individual character style. This way, we could, for instance, automatically format expressions that represent chapter headings (titles) in italic style, or similar. 😀

Unfortunately, I’m not exactly sure what you mean by that. My idea was not about slices or reading meta-data from files, but about utilizing a UI logic that is already available elsewhere in the application and works great, as far as it goes. If “Page Number”, “Section Name” etc. were available as variables that could be used for building expressions just as it is possible with the path name variables in path name expressions for slices, it would be possible to recreate many of the features that are available in the cross-references systems of applications like Indesign.
Think of it from a practical perspective. As Paolo said, when you have hundreds of cross-references all of which are supposed to follow a complex pattern like 
See chapter <chapter number>, “<chapter title>”, on page <page number> of volume <volume number>,  you will currently have to assign four (!) cross-references to create a single (!) instance of this pattern. That means, you will not end up with hundreds of cross-references, but with 4 times as much cross-references in your document.
And from a practical point of view, it should be obvious that this is a pain:
First off, your Cross-References Panel will become overcrowded, making navigation increasingly difficult. You will easily lose track of which entries belong to the same quadruple and represent a single instance of the cross-reference pattern above.   And secondly, the current non-complex approach creates a potential error source of first rank. The reason being, that for each instance of the example pattern above you will have to check four pointers to locations in your document instead of a single one, where each of the pointers can be set independently from the others. By logic and economy alone, it should be obvious that the correctness of a complex cross-reference following the pattern above should not be a function of four independent data points. So, please, give us a variable-based system from the outset. I have the impression that the target of a cross-reference is already handled internally as a complex set of data, for otherwise the user could not switch between the “Display as …” options. But if that is the case, it should be not too difficult to expose the elements of that data set to the user in the form of variables that can be used to build complex expressions. Please consider these arguments. 😀
As a side note, it would be fantastic if each of the variables could be associated with an individual character style. This way, we could, for instance, automatically format expressions that represent chapter headings (titles) in italic style, or similar. 😀

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following:
Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀
 

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following:
Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀
 

“Super-fields” would come in super-handy. I wouldn’t consider those any more overwhelming to the user than the way in which custom path names are defined in the Export Persona. So I would suggest that you simply do the following:
Turn the options of the “Display (cross-reference) as …” menu that is available from the Edit Cross-Reference dialog into variables and borrow the user interface from the Path Name Definition flyout in the Export Persona to let us build super-fields in the sense suggested by Paolo T. The user interface and its mechanics are already there. Why not use these things for something else that would be very useful? 😀
 

It would be twice the work (for creation, maintenance, translations). If the blocks can be initially hidden, the implicit complexity of this feature may also be hidden. For example, if each block can be added by clicking a '+' button, only the basic block will be visible at first, but adding blocks would be extremely easy.
I don't know if the system adopted in ID, inherited from FrameMaker, is really needed. All considered, I think that the only types of cross-reference I've seen in my life are of these types:
- See ["page"] [page number].
- See [title] ["on page"] [page number].
- See [paragraph number] [title] ["on page"] [page number]
- See [paragraph number] [title]
- See [title]
Paolo
 

Thanks for the comments and suggestions. We plan to implement some of these, but it may take a little while.
We didn't provide Show as > Chapter Name because we figured the name of the chapter would normally be a heading somewhere in the chapter, so can be got by using the text paragraph body.
The Settings panel does include some document-specific settings. For example, the custom Filler text content which is also specific to the text language. While you are waiting for translations you can add your own strings. It is the spelling language from the Character panel that it uses. If that language is "English (US)" and that doesn't have a string, it will look for another variant of English instead, and similarly for other languages with regional variations.

Can all these fields be a single block, by building a "super-field" including all the possible options? 
An update command in the Book would also be useful, to update a complete book with a single command.
Paolo
 

A plus icon next to the cursor when cloning a layer by drag-and-drop would be very useful to have, as @Frozen Death Knight had already mentioned. But other than that, a great and long awaited addition! Thank you! 😃

Apps: All
Platforms: Windows, macOS and iPad
First of all the auto select drop down in move tool which was added to Affinity Photo in V2 has now been added to both Affinity Designer and Affinity Publisher, as requested numerous times from customers. This now allows you to optionally disable the move tool auto selecting objects when you click on them. This can be particularly useful when moving and transforming objects which maybe within designs where you can accidentally select something else, or you are working at a zoom level where it's hard to get the hit zone to drag-move an object. Now if you have an object selected and have auto select turned off you can drag anywhere on your document to move it.
You will see this option as a check box (icon on iPad) to toggle auto-select on or off, followed by a dropdown menu:


The drop down gives you the following options
Default - This is default behaviour, clicking on any objects or groups will select them. Objects / Layers - This will ignore any groups and automatically drill to select any child object you click on. This saves you needing to keep double clicking or cmd-clicking to drill into groups in complex designs.  Groups - This has limited use, but is another option you can choose if you want auto select to only select groups. i.e. if you click on an object which is not part of a group nothing will be selected, if you click on an object which is part of a group the group will be selected. Under (iPad only) - this will toggle your selection through the z-order of the layer stack in the case of objects which are stacked on top of each other. This achieves the same as previously setting the selection target to under (or holding alt). Note:
Now this drop down has been added the previous context toolbar option of "Allow selection to consider items inside of groups" has been removed. This is because that gave the same behaviour as what "Auto Select: Objects" now does from the new drop down. On iPad the previous Selection Target menu has been removed from the move tool context menu as any functionality which was previously possible with those options can be achieved using this new feature.  

I'm a somewhat new user of Affinity Design. I signed up to join this forum just because of this issue involving OpenType Variable Fonts.

I've been working in the sign industry for nearly 30 years, mainly designing outdoor electrical signs but also lots of other things too. I've used at least half a dozen or more vector graphics applications over the years, but have done most of my work within CorelDRAW and Adobe Illustrator. I haven't considered Affinity Designer as an acceptable replacement for either one of those applications at this point. But I have been experimenting with Designer because I think the potential is there for the application to become more popular, particularly for anyone doing design work on a limited budget. Lots of small businesses and individuals will try to "home brew" their own logos and other graphics materials. Just in case I start receiving customer provided artwork in Affinity Designer format I want to be able to handle it properly.

For my own design purposes OTF Variable Font support is very important. I really like variable fonts that offer weight and width axes. Such typefaces will give me more flexibility to create a design that has to fit in a fixed space, such as a replacement face for an existing tenant sign cabinet. There is a lot of truly horrible quality sign design out in the field. Quite a bit of it features default Arial artificially stretched and squeezed to cram into a spot in the layout. The "designer" can't bother to scroll down the fonts list to find a typeface with styles whose proportions fit in the space. I think sign designers have a certain civic duty to not visually poop on the commercial landscape. A badly designed sign may be visible on a building or next to a street for many years. Badly designed signs and poorly maintained signs help fuel public backlash and inspire severe anti-signs ordinances. Variable type can allow designers to deal with space limitations far more gracefully. A variable font that has a width axis can be "squeezed" yet maintain the proportional balance of its vertical and horizontal strokes.

I spend a pretty decent amount of money on commercial type. Most type families I've purchased lately have included variable versions along with a folder filled with many static instances. Some purchases had only variable fonts in the package. For instance when I bought a copy of Proxima Vara I downloaded just one font file. I was pretty happy to see the arrival of the OpenType Variable format. I remember using Type 1 Multiple Master fonts in the 1990's (within Adobe Illustrator). The OTF Variable format brings back the Multiple Master concept, but with the much larger OpenType character set capability.

I really don't care whether Variable Fonts are supported by PDF or not. With a lot of the design work I do I tend to convert the type objects to outlines during the design process or when I finish it. But the Variable Fonts have become an important tool for the design process.

It's worth noting Adobe recently added more than 140 Variable Font families to its Adobe Fonts service. Out of vector drawing applications I think Adobe Illustrator has supported the OTF Variable Font format the longest; it's also one of very few that support OpenType SVG (aka "color fonts"). CorelDRAW has supported OTF Variable since its 2020 release IIRC. Even Inkscape supports OTF Variable Fonts now. I think it's pretty important for Affinity Designer to add Variable Font support sometime soon. 

A plus icon next to the cursor when cloning a layer by drag-and-drop would be very useful to have, as @Frozen Death Knight had already mentioned. But other than that, a great and long awaited addition! Thank you! 😃

Again thank you for cross references, I needed this.
Use Index Marks as targets: One feature ID lacks is Target Type = Index Mark. For some books everything you might ever want to cross reference will have an accompanying index mark so being able to target an index mark would save time and be a nice feature. For example, in a book of biographies you might write "See John Doe on page 123" and John Doe would be in your index. In a cookbook you might write "See the recipe for Lemon Icing on page 123" and Lemon Icing would be in your index.
Anchor generation: Using a paragraph as the target generates an anchor at the start of the paragraph which makes sense but its name is a truncated version of the first words of the paragraph with an appended number for duplicate names, which leads to an anchor list full of things like "Less than", "Less than 2", "Four of", "Their son", "Robert's", and "William". Perhaps the dialog could offer an optional field to name the anchors to save a step?
Target Type = Target Chapter: I think it should list the chapters as names and not as numbers. Most books have front matter so what Publisher considers to be chapter 2 will almost always be chapter 1.
Books and chapters: While Section Name is offered, Chapter Name isn't so I'm unsure how we'd generate "See Apples in <Chapter 7>".
Minor stuff:
Deleting cross references: Shouldn't there be a Delete option in the panel? I know you can delete one by selecting it with the Text tool and pressing Delete but similar panels have Delete icons. Filter Text and Style: Shouldn't these be disabled when Target Type = Anchor? Panel size and position: The panel's default height and position could use some improvement. Maybe default to docking at the bottom of the left studio? Name column in panel: You can't click a name to edit it inline as you can with similar panel lists. Display As > Above Below: Will these be localized in a future beta? Yes with Settings Chapters: The "Ch." column should be named Chapter and as with the dialog the values should be names instead of numbers. Control alignment: The controls at the top and bottom of the panel aren't vertically aligned in their spaces. [added more] Paragraphs: The list of paragraphs shouldn't include index or TOC text or else people might accidentally create cross references to text that will soon be replaced, losing the anchors. End characters list: It looks like there's a separator at the top of the list, as if there was supposed to be another option above it. Menu grouping: Cross references and Anchors fit together just as well as Anchors and Hyperlinks fit together, but Anchors are grouped with Hyperlinks. I don't use Hyperlinks but I will use Cross References so I will now also be using Anchors. Perhaps group all three together in the menu?  Display As > Anchor Name: There's no way to insert an anchor's name as the Display As format which isn't that important for print documents but is for interactive PDFs. e.g., if I've named an anchor "Boiling the Ocean" then I could use that name when I insert a cross reference to it. e.g, "See Boiling the Ocean"  Settings > Cross References: Is Settings the right place for this? The values shown in the fields are the current document's defaults and nothing else in Settings shows document defaults. Perhaps this should be in a standalone dialog accessible from Text > Cross References or from the panel's menu? Changing any English language option except for "English" (US) will change all English language options except for "English" (US). Changing English (US) will change only it. Is this intentional? I had one crash while editing a cross reference but I couldn't duplicate it so this likely isn't useful. I'll keep an eye on this but the steps were roughly delete the generated anchor, edit CR, target=paragraph, pick a new paragraph, click OK and then it crashed.
Affinity Publisher 2 Beta-2023-03-01-132035.ips

This was actually already logged, I just missed it on the known issues. It actually does sort, but you need to refresh the table to see the sort (which can be done by changing the target type between anchors/paragraph). Should hopefully be fixed in the next beta
I'll look at getting this added as an improvement

Apps: Affinity Publisher
Platforms: Windows and macOS
Cross-references are a field inserted into text that refers to another object or piece of text. If the current document is a chapter of a book, cross-references can refer to objects or text from other chapters.
You can insert a cross-reference by using Text > Cross References > Insert Cross-Reference, or by using the right-click menu on text. If a cross-reference is already selected, these options change to Edit Cross-Reference instead. Either way brings up a panel to set the cross-reference properties. The first group of properties are about the target of the cross-reference. This can either be an existing anchor, or a text paragraph. (If you cross-reference to a paragraph, it will automatically create an anchor at the start of the paragraph.) The second group of properties are about how the cross-reference will be displayed. These include as the target page number, section name, and the content of paragraphs. By using several cross-reference fields you can build up text like, “See footnote 2 on page 12, below”.
The Window > References > Cross-References menu option will display a Studio panel that lists the cross-references from the current document. From here you can go to the cross-reference itself, or its target. (This will open other book chapters if necessary.) You can also update cross-reference text from here — they don’t update automatically.
Settings > Cross-References has options for controlling the text used for showing relative positions “above” and “below” (these will use the language of the text they are in rather than the UI, for support of bilingual documents).