jeffreydevey

@DWright It appears this issue has resolved itself. I'm not sure what caused it, but everything appears to be working fine now.

In version 2.2 I am having issues assigning a specific brush as an eraser using the eraser side of my Wacom Cintiq pen (Pixel Persona). In previous versions I was able to click on a brush in the brush panel with the eraser side of the pen to assign it to behave as an eraser, but when I do this in 2.2 the eraser side behaves as a brush rather than as an eraser. Currently I am unable to change the eraser tool. Specs: MacOS 12.6, 27" iMac (2019), Wacom Cintiq 24HD, Affinity Designer 2.2.0

Yes, I agree. Saving should be convenient. I've pointed out some additional drawbacks I've encountered with the current method on another thread. For example, I was working in Pixel Persona and had to re-enter it after the document reopened in Design Persona. Then I had to reopen the pixel brush category I was using before exiting the document to save. Then I had to reset the color panel slider mode to my preference, etc. Saving used to take two clicks and a couple of seconds, but now sometimes requires upwards of 10 clicks and the whole process takes close to a minute by the time I reset everything the way it was before exiting the document. If I save my work 5 times per hour I'll end up spending 40 mins. of every work day just saving my work and resetting panels. The current saving system for the iPad is a frustrating mess from my perspective. I hope they get it sorted.

I've just encountered further problems created by the removal of the "Save" command from within the open document menu. After exiting the document to save and reopening the document, the app reverts to Designer Persona regardless of which persona the document was in upon exiting. Any non-default panel options selected prior to exiting also revert to their defaults. Brush categories, color slider preferences, Main View/Split View modes, etc. all have to be manually reset to the user's previous working state after each and every save. Please, PLEASE try to provide a better solution.

Oh, I see. No worries. 🙂 I've experienced the "surprises" you're referring to the hard way. I agree, this was extremely frustrating when it happened to me, but I think there are better solutions if this is the problem Affinity is trying to solve. For example: A popup dialog box upon selecting "Save" from within the open document menu, informing the user their changes may not be synchronized to disk when using that method (with a "More info" link to provide the user with more detail about that issue, and a "Do not show again" checkbox option). Upon closing a Live Doc, including the options "Save changes and close", and "Close without saving", respectively. Additionally, there could be a "Note: Changes saved from within the open document menu may not be synchronized to disk. (More info)" line of dialog. An option in the Interface Preferences to include "Save/Save As" options in the open document menu, again, with a note that "changes saved this way may not be synchronized (More info)", etc. I believe the better solution to the issue is to communicate the issue to the user without hindering a streamlined and efficient workflow.

Can the reasoning behind this change be clarified by the Affinity team? I posted this question on the announcement thread as well, but I'm posting it again here because I'm not sure which is the most appropriate place. Thanks!

Can the Affinity team elaborate more on the decision to remove the "Save/Save As" menu items from within the document?

"Save a Copy" is not ideal and has its own drawbacks. I don't want to fill my storage unnecessarily with dozens of copies of each project, and it is especially cumbersome when the user has to manually rename each copy. I have a feeling this decision was made to solve an issue where iPad files stored in the cloud are not updated when saved from the menu within the open document. However, I'm just assuming this. It would be nice if decisions like this were accompanied by communication from the Affinity team on why the decisions were made. If my assumption about the reason behind this decision is correct, I can suggest better solutions to the problem it was intended to solve. The current solution merely replaces one problem with another for the user.

I see, that makes sense. So it's an issue with the pixel brush not accurately painting the color, regardless of whether the color picker was used to select the color. In any case, I hope they get it sorted out soon. Thanks!

UPDATE: I duplicated the top row of boxes and adjusted the saturation of each box to 50% to see if it had any affect on the results. It appears to be dependent on the luminosity, and independent of hue or saturation settings. color-picker-bug-affinity-designer-2-ipad-ex5.mov

I've attached another example below where I created several vector objects in different colors. The top row has varying hues, but are all 100% saturated with a luminosity setting of 10%. The bottom row maintains the same hue and saturation settings, but the luminosity for each has been set at 50%. As you can see, the problem appears to be isolated to the top row of objects. color-picker-bug-affinity-designer-2-ipad-ex4.mov

