Jump to content

ogardiner

Members
  • Content count

    11
  • Joined

  • Last visited

  1. Thanks for your efforts. If there is anything I can do to help, please let me know. The sooner this thing is fixed, the better...
  2. Hmm, I can't confirm that on a Mac. Selecting everything, copying and pasting it into a new document (without artboards) fixes all pixelview issues for me. However, I share your disappointment regarding this bug and how it has been handled. I wish we could do something to expedite a fix... Best, Ole.
  3. Hi guys. Just to keep the ball rolling - this is actually pretty severe. Some additional details that might help: - The bug only affects documents with artboards. Before adding the first artboard, the pixel view is perfect and shows no artifacts across all zoom levels. - The artboard dimension and position seems to have no effect. Artboards with round integer values for position and dimensions are affected as well. - Apparently the problem lies with the artboard boundary, not the artwork or frame lines (see attached gif, you can see that the artwork and blue frame stay put while the artboard boundary jumps) Thanks :) Best, Ole.
  4. Hi guys, first of all a big Thank you - I am a huge fan of Affinity Design and use it for all my projects. In general the usability is great and it is a pleasure to work with. But there is this tiny detail that has bitten me so many times that I at least wanted you to know :) The thing is: AD obviously remembers the last directory that I have saved or exported to. In general this is very helpful because when saving or exporting repeatedly from the same file, it is very likely that I intend to do that into the same directory. BUT... I often start my work by opening a recent file and saving this under a new name (e.g. "mydesign_02"...). And when I do, I usually want this copy to go into the same directory as the original file, not some other projects export folder from yesterday. I cannot count how many times I have done "Save as", then worked in the copy, then closed AD, only to notice that the file is not, in fact, in the same folder as the original. So I have to start AD again, open some file, select "Save as" and check which folder it is saving to, then find my copy and move it to its intended location. Pretty annoying :) I assume that this is not very easily fixed, but I still wanted to let you know :) I have a feeling that these kinds of usability details are exactly what you're trying to get right, so maybe you will come up with something smart ;) Thanks again, best, Ole.
  5. ogardiner

    Crash when duplicating layer on OS X Sierra

    Hi, thanks for getting back to me :) I've uploaded the file, it is called "example_crash.afdesign". You can crash the app by duplicating (Command-J) the layer "Dorf" > "Dorf" > "Duplicate_Me". AD also crashes when you change the x-coordinate of the "Dorf" workspace (e.g. entering "1700" for x coordinate in the Transform palette, then pressing enter - AD crashes). I think the problem may be related to symbols. If I remove (and thus disconnect) all symbols, the layer can be duplicated without crashing AD. I hope you find out what's going on there... Thanks - Ole.
  6. ogardiner

    Crash when duplicating layer on OS X Sierra

    Luckily the crash only happens when using the "Duplicate" function (Command-J). Copy/Paste still works.
  7. Hi guys, since updating to OS X Sierra I've been experiencing more and more crashes of Affinity Designer. I can now repeatedly crash the application by duplicating a certain layer in one of my files - let me know if you want to take a look at the file (preferredly non-public) or if I can provide any more details (is there a crash log?). I hope you can help me out, up until now I've been having nothing but a great experience with AD. Thanks, Ole.
  8. @Ben You are right of course - it is only a few seconds and only once for each document. It won't stop me from using AD and loving it ;) It is just that these seconds weren't necessary in earlier versions. They are only now, and what for? Is the program better now that I have to use a workaround to do this simple task? To quote the Zen of Python: Just a last thought: In the end it is really not that important if a task takes a few seconds longer. But these seconds might push someone to chose another program altogether... Anyway, thanks again for taking the time to elaborate on this point :) Wishing you guys a nice weekend, Ole Trenner
  9. @MEB Thanks, it's much appreciated :) @Ben Thanks for your insights. I agree that (maybe) the new approach might be more consistent, and I am aware of the possible workarounds. Still, the new behavior requires a more complicated workflow than the old behavior. And I know that you guys value usability and ux more than anybody else ;) There are probably ways to keep the new consistency while improving the ux: - Configuration options for the transparency grid colors would allow me to switch to completely white (or at least less obtrusive) grid - Slices could have a checkbox "include document background" - The "new document" modal could offer an option to automatically create the not-to-be-exported backdrop I'm sure you have even better ideas :) I just wanted to describe my use case and workflow. Anyway, keep up the great work, best, Ole Trenner
  10. Just as a feedback for the dev team: I understand that you adjusted the behavior and now exported png files get a white background except when the document has the "transparent background" option checked. In previous versions the transparent background option only influenced the transparency grid on the document and not the background of exported files. Honestly, the new behavior might seem more consistent, but it is really uncomfortable. I create lots of ui assets (buttons, badges etc.) which need to have a transparent background. But I don't use the transparency grid because it does not provide a realisitic preview of how the ui asset looks on a typical user interface. Until now I could switch the document to use the white background and still export the png with a transparent background. If I needed the occasional opaque png, I could use the background option of the respective slice. Since 1.5 I have a much more complicated workflow: Now I have to check the "transparent background" option for my document, then create a white backdrop to preview my assets without the transparency grid, and then disable the backdrop in the export persona to still export assets with a transparent background. So much hassle... And the background option of each slice is more or less useless, because "transparent" does not mean transparent any more. I know I am but a single user, but maybe you can consider improving this behavior :) Thanks and keep up the great work, Ole Trenner [Edited: fixed typos]
  11. ogardiner

    Designer 1.5 slices export transparency

    I have to agree with the OP: in AD 1.4 an exported slice would have a transparent background no matter what the background setting of the document was. That was very comfortable because you did not have to use the disturbing transparency grid as document background and still export transparent png files. Also it matches my user expectation: exporting an area without any element should result in transparency, not in white... I would much prefer the old behavior over the new one. Thanks :) Ole Trenner
×