MikeTO

The picture frame is on the master page so you can't cut it on a page based on it unless you first choose Layer > Master Page > Edit Detached.

The vertical offset is a glitch in Light mode - the text is correctly aligned vertically if you switch to Dark mode. The selection rectangle is also odd for this dialog in Light mode. It's not a problem with all dialogs, for example, Insert Anchor doesn't have this problem.

I *love* the Context bar, it's so clean and compact compared to the traditional control panel that InDesign uses. That being said, there's a change that Serif could make which would save some horizontal space. There are three a's and three pilcrows (para symbols) when editing text which looks cluttered - and my OCD can't help noticing that they're not vertically aligned. The first is a non-clickable label to identify the style list to its right while the others are Update Character/Paragraph Style and Character/Paragraph (show studio panel). I suggest removing the label and moving Character/Paragraph to the left of each list, using the control itself to identify the list. The update controls could remain where they are or for a super compact layout they could be removed and "Update Style" could be added to the top or bottom of the style list itself.

I think Peter has raised a fair point. Apps can show the values of the first of multiple selected characters, or paragraphs, or objects or they can show mixed states. But Affinity does some of both. For example in the Character studio panel, Affinity shows mixed states for font, weight, size, and char style but not for colour or background colour (which are in the same part of the panel) or for anything else below. Likewise in the Paragraph studio panel, Affinity shows mixed states for justification and para style but not for anything else. IMO, Affinity is showing mixed states for the most important items but there's more work to do here someday. There is one very minor bug - in this screenshot you can see that Context Bar is showing left justification while the Paragraph studio is showing mixed states. All of the other controls that show mixed states in a studio panel also show mixed states in the Context Bar so this was likely just an oversight.

I think they were asking to add the two words together, so that each of them on their own would still be flagged as a spelling error but that together the two words would be approved. I don't think there's a way to do this. You definitely can't do it via the user interface since only single words are flagged. Adding two words manually to the dictionary file on macOS with a space between them or quotation marks around them won't work either. AppleSpell is based on HunSpell and I didn't see anything in the docs on this when I did a quick scan, but HunSpell is a beast with tons of options and I didn't spend that much time looking at it so perhaps somebody with more experience with it could chime in.

In the meantime, you might consider changing your shortcut for Paste Without Formatting to something simple like Cmd+Shift+V.

That's part of the problem but it still exists with a docked studio panel. However, I've confirmed the floating part of your bug. If Find and Replace is floating and closed, Text>Find or Cmd+F sets focus to the Find field If Find and Replace is floating and open, Text>Find or Cmd+F does nothing If Find and Replace is docked, Text>Find or Cmd+F usually sets focus to the Find field but not always With regard to the docked version of this bug, few bugs are truly intermittent so there is a certain sequence of steps that must be followed to trigger it. The obvious candidates are whether the studio panel is visible or not, which field in the panel last had focus, whether a different studio last had focus, which tool is selected, etc., but I've tried all of those and haven't been able to duplicate it on demand. I'll keep an eye out for the next time it happens and see if I can then come up with repeatable steps. Once we've figured this out we can move this to the Report a Bug forum.

Yes, it is confusing. I suspect it's because Affinity is relying on macOS' ability to add and remove windows to the Windows menu automatically and there's only one window open. Affinity would need to manage the menu manually like Adobe has done. It's been discussed before. E.g.,

I'm not seeing that here. The only apps I have problems with on my M1 Pro are Apple Preview and Apple Notes, both of which I can lock up for up to a minute. I imagine Apple would consider my use of these apps to be edge cases but they really weren't designed for scale. I've reported the issues to Apple.

I've seen this, too, but isn't the trigger more complicated than just the studio being open and no text being selected? I tried it now for five minutes and I couldn't replicate the issue on demand, the Find field was always given focus. I know it happens but I don't know what triggers it. On a related note, I have a similar issue with the Insert Index Mark dialog. The first field is Topic and it should always have focus when the dialog opens but sometimes Parent Topic is given focus. Again, I don't recall the trigger. I'll keep my eye on both of these to come up with repeatable test cases.

