sfriedberg

There has been discussion of this on other threads, but I will chime in here as well.  Yes, if you are doing graphic art that feeds into a printing pipeline, you need the ability to view (and tweak) color separations.  In addition to showing the separated channels, there should be tools (maybe like video "zebra" overlay?) to show areas with "too much ink", unwanted "rich black", etc.  The Affinity suite should provide these tools, so plates can be checked before export, rather than after.
There are also some artistic cases where control over the screen (frequency and angle) for each channel is a design element, not just a make-ready consideration.
Additionally, the color management settings and flow need to be elevated to a much higher level than they are right now.  I'm of the opinion that the profiles associated with everything should be explicit, user-settable, and resettable to the appropriate file/device/system default.  And users should be able to load ICC profiles into the Affinity apps even if the OS doesn't have a place for them. Automatic "it's for your own good/convenience" color conversions lead to madness and premature baldness -- hard-learned lesson from painful experience.

The problem is the use of Split Notes and Text Wrap together as I was thinking but I was looking at the wrong picture. The bottom picture is irrelevant, it's the top one. In fact, footnote 26 is irrelevant, too, it's just footnote 25 and the top picture's text wrap.
To work around this bug, I recommend turning off text wrap on the top picture. Choose Layer > Master Page > Edit Detached and then drag the text frame's top middle handle so that its top is below the picture. Click Finish when you're done. This will avoid the use of text wrap which triggers the bug and will avoid overlapping the picture with text. I tried that and it worked well.
Good luck, and I hope you don't have too many other pages like this!

You can do quantization to exact number of colors using a trick that I have shown a couple of times on this forum (earlier video clips probably deleted because of Affinity forum max storage limit), using the Gradient Map, Posterize and Black and White adjustments (in this order) on underlying layers (projected against a solid background):

quantization_brushes.mp4 Note how Affinity apps create a document palette based on effect of adjustments even if part of the manipulated layers fall outside of the background (so that the image actually still has dozens of orange tones, quantized number being effective only within the boundaries of the background rectangle). 

I've done a couple of sessions of curve editing in the last few days, and have a request for enhancement for joining curves.  When working rapidly with already trimmed curve segments, I do not want to have to zoom in on nodes and painstakingly drag one node over another to join two curve segments.  I want to quickly box select both nodes and weld the two nodes together. Bam. Done. Move on to the next joint.  Repeat.  Bam. Bam. Bam. Bam.  No fussy business, no delay.  Just efficient work.
What I get right now with the "Join curves" Action of the Node Tool (A) is an additional line segment between the two nodes.  This segment is usually hidden by its tiny size, until I apply an operation like a boolean or the new beta contour, or apply a wide stroke.  Then the insanely high curvature of a curve doubling back on itself twice makes it clear there's a little glitch that absolutely must be cleaned up before I can go on to the next step.  Slowly, and painstakingly.
So I would like to see another toolbar Action for the node tool, where selected nodes are not joined by a line segment, but merged into a single node.  Adopt a rule that the highest (or lowest, I don't care) node in the layer stack is moved to the position of the lower, so if you are working with a precise design, you can reliably preserve known locations.  Moving both nodes to an average location is much less useful than keeping one readily-identified node in a fixed location.  Please do not base the rule on selection order.  The node visual indicators are usually overlapping, and having to select the two nodes in a particular sequence would be a huge pain in the patoot, and require more of that slow, zoomed-in, painstaking work. Box select, weld, done, repeat.  That's what I want.

I'd like to add a voice to the request for equation support, as almost every technical document I prepare has at least a few equations, and some documents are very heavy in equations.
I'd be willing to live without an interactive equation builder if AffPub allowed me to place MathML files in a frame, with proper formatting of the MathML content, of course, not just dumping the raw text into the frame.  MathML is a mature open format, and there are lots of tools to work with it (which is why it's not essential to have equation builder support inside AffPub).  MathML 3 support would be nice, but MathML 2 would be sufficient for what I work on.
There should be the same sort of link/embed/refresh options for placing MathML as for placing text or images.
It would be nice to have equations and text flow "inline" within a single frame (or sequence of linked frames), but I could get my work done with separate equation and text frames, especially if the equation frames (like image frames) offered the standard text wrap settings when placed over a text frame. [Added in edit] And, of course, it should be possible to pin an equation frame to a text location so that it will follow the text flow, just as image frames can.

