Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender

Recent Profile Visitors

673 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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!
  5. Can the Affinity team elaborate more on the decision to remove the "Save/Save As" menu items from within the document?
  6. "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.
  7. 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!
  8. 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
  9. 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
  10. 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.
  11. 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.
  12. @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.
  13. @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
  14. 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
  15. 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.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.