Thanks Dan. I believe you're saying that Publisher doesn't have a sense of current attributes as I assumed and instead the default attributes are changed when attributes are set and nothing is selected. Got it, but I think #3 and #6 below are confusing. Move or Text Frame tools, no frame selected: Setting attributes changes the default attributes for future frames. Perfect. Move Tool, frame selected: Setting attributes changes the default attributes of the frame and the attributes of any text in it but not the defaults for future frames (with the caveat of colour which you've said is a bug). Perfect. Text Frame tool, cursor in an empty frame: Setting attributes changes the attributes at the insertion point, the default attributes for this frame, and the defaults for future frames. I understand why you're doing this (no text is selected) but I think it's confusing because the frame sure looks selected with its size handles. But it's consistent with the design decision. Text Frame tool, cursor at end of a word: Setting attributes changes the attributes at the insertion point and the default attributes for future frames. As you'd expect, the existing frame's default attributes are not changed, just the temporary attributes at the insertion point which will disappear if you don't type anything before changing tools. This is consistent with the above. Text Frame tool, some or all text selected: Setting attributes changes the attributes of the selected text but not the default attributes for future frames. This is consistent with the design decision. Text Frame tool, cursor in middle of a word: Setting attributes changes the attributes of the word but not the default attributes for future frames. I believe users may find this confusing because nothing is selected so shouldn't Publisher be changing the defaults like in #4? Although it's common for apps to apply character attributes to the current word even if it's not selected, the text is not selected so Publisher should be changing defaults. i.e., If I position the insertion point like this "This is a test|" I'm changing defaults but if I move it one character to the left "This is a tes|t" I'm not changing defaults. Thanks! BTW, this isn't important to me, I was just banging on the beta.

@CLC Fixed and I added your additional machine. I assumed it was the 10-core CPU based on the scores.

@v_kyr I believe they downloaded it from the Affinity website, this is a Safari error. Hi, I think you should delete it and download it again from https://store.serif.com/en-gb/update/macos/photo/1/. Here are some generic instructions for this type of Mac error. https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/ Good luck!

It's easy to do with a single text frame: Create a tab stop at whatever value you want for the start of the second "column". Change Left Indent to the same value. This will automatically change the First Line Indent to the same value. Change First Line Indent to 0. That's it. It's more work if you want the left "column" to be right aligned but that's possible, too.

Oops, fixed. Thanks.

Which Intel processor do you have? It's too bad the benchmarking tool couldn't gather that automatically. Thanks.

If you use Separated mode you'll always see the title at the top of the window. But if you prefer to use it with Separated mode off which I do, too, just keep the Toolbar open and you'll see the file name in the "Status" control as shown here.

@mykee

If you keep the History studio panel open you will have one click undo/redo.

Could you copy one of those text frames that is giving you trouble to a blank document and upload it here so we can take a look at it? Thanks.

I think they meant paragraph style when they wrote tag and in step 1 where they wrote "uncheck no break" they meant "check no break". No Break is a character attribute under Positioning and Transform so you have to make it part of a paragraph style or apply it directly to the entire paragraph. Doing this will force that paragraph to span across the text frame because it refuses to break. The workaround works but of course it requires changes if you add or remove text after the spanned paragraph and before the next frame.

