- S -

Did you try installing using the Affinity .EXE installer, rather than the .MSIX installer?

As the above poster mentioned, it's likely because [Document > Transparent Background] is enabled. You can create your own custom TIFF export preset that uses a solid white Matte, which will always export TIFF images with no transparency.

If it's not possible to program the pen buttons and there isn't a way to use some sort of on-screen Surface menu, then I guess using an on-screen keyboard may work better than trying to use the physical keyboard (or a Bluetooth keyboard). There are two different on-screen keyboards built into Windows. 1) The "Touch keyboard", that is activated in Tablet mode; or [Right-click Windows Taskbar > Show Touch Keyboard button]. 2) The "On-screen keyboard", that can be found by searching the Windows Start menu. While the "Touch keyboard" does have various different layout options, the "On-screen keyboard" should resize to a smaller size, so it doesn't take up as much screen space. They are both floating. If you're unable to find a better solution than using an on-screen keyboard, then I guess you could give feedback to Microsoft, as it seems like a bit of an omission for a tablet device. Alternatively, you may get more success trying to get Microsoft to include some sort of Modifier Keys floating menu feature in Microsoft PowerToys. One of the developers for PowerToys was recently asking for PowerToys suggestions on Mastodon. Lastly, you could give feedback in the Feedback section here for Serif to consider including on-screen Modifier Key buttons somewhere – such as in the Affinity Tools/Toolbar/Panel – like Adobe's Modifier Keys palette.

Windows clipboard is more complex than you would think it would be. I wouldn't read too much into copying from XnViewMP, as it may be copying and pasting clipboard data differently. I'm thinking the underlying issue is due to some Windows clipboard oddity that hasn't been accounted for in a change made between Affinity Photo 2.0.0 and 2.0.3. Looking at those three extra pixels in the bottom-left corner, it seems as though that's the start of the bitmap data and there's some bytes of data there that shouldn't be, which is causing it to shift right by three pixels (drawing from left-to-right, bottom-to-top). Hence why the right side ends up wrapping to the left. Edit: I posted an additional video in a post here.

It's likely due to the following setting: [Edit > Preferences > Performance > View Quality] Change the setting from "Nearest Neighbour" to "Bilinear (Best Quality)".

When this happened, did you directly paste the screenshot into XnViewMP first, or did you try pasting it into Affinity Photo first and then pasting it into XnViewMP? I think Affinity Photo 2 is doing something with the clipboard. Try reproducing it without having Affinity Photo open and just pasting directly into XnViewMP.

If the Pixel tool is selected and then a brush is selected that has Wet Edges set to On, the Pixel tool inherits the Wet Edges setting. When then changed to another brush – such as a basic round brush – the Wet Edges remain on as the brush is set to "Don't set wet edges" by default (which is technically "normal" operation). With the basic round brush now selected, when using the Alternative mode (holding the Ctrl key on the keyboard) to temporarily use the Erase mode, the wet edges are applied and will not erase as expected. There is no indication that Wet Edges is set, as there there is no Wet Edges Context toolbar item for the Pixel tool. The only way to remove Wet Edges is to use a brush that has Wet Edges set to Off (not just set to "Don't set wet edges"). This means the user either using the "More" button in the Context toolbar or creating a new square brush and setting the Wet Edges to "Set wet edges off". This will then remove the Wet Edges setting from the Pixel tool and the Alternative mode will work as expected. This appears to be an issue introduced in Affinity Photo V2. In Affinity Photo 1.10.6.1665, both the normal Pixel tool mode and the Alternative Pixel tool mode ignore inherited Wet Edges – and the Alt mode (Erase) works as expected. Steps to reproduce: Square Brush.mp4 ---- Affinity Photo 2.0.4.1701 (EXE version, but I also saw it when I had the MSIX version installed) Windows 10 22H2 (19045.2486)

@jbikeler As another poster mentioned, this is caused due to the Pixel tool inheriting the "Wet Edges" setting from another brush. The Pixel tool just doesn't show the "Wet Edges" setting in the Context Toolbar at the top. Selecting a basic round brush in Affinity Photo 2 also won't reset it. Therefore, I would create a new square brush like "NotMyFault" mentioned and use this to reset the Pixel tool. If you keep this newly created brush in your Brushes panel, you can select the brush again in the future to reset the Pixel tool if the issue occurs again. See below video. Square Brush.mp4

Yeah, that's exactly the same issue (although I only have one monitor). Even down to the 3 pixels on the left of your screenshot being shifted up by one pixel.

