mwdiers

No, I had tried that already, and it made no difference. On restart the shortcut was back. On macOS, nothing is hardwired. All shortcuts can be changed or removed in System Preferences, and any system shortcut can be overridden at the app level. On macOS, Cmd-M is the default system shortcut to minimize windows, but by default, Affinity apps override that to add a Curve Adjustment layer. That is why they added Cmd-Opt-M as the default to minimize the Affinity app windows. By default, Cmd-Opt-M is nothing at the OS level.

I was able to work around this, but figured it should be reported. This happened in Publisher 2.6.3, but I assume the same thing will happen in the other apps. When I was trying to use the Cmd-Opt-M shortcut for Insert Em Space, I discovered this was used by Minimize window. I was unable to remove the Minimize shortcut directly. When I cleared the Minimize shortcut, and then switched to add it to Insert Em Space, I got the exclamation point saying it was already assigned to Minimize. When I went back to the Window section, the shortcut had returned. I also tried clearing the shortcut first, closing Settings, then opening it again, but the shortcut immediately comes back. The workaround was to assign Minimize to some other unused shortcut first, such as Ctrl-Cmd-Opt-M, then assign Cmd-Opt-M to Insert Em Space, and then remove the Ctrl-Cmd-Opt-M shortcut from Minimize. That truly cleared it and it did not come back.

Well, at minimum, it will be nice to have menus that mirror those on macOS.

Just an update. This is still happening in macOS 26 b3.

Example of the crash. Publisher Crash Report.txt

I am on the Tahoe Developer Beta 2. I understand that I use Affinity software on a macOS beta at my own risk. I am only reporting this in case it is a larger issue with Tahoe that will need to be addressed by the devs. When I am applying a style to a paragraph near the end of a frame, and the newly applied style has “keep with” or widow/orphan options that cause the paragraph to break differently, or in particular, to cause the paragraph to appear entirely in the next frame, Publisher will crash. The crash report always has this cause, thread 0: “(Data Abort) byte read Translation fault.” If I instead set the cursor in a portion of the same paragraph that flows into the following frame, and apply the style there, no crash occurs. I have been able to avoid the crash in this manner. The next time it happens, I will post a full crash report.

Ugg. That’s a terrible workaround. So much for cascading styles. Also, it doesn’t prevent a character style from being applied, but that happens less often at least.

I have a document where I add sidenotes. These sidenotes are unnumbered. I have a note body style specified in document-wide sidenote settings. When I create a new sidenote, the correct note body style gets applied to the sidenote. However, It also picks up additional formatting from whatever I was just typing in the main text. For example: I have a paragraph to which I add a superscript “A”. I click to a different paragraph and insert a sidenote, and start typing. The inserted sidenote has the correct style, but also a superscript override. Every time I add a sidenote, I have to make sure I click the “Reapply Text Styles” button in the Text Styles pallet to make sure I am not getting additional formatting from the last thing I typed. I also need to make sure no character styles carried over, because those also will get inappropriately applied to the sidenote. I’m going to guess the same thing happens with footnotes.

I just ran into this on 2.6.0. I exercise rigid style discipline, using inheritance everywhere. Everything descends from [Basic Paragraph]. When [Basic Paragraph] is set to a variable font, it is not possible to change the weight of descendant styles. The weight is simply ignored. It is still possible to override text with a particular weight, but that's not tenable when laying out a book.

I have discovered this in Sidenotes in particular. When I set the Document-Wide Initial Advance setting for a document in Publisher, the setting is not saved, and reverts to Leading after the document is re-opened. Steps to reproduce: Create a sidenote. While editing the sidenote, change Document-Wide Initial Advance to Ascent. Save the document. Quit Publisher. Restart Publisher, and reload the document. Add a new sidenote. Initial Advance will have reverted to Leading. Note that the previous notes do not visually change their Initial Advance. However, when entering those notes again, the Document Wide as well as Custom settings will show "Leading" rather than "Ascent" even though the initial advance of that note visibly is still "Ascent." This is particularly noticeable when a sidenote appears at the top of the page margin. Any new sidenotes that are created will have an Initial Advance set to Leading and appear so visually until the setting is changed back to Ascent. It is also somewhat annoying that it is not possible to change Document-wide notes settings unless the text cursor is currently in a note of that type.

I can confirm that it also fixed the disappearing sidenotes in my case.

On 2.6.0 beta, that is not the case. It is happening on text frames originating from master pages.

In certain circumstances, when I am editing a Publisher document, and click into a text frame to begin typing, if I hit the backspace key, the text frame itself is deleted. This seems to happen when the Text Frame Tool is selected, and I give some other part of the UI focus, and from there sinlgle-click into a text frame. I can consistently reproduce this behavior if I: Begin with the Text Frame Tool selected. Click into a field in the Document Information panel. Single-click into the text frame (and thus getting a blinking cursor which is accepting text). Press Backspace. Note that even if I start typing between steps 3 and 4, and thereafter hit Backspace, the text frame is still deleted. This does not appear to happen if I begin with the Move Tool, and from there double-click into a text frame to begin editing. It does not happen when the Text Frame Tool is selected, if I double-click into the text frame rather than only single-clicking. It also does not happen if I single-click into the text frame, start typing, single click in the text frame again to mover the cursor, and hit backspace.

The "Keep with next" option ignores any lines beyond the next paragraph. In the scenario where the next paragraph only has 1 line, and "Keep with next" is set to 2 or more lines, I would expect the paragraph to move to the next frame, keeping it with the next two paragraphs.

It's fixed! 2.6.0 beta (3027).