Correct, text frames. And saving defaults has no impact. I think you'll be able to duplicate the issue with these steps and I've included a screen recording at the end to show one of the scenarios. Applying existing styles and attributes to a new text frame is easy, you just pick up the attributes from the last insertion point or from the last character of a selected text block. So if the new frame has incorrect attributes it's almost certainly an issue with how the tags are applied and stored in the previous text frame and that's a real bug that's more important than whatever attributes are applied to new frames. With that in mind, I came up with these some test scenarios: Create a new doc and draw a text frame. If you're using Publisher's defaults, it will be Arial Regular, 12pt, Black. Type "Test" and choose Select All In this exact order, set: Text colour to Red - the colour values aren't important but pick a colour that is obviously not black Text size to 30pt - the value isn't important, just different enough to be obvious Font and Weight to Times Bold - again, not important, I picked a serif to be obvious Draw a new frame and type "Test". It will be Arial Regular (wrong), 12pt (wrong), Red. Create a second doc and draw a text frame. Type "Test" and choose Select All again. In this exact order, set: Font and Weight to Times Bold Text size to 30pt Text colour to Red Draw a new frame and type "Test". It will be correct, Times Bold, 30pt, Red. I get the same results if I apply Size before Font. The second bug is that paragraph styles aren't applied in the same manner if text is selected which is a red flag. Create a new doc and draw a text frame. If you're using Publisher's defaults, it will be No Style + Arial Regular, 12pt, Left. Type "Test" and with the insertion point still to the right of "Test", set para style to Heading 1. I'm using Publisher's defaults so it will become Arial Bold, 20pt, Black, Centre. We'll ignore the other attributes associated with Heading 1 to keep this simple. Draw a new frame and type "Test". It will be Heading 1 + Arial Regular (wrong), 12pt (wrong), Centre. Create a second doc and draw a text frame. Type "Test" but this time choose Select All. You could also double click to select the word, triple click to select the para, or manually select "es" in "Test", the results would be the same. You could also type two paragraphs and select the latter part of para 1 and the first part of para 2 - the important thing is to select text. Set para style to Heading 1. Draw a new frame and type "Test". It will be No Style (wrong) + Arial Regular (wrong), 12pt (wrong), Left (wrong) + a long list of other attributes that were part of Heading 1. You can combine the two issues for more unexpected results: Create a new doc and draw a text frame. Type "Test" and with the insertion point still to the right of "Test", set para style to Heading 1. You'll get the same results if you choose Heading 1 before typing "Test". Choose Select All. In this exact order set: Font and Weight to Times Bold Text size to 30pt Text colour to Red Draw a new frame and type "Test". It will be correct. Create a new doc and draw a text frame. Type "Test" and choose Select All. Set para style to Heading 1. In this exact order set: Font and Weight to Times Bold Text size to 30pt Text colour to Red Draw a new frame and type "Test". It will be No Style (wrong) + Times Bold, 30pt, Red, Left (wrong) With the insertion point still to the right of "Test" in that new frame, set para style to Bullet 1. This wipes out any character overrides. Draw a new frame and type "Test". It will be Bullet 1 + Times Bold (wrong), 30pt (wrong), Red (wrong) Here's a screen recording of steps 5 to 10 of the last scenario: Screen Recording 2022-02-17 at 1.50.29 PM.mov

Could you add a bit more to the note for the devs? In another thread this week I described a similar issue with colour. If I create a text frame, type some text, make it 24 pt, red, and Times, and then start a new text frame, the text I type there will be red but the size and font will be the default. Some layout apps have a concept of current formatting, if you draw a new text frame it inherits the attributes of the last edited text while others always reverts to defaults. It's just inconsistent. Thanks.

Text created with the Artistic Text tool will be scaled when you resize the text object whereas text created with the Frame Text tool won't be scaled when you resize the text object. This makes sense because "frameless" text has to scale to fit the new size otherwise scaling the object would do nothing. As far as I'm aware, you can't convert Artistic Text objects to Frame Text objects in Affinity. But you can copy the text to the clipboard and create a next text frame in the same spot and paste the text into it.

FYI, on macOS with Separated mode off, the tabs do not become very narrow. They get narrower until they're at a small but still useful size and then an overflow menu appears to the right from which you can select a tab. The Window menu can't be used for switching tabs with Separated mode off - there's just a single window listed. On macOS with Separated mode on there aren't any tabs of course but the Window menu will happily show far more than 10 documents.