mqudsi

Thanks, I stand corrected. In all cases, is it possible to change this?

I'm fine with most keyboard shortcuts the way they are, but for the life of me I can't get used to the discrepancy when it comes to zooming: the Affinity suite zooms with ctrl+scroll and uses alt+scroll to rotate an object about its axis, while Illustrator zooms with alt+scroll and just scrolls left/right with ctrl+scroll. (Also, is rotating the selected object used so commonly that it merits the very coveted ctrl+scroll shortcut? I wish Serif just used both alt+scroll and crtl+scroll to zoom instead). Anyway, I can't seem to find a way to change this in the keyboard shortcuts section. Is it possible?

I suppose that means timer events should be classified into "fires in background" and "doesn't fire in background" with the default being the latter? Presumably that would address/workaround (without fixing)

AD/AP should block all processing/rendering/etc threads when it is not the active window or when it is minimized. Active tasks (the type that would present a progress dialog like export/save/etc) should of course not be suspended, but there's no reason for AD to be rendering the canvas when it's in the background. Additionally, all tabs except the current tab should always be suspended. The CPU (not memory) profile of AD when open with a single tab active (and not "multiple documents mode" enabled) should be identical whether that tab is the only tab loaded in AD or one of a hundred.

Thank you both for explaining. I understand the difference between cropping and clipping, but it was @MEB's point about visibility's role in all this that cleared things up. I now understand (but still disagree with) the results that AD presents. It is a difference in how AD treats objects vs how other software might. As a vector-based program, I would expect AD to treat a filled object and an unfilled object exactly the same, except in how they appear (i.e. unfilled is "filled but with transparent background"), whereas for a pixel-based program like AP or Photoshop (where masking comes from in the first place) it makes sense for masking to work on colored vs uncolored. But when it comes to vector objects, an area "is present" when it has an enclosed path, not when it has color. For a rasterized/flattened pixel layer, AD should treat masking the way it does: by colored vs uncolored. But for vector objects, the definition of "existent" is fundamentally different, and imho only whether or not a closed shape exists and not whether it is filled with a color or has no fill should play a role.

Thanks for the reply, Sean. The terminology is eluding me, but (referencing your images from here on out) I'm not understanding how the 4th image (bottom right) is correct. Each row has the same operation performed on it, each column has the same items/color. The operation performed in the second row, as demonstrated in the first column, results in the intersection of the two shapes being retained. The green fill of the rectangle does not appear anywhere in that resulting image. When the only change that is made is that the green fill is changed to no fill, we go from "intersection of the two shapes retaining the fill of the red rectangle" to "stroke of second shape in the color of the first, and the intersection of the two shapes with the (no) fill of the second shape (rectangle)." I am extremely confused how, if the only difference between operations 3 and 4 is the fill of the second shape which does not appear in the final result per image 3, do we end up with a completely different result.

It seems that masking is broken in the case of an unfilled mask (i.e. fill color: none) under 1.6.2 no fill masking bug.afdesign

This is a feature request to add an option to the right-click transform menu when right-clicking on an artistic text element or a textbox element to convert between one and the other. Currently, one must cut the text, delete the element, create a new element of the other type, then paste the text.

@Chris B So I just tried this... is it just me or does AD not allow multiple shortcuts mapping to the same action? I don't want to lose ctrl+w, but I want to map ctrl+f4 to do the same.

This is a feature request to add an "edit layer in AP" context menu item to Affinity Designer when right-clicking a raster layer in the layer browser control.

Thanks for the reply, Chris. I understand, I've actually already done so myself. This is a suggestion/feature request to support this keyboard shortcut out-of-the-box on Windows.

On Windows, ctrl+F4 plays the same role as ctrl+w on all other platforms; namely, it closes a single document/tab in an mdi without closing the app (at least if other documents are open, as contrasted with alt+f4). Since ctrl+f4 isn't mapped to anything else atm, it should be mapped to "close document".

Just a small request: now that the horizontal/vertical distribution options are no longer available in the toolbar and must be accessed via the top-level alignment drop-down menu, I was wondering if they could also be added to the right-click context-menu under the "alignment" heading? Currently, all the contents of the top-level alignment menu are available in the right-click alignment menu, except the distribution options. Thank you.

The latest versions of OS X and iWork finally bring native RTL support to OS X, it would be greatly appreciated if there were some way to finally type in RTL with Affinity Designer. Please and thank you.

Thanks, MEB.