I always have "Force Pixel Alignment" set to On and "Move by Whole Pixels" set to Off. However, the issue occurs whether they are enabled or not. I've just double-checked and the issue is definitely due to changes made in Affinity Photo 2.0.3.1688. I uninstalled 2.0.3.1688 and went back to 2.0.0.1640 and the issue does not occur in 2.0.0.1640. When I installed 2.0.3.1688 again, the issue started again straight away. Video 1 (Copying screen to clipboard using the keyboard Printscreen button): – Comparing 2.0.3 (working incorrectly) to 2.0.0 (working correctly) 01 Printscreen.mp4 Video 2 (Copying locally saved file to clipboard from the Windows Photo app): – There is a slightly different behaviour when copying from the Windows Photos app, rather than using printscreen. Copying and pasting this way only appears to affect [File > New From Clipboard], not [File > New…] like in video 1 above. 02 Photos app.mp4 Affinity Photo 2 system requirements list "Windows 10 May 2020 Update (2004, 20H1, build 19041) or later", so I'm not sure why you don't have any Windows 10 test machines.

Yeah, I've experienced the same problem in a previous post. Amazon CloudFront (the forum CDN) will throw an error when trying to submit a post here that contains either the loopback IPv4 address in the text (127.0.0‍.1), or the word local‍host (no spaces) in the text. You need to either use a screenshot, break the words apart, or insert a "Zero Width Joiner" in the middle of the words local‍host or 127.0.0‍.1.

Walt was referring to the below post, where the poster was using a third-party firewall (ZoneAlarm firewall), which is blocking loopback.

If you completely block V2 it won't run at all. It must at least be able to use local networking to connect to other apps on the same machine. Windows Firewall doesn't block loopback (localh‍‍ost) communication, therefore the Affinity applications will still work, even if blocked by Windows Firewall. Other third-party firewalls however can cause issues if they block loopback (or the user blocks loopback). Therefore, people can block Affinity applications with Windows Firewall, however there will be a few caveats: 1) Affinity programs require outbound internet access the first time they're run after installation – as users need to enter their Affinity ID and password to perform a one-time licence check with Affinity servers and activate the licence. 2) Other functionality that requires outbound connections – such as the Affinity Stock panel – obviously won't work if outbound connections are blocked. 3) If using the MSIX installer (rather than the upcoming MSI/EXE installer), the Affinity application paths have the version number in the path. This means the firewall rule will only be relevant for that exact version (I.E. 2.0.3.1688), as Windows Firewall doesn't allow wildcards in paths. Windows Firewall does allow creating rules using an App Package name – instead of a direct file path – which gets around this issue and is how firewall rules are created for Microsoft's own Store apps, however this method doesn't work with Affinity applications (see my previous post HERE). I'm not entirely sure why there isn't an option to disable automatic update checking from the UI, particularly as MacOS has the option. Some people don't like applications having internet access unless strictly necessary, however there is another practical reason why some people may want to disable automatic update checking in professional software – consistency. When doing a large project (for example scanning and restoring a batch of a few thousand photos), a lot of testing and checking will be carried out before starting the run because it's a long, tedious, time consuming task and having to go back and correct any problems is no fun and extremely costly in terms of time. It essentially becomes a production line and the last thing needed is for any of the programs to update midway through the project and introduce any bugs, inconsistencies or unexpected behaviour. Some projects may last weeks or months, so it would be useful to be able to turn off automatic update checking in these circumstances.

Using "New From Clipboard" pastes a captured screenshot incorrectly in Affinity Photo 2.0.3. In the below example, when copying & pasting a full-screen Command Prompt window, part of the scrollbar on the right-hand side of the image gets shifted to the left-hand side when pasted (3 pixels). The left bit also moves up 1 pixel (so the bottom-left corner ends up with 3×1 pixel transparent area). Screenshot A: Steps to reproduce: 1) Take a full-screen screenshot by pressing the "Print Screen" (PrtScn) button on the keyboard. It doesn't make a difference what's screen captured – I chose a Command Prompt window because a dark window with a light scrollbar makes the issue clearer to see. 2) Then either: a) Go to [File > New From Clipboard] b) Or go to [File > New > FHD 1080p] and then [Edit > Paste] 3) View the left and right edges of the pasted screenshot. The image has shifted when pasting. When pasting the captured screenshot into Microsoft Paint, the pasted image is OK and not shifted. Therefore, Windows seems to be copying it to clipboard correctly and Microsoft Paint seems to be pasting it from clipboard correctly. When using the [Windows Key + PrtScn] shortcut keys to save the screenshot directly to %UserProfile%\Pictures\Screenshots as a PNG file, the image is also OK and not shifted. This issue occurs in Affinity Photo 2.0.3.1688. I'm pretty certain it didn't occur in Affinity Photo 2.0.0.1640. Initially I was thinking that this could be a Windows bug, however as it works correctly in Microsoft Paint, I think there is something else going on here. Animation showing shifted edges: Pasted Edges.mp4 Example files: Example files.zip ----- Windows 10 22H2 (19045.2364) 1920×1080 monitor. Windows display scaling set to "100% (recommended)"