The issue seems to present itself more with high-saturation, low-luminosity colors based on my experience so far. Thanks for looking into it. Are you a Serif employee? It's not immediately obvious to me who is a user and who is an employee on this forum.

I am confused by the removal of "Save" and "Save As" from the menu options within the open document. Saving work often should be part of every user's workflow, and having to exit the document to do that is cumbersome. Does Affinity Designer have an autosave feature on the iPad to recover unsaved data in the event of the app crashing? Perhaps the reason behind the decision to move the menu options can be clarified.

@NotMyFault Yes, that is true for the 100% K black and rich black swatches, but I want to make sure the example of the color picker failing to match other non-black colors in Pixel Persona is addressed as part of the issue as well. The black matching issue is only one part.

@NotMyFault The document is CMYK, but the issue persists with other colors as well (attached example 2). I'm using the same document mode and workflow I've carried over from v1, and never experienced the issue with that version. If I assign vector objects the 100% K swatch and the rich black swatch, respectively, then switch to the Pixel Persona and assign the same swatches to my brush, the 100% K swatch appears to match, but the rich black does not (attached example 3). No adjustment layers are in effect in either example, and no "wet edges" or other settings are in effect on the pixel brush that would give me that result. I have gotten the same results with other brushes as well, including the stock round "Basic" brushes. color-picker-bug-affinity-designer-2-ipad-ex2.mov color-picker-bug-affinity-designer-2-ipad-ex3.mov

As the title states, the color picker isn't picking accurate colors when painting in the Pixel Persona. This appears to be a persistent issue, and not isolated to a single session. Screen recording attached as an example. color-picker-bug-affinity-designer-2-ipad.mov

I've experienced this issue a few times as well. What a nightmare, especially the first time it happens and you have no idea what's going on.

First, I'm happy to see continued development on Affinity's suite of products. I hope Affinity is successful in its endeavors to be a viable alternative to Adobe in the professional market. I think the new features in v2 are very welcome, especially the warp tool, as I am amongst the users requesting that feature for quite some time. The changes to the user interface are taking some time for me to get used to, and there are a couple of things about it that I feel could be improved to make it more user-friendly based on my experience with it so far. As several other users have mentioned, the trash can button in the lower left corner was very useful in v1, and I hope to see it make a comeback soon. A long press or three-finger swipe feels much more cumbersome than the direct access to the trash can icon in v1. The color panel always reverts to CMYK sliders, and I feel like it should remember the slider/color wheel settings the user prefers. It's frustrating to have to change this preference manually dozens of times in a session, and makes the user less efficient. There are also a couple of bugs I have become aware of that I will post in the proper channel, but the feedback above relates to functionality I presume was by design.

I'm adding my name to the list of users who miss the trash icon. I've been using the contextual menu for now, but that slows down my workflow. I hope to see it return in the next update.

Never mind. I restarted the program and it is functioning properly now.

I've struggled with this issue in v1 of the app as well. It's incredibly annoying to accidentally click on the scrollbar. When the scrollbar appears for me in v1, it literally covers a portion of the layer visibility checkboxes.

I agree that this was a poor design decision. It makes it extremely difficult to find and select the intended group in the layers panel when all groups appear identical. EDIT: I read other comments saying this can be changed in the preferences.

I prefer the aspect ratio of my selection to not be constrained unless I am holding the "Shift" key. I have adjusted the settings in Preferences (attached image), but my selections are still constrained when resizing with the corner handles.

This issue has come back to bite me again, and I find it extremely frustrating that I can't find an option in Affinity Designer to turn off overprinting on objects using 100% black. Either the option to toggle overprinting on/off doesn't exist, or it's buried in the UI and I can't find it. When pasting artwork assigned as 100% black from Affinity Designer into Illustrator and reassigning colors in Illustrator, overprinting is still applied to the artwork (even if it is no longer black) and has created problems for me when delivering files to the client. The user should have control over whether or not 100% black objects overprint. It's not always desirable!

@walt.farrell That helps a lot, thank you! I don't see any indication in the Color panel that overprinting has been applied (as the screenshot from the Help article would suggest), nor an option to turn it off (which is frustrating), but at least I know what is going on and I can adjust my process accordingly. Thanks again!