@Joy BoyThe place to start is with your chosen publishing company's requirements for the cover.  The precise dimensions will obviously depend on the book size (including page count), so you might get an updated cover requirement after submitting the manuscript.  You will also need to know the ICC color profile the publisher expects, and whether you need to provide art for one side or two sides.
When you have that information, you can set up a document in Publisher or Designer with the required dimensions, color model and ICC profile.  It is simplest if the publisher gives you a one-rectangle layout that encompasses the entire cover.  If the cover is actually a dust jacket, that would include the folds over the boards.  It is much messier in the Publisher to attempt to work with a front/spine/back or frontfold/front/spine/back/backfold layout, although you can do that fairly easily in Designer using artboards for the three (or five) portions of the layout.
So, you are going through the process backward.  The place to start is with the publishing companies you're interested in.  Do not watch some random Youtube tutorial and then try to figure out which publishers those instructions will apply to.  Get specifications/requirements from the publisher, then set up a matching document in Publisher or Designer.  Export your document in exactly the format the publisher calls for.  If they want a particular PDF revision level, export with that option.  If they want all text converted curves, make sure you export it that way.  Etc.

While using the 2.1 betas with cross references, I found myself adopting the routine of updating all cross references, updating the index, saving, and closing the file. If I'd inserted the TOC already I'd do that, too. I will write a script to automate this when scripting is available, but perhaps it might be nice to have a menu command to update cross references, TOCs, and the index at the same time for those who don't use scripts? These three things always need to be manually updated and it would be convenient to have a single command to update them, while still retaining the ability to update them independently.
Thanks

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

Cross-references is the feature I have been waiting for.

Will it be possible to set up cross-reference formats, so that you can have a cross reference that also generates prefix, infix and postfix text? In other words, can you create a cross reference that looks like this:
See Section 3.2 Task-Switching Penalties on page 47.
...or, are the references limited to just page numbers?
Will it be possible to automatically format cross-references differently depending on output format? For example:
PDF for print: See Section 3.2 Task-Switching Penalties on page 47.
eBook/HTML: See 3.2 Task-Switching Penalties.
 

Speaking from experience with scripting CorelDRAW, this is likely to come back and bite us at some point in the future, namely when scripting is added.  Reasoning:  It's not uncommon to script operations on groups selected by name or by Z-position in the layer stack.  If you can't create a group with exactly one object, then you can't apply the same script that you would normally apply to a group.  In some cases, the user could set things up with a layer instead of a group (there is no requirement to have more than one object in a layer), but this is not always possible, especially when scripting a serious of operations that may move and/or create objects between layers.

+10 As a heavy user of object styles in CorelDRAW, it's bewildering that object styles don't behave like text styles with regard to property changes on the style propagating to the objects assigned the style.

https://affinity.help/publisher2/English.lproj/index.html?page=pages/Text/specialCharacters.html?title=Special characters and glyphs
The Unicode value for an Em Space is U+2003, not U+2023 which is a triangular bullet.
The Unicode value for an En Space is U+2002, not U+2020 which is a dagger.
These typos are present in all translations that I checked.

I can confirm this behavior. I have run into this issue before, and I don’t know to solve it other than to recreate the problem style.
I don’t believe this is accurate: [No Change] is a distinct setting from auto. [No Change] says do whatever the parent style says to do, while setting Auto would override the parent style to revert to automatic behavior. So if the parent style has a leading override of 12pt, and in the child style you have set some different leading override, it is impossible redefine the child style to follow the parent style. You can only explicitly define the child style to the same value as the parent style, but of course, if you later change your mind on the parent, you would also have to change the same value in the child. Apparently for this one setting, if you ever make a child style go its own direction, you can never revert to inherit the value from the parent.
And this is not consistent with other options. For example, kerning and tracking in the same pane both have auto as a setting, but in those cases, you can revert to [No Change] and expect it to be saved.

I just noticed that in v2 we can now load any mask into the Refine mode via Layers panel context menu, including the "on-the-fly" adjustment and filter masks. Then it can be edited as any other Refine selection and applied directly back to the mask it came from.
In v1, the Refine context menu command exists only for mask layers that are actually masking a layer. But you can always load a mask as a selection, edit it via Refine as an overlay, save as new mask and delete/disable to old mask.