I'm not sure whether there's a better way for the Affinity programs to communicate with each other as I'm not a developer. However, it looks like Affinity V2 programs use IPv4 loopback to talk to each other via a local proxy. I haven't used ZoneAlarm firewall, however it should be possible to create allow rules in ZoneAlarm. See screenshot – as CloudFront throws an error when I try to submit a post here containing local IP addresses in the text.

As per THIS POST, the issue appears to occur when using an Affinity Designer document that has artboards. Steps to reproduce: Artboard.mp4 File: untitled.afphoto

Someone else posted a similar issue at the link below a few weeks ago, however I was unable to reproduce it myself. The person in the other post has a similar layer structure to you (a pixel layer, two groups deep). I would make a copy of the document, name it "Test" so it doesn't get mixed up with the original and then start going through and deleting unnecessary groups and layers to see if you can narrow it down a bit more. Once you've narrowed it down, you may be able to figure out whether it's a bug or whether something specific is causing it. Alternatively, it may help if you could upload the file here to see if other people can reproduce the issue with your particular file.

Your "white" is set to 0% opacity in the Colour panel. If you change it to 100% opacity, it will then show as 55% grey (or whatever the slider is set to).

Even earlier than that, I mentioned it in January 2017 (a few weeks after it was released on Windows) in the below post about the "Date Taken" field. The problem is, although Affinity Photo adds the software name to the file metadata, it adds it to the following metadata tag. [XMP-xmpMM] HistorySoftwareAgent While there is nothing wrong with adding it to XMP Media Management metadata, it's not much use if other software (DAM, Windows File Explorer, etc.) is looking for that metadata in the below metadata tag instead and therefore doesn't read it. [IFD0] Software Screenshot:

Oh no…

It's because the freehand selection has antialiasing and/or feather applied. Then when you move the newly pasted layer with the Move tool, you still have the selection enabled. This means what you're moving is not the newly pasted layer as a whole, but the (still) selected part of the newly pasted layer (which still has antialiasing and/or feather applied). Therefore, you need to go to [Select > Deselect] (CMD/CTRL + D) to deselect the active selection before moving the layer.

Include commas and quotation marks in your passwords to screw with an attacker's CSV files.

Using the Move tool on a selection (over a blank pixel layer), or using the Transform panel on a selection will make the edges imprecise as the selection works like a pixel layer, rather than a vector shape. The edges do not stay hard due to resampling. Therefore, using the Move tool in this way in Affinity Photo is not the same as using the "Transform Selection" feature in other image editors – which do keep the edges hard. You will end up with transparency around the edges, rather than it being fully opaque. Although I usually use vector tools, it's "clunky" because it's necessary to switch the vector tools between 0% and 100% opacity so you can see what you're selecting easier. Whereas with the Marquee tools they are already transparent, as that's what they are supposed to be used for. If an end user would rather use the Marquee tools, the Marquee tools should let them work that way without needing to use the vector tools. However, being unable to use the Spacebar to move the selection during creation makes this more difficult. I'm well aware there are different methods of doing different things, but this is a topic in the "Feedback" section of the forum where users can give Serif feedback on their software. In this case, give feedback on improvements to the Marquee tools so that they can be more useful. Making improvements to the Marquee tools so that modifier keys like the Spacebar or CTRL can be used during selection shouldn't be a contested issue, especially as Affinity Photo doesn't have a true "Transform Selection" feature. Selection tools can be used for many things, from adding and subtracting from existing masks, to quickly knocking out eyes or wheels for example. It's difficult to drag a marquee perfectly without being able to position it with the Spacebar. It can even be done in a web browser… Selection.mp4

Unfortunately, that's correct. The Rectangular Marquee tool and Elliptical Marquee tool are still very primitive. If you want to use the Spacebar, or resize the marquee after initial draw without making the edges soft, you will need to use the Rectangle tool and Ellipse tool (vector shape tools) instead and then create a selection from them – which is obviously a bit of a clunky work-a-round.

Unless you're resizing the selection, that sounds like a slightly different issue. With the Flood Select tool issue, does it occur regardless of whether the Antialias setting in the context toolbar along the top is enabled or disabled? Or does it only occur when Antialias is enabled? Capture.mp4