Hi,
Unused styles may be (i) unwanted or (ii) not yet used.
In Affinity Publisher v2, it would be preferable to have a command that allows to select styles in the panel list that are not used rather than deleting them directly. Direct deletion does not allow to know exactly what we are deleting.
Please +1 if you like the idea 😉.
Thank you,
Loïc

Draw the shape with the Pen tool in Polygon Mode, close the shape then Layer - Convert to Text Frame. You can adjust the nodes of the text frame using Node Tool.

I'm not currently certain which is correct, the helpfile seems to indicate these should be present (and personally I would expect them to be) however from my testing it doesn't appear as though these options are available in the app, though it may be the helpfile which is wrong.
I'll be logging this with our developers now and I will be sure to update this thread, with any further information I am provided 

Sun2Son, OldBruce is correct, we can only guess unless we have the document to examine.  My guess is that you inadvertently rescaled one of several linked text frames using the handle at the far bottom right corner, in an attempt to resize it.  Rescaling a text frame causes all its contents, including text, to be rescaled (after all the character and paragraph style properties are applied.)  AFAIK there is no way to exactly reset the scaling on a text frame, but it is simple enough to delete the accidently rescaled text frame, create a new one with the proper size (leaving the rescale handle strictly untouched) and link it into the other frames so the text reflows through all the frames.

From another user, try:
Select the Text Frame (not the text within it). Click Revert Defaults button (or Edit > Defaults > Revert).

So we have a recipe and a potential fix for this already. As I understand the next major beta will resolve this issue. If you still encounter it in that beta please tag me and I'll get your files to investigate further.
Apologies for the inconvenience, it is a bit of a hard bug to workaround.

Thanks I'll get that sorted 

Give me a dropbox link and I will be happy to supply my four chapter .afpubs and the .afbook.

Give me a dropbox link and I will be happy to supply my four chapter .afpubs and the .afbook.

I will get this thread addressed again next week, sorry @sfriedberg

Others can correct me if / where I'm wrong...
MSI (unsandboxed) is one of the standard Windows installers as you've used in the past. They generally (but are not required to) put their files under C:\Program Files (for 64 bit apps) or C:\Program Files (x86) (for 32-bit apps). "MSI" refers to Microsoft Installer and the file is actually a database that the installer itself uses to install the app in question. If the file extension is EXE, that's just a standard executable file which wraps up the MSI and is sometimes called a bootstrapper as it assists with install options and compatibility. Both MSI and EXE use the Microsoft Installer services - One triggers it from the "document" side, the other from the "executable" side. This has been the standard means for installing Windows programs for years.
MSIX (sandboxed) is the installer for an application that's packaged as a sandboxed application. "MSIX" refers to Microsoft Installer Extended" (I think). These programs install under C:\Program Files\WindowsApps and have much more stringent security applied to them by default.
In both MSI and MSIX cases the underlying application files that are installed are the same, it's just a difference in how they're "delivered" to your computer, where they're installed and other implications of the difference of install / operation methods.
Pros / Cons (I'm sure there are more and there will be debate on whether they're Pros or Cons)
MSI Pros - It's the de facto standard for installers, is well-known, well-understood and reasonably safe assumptions can be made about the installation (from a technical viewpoint). Third-party interactions are much easier due to those assumptions generally being correct. This last one is primarily what has driven the appearance of the Affinity 2 MSIs.
  MSI Cons - Application security is up to the application itself for the most part, there's no default (i.e., OS-level) update mechanism so the app/user has to check for updates. Only one MSI can run at any one time, and may require multiple reboots. Installing one MSI sometimes breaks another, though not if they are well written.
  MSIX Pros - They're automatically updated with much smaller patches, they're in a more secure (i.e., harder to access) location, they're all consistently installed (which may be a pro or con). Patches can be installed in parallel.
  MSIX Cons - Third party (app) interop is often more difficult due to file inaccessibility because of the MS store security model. It's sometimes difficult to even access (i.e., view) the installed program's file structure due to the security of higher-level "parent" directories (sandboxing). You're subject to Microsoft's or the app vendor's whims when it comes to updates (pro or con depending on your viewpoint and / or needs). There may be more -- I've probably forgotten something obvious.
Executive Summary -- By packaging the Affinity apps as MSIX (store) apps, third party app interaction was broken in many cases. Serif decided to offer the standard MSI installers as an option for those who wished to use them since they tend to be more interop-compatible with other applications. Same app either way - It's just how it's installed.