matisso

So, over a year and a half have passed since this issue had been raised, may I ask how is this rolling? regards, Matt

+1 Definitely a must.

Sorry for being harsh here… My personal opinion – you'd better give up using Photo for RAW development and use anything else. Seriously. Issue #1, which IMO is serious enough on its own to neglect any others – no sidecar files saved with the development settings, making each of your development a one time better-do-it-right attempt. Such workflow (with external settings), obviously, is incredibly useful if you want to revisit your photo for various reasons – e.g. because the engine got updated and you might try and compare how it performs. Or you simply might want a different version of your photo – going back to RAW is as lossless as it can be, compared to adjusting the developed photo. I’ve used several RAW processors and most of them adapt this approach. If not, they keep an internal database of the settings, but nobody but Affinity thought it would be a great idea to make your settings go pooof when you hit the “Develop” button. Yes, there are presets, but this isn’t a realistic choice, you won’t be saving a preset for each photo. Issue #2 – if the rant above still keeps you from changing your mind about AP for RAW files, try moving the “Blackpoint” slider and watch your blacks go clipping in no time. It’s a really cruel joke. Now there are some nice things in it, particularly the option of making additional, localized adjustments by means of masks aka overlays, which can be prepared using advanced selecting and masking features that AP has (although it has its own faults, you can’t adjust all of the parameters when using an overlay, unlike in Lightroom). But it’s a small gain compared to the fundamental flaws this engine has. Move along and save yourself some frustration. Cheers, Matt

Hello, Today I needed such a simple drawn shape and thought I would do it in Designer, since I convinced my employee to buy a licence. However I ran into a strange and annoying bug – merely upon changing zoom level, the brushed stroke changes its appearance. I have included the link to an animated gif that shows the shape at 75, 100, 150 and 200% zoom and a source file as well. What’s even more frustrating, I actually discovered it after i had exported the PNG file at twice the resolution and found out it the stroke changed in it. Try opening the attached .afdesign file (Windows 10 at my end here at work) and clicking Ctrl + + and Ctrl + - and see the stroke going “alive”. Please see this: https://imgur.com/a/8F7DUB5 Regards, Matt brush-bug.afdesign

@TonyB, I have a question: Will that take the chosen resampling method into account? Should be obvious, but it’s better to ask… I often find the default bicubic too soft, particularly with bitmaps and have to re-export the assets with another resampling mode. I actually have an idea for a feature suggestion based on this. cheers, Matt

Good call. I was also lost many times the same way but somehow never thought of actually making a thread. cheers, Matt

So I sprained my ankle exactly a week ago. No more longboarding for a while! Since I got my X-ray images on a CD, I thought it would be nice to play with them a little. I didn’t have anything particular in mind, this was freestyle, and somehow ended with a title page for a magazine, I suppose. I used Designer for the final layout, although the DICOM images were processed in Photoshop. It was my go to app and frankly, I didn’t think for a moment if Photo could handle DICOM, too. I wish there was a multi-column functionality in AD… In case you were wondering, the typeface used was Bona Nova family. It’s been released fairly recently and it’s a result of a tremendous collaboration between Andrzej Heidrich, the traditional graphic artist (who also happened to have designed banknotes in Poland among other stuff) and a young but already prominent type designer, Mateusz Machalski. If you’re interested, you can read more at http://bonanova.wtf. Cheers! Matt

Any feedback on that gentlemen? Or should it rather be a separate feature request? cheers, Matt

These are very good things going on. Kudos, @Ben and the rest of the team! While you’re at node tool, would it be possible to expand segment dragging functionality, so that there’s an option to keep nodes’ direction instead of having them rotated like it currently works? I know you can grab a single handle and constrain the editing direction by holding Shift, but editing curve flow by dragging a segment is often much more natural. For type design or modification it’s actually indispensable. Shift modifier seems to be available for segment dragging, doesn’t it? I miss this functionality very much and I think than anyone dealing with type or logo design would find this really useful. Cheers, Matt

@MEB, this is just a Modal Windows.afdesign file from the Grade UI Pack, like I said. For the sake of convenience though – there you go. There's also the screenshot of the Snapping Manager you asked for. And a few more showing moments when it goes “wrong”. However, I don't really think the snapping settings are the key here. It’s the snapping that takes over pixel alignment that appears to be the problem. Cheers, Matt Modal Windows.afdesign

This is pure gold, I must say. Cheers, Matt

Thanks @MEB for the hint on snapping to objects. Indeed this might be likely is the issue, I had my mid-points snapping on while testing this on the Grade UI file (I had all of them ticked, to be exact). It's worth noting that it doesn't always behave like this. I had to make a few attempts to recreate it, because sometimes the object snapped right into the pixel grid – that would actually explain the mechanism you described. However, if it also happens that it doesn’t snap where it’s expected, well, something isn’t right. @arechsteiner pretty much nailed it – it says force, so please actually force. Right. So I actually played with it for a bit longer, trying different snapping options and carefully observing what is happening with the object as it snaps to different candidates. It looks like this behaviour is also caused by snapping to objects that are off-grid. Text is notorious for creating such situations, as it doesn't follow the pixel grid. You might select all the text objects in the layer palette, and choose “Exclude From Snapping” option from the context menu. Then again, that would be extremely tedious to do it for every text object in your design and for every objects that you prefer to stay off the grid, for better antialiasing or whatever different reason. That's where another limitation comes in, namely the lack of selection of objects based on their kind, attributes, or so. Enter Illustrator: Select / Text Objects. Among other selection options, like select similar objects, same opacity, colour, stroke weight, etc. But still it wouldn't address the underlying issue of objects not being pixel aligned, or snapping taking priority over it, if you like. That’s actually easy (from a user’s perspective, ofc) – ideally, give the user a choice in preferences. One option would be to force integer values, another one – allowing fractions in pixel forcing mode. Or make the decision on your own, like Adobe did. For the record, in the described case Illustrator snaps to either smaller or larger integer value, ± 0.5 pixel difference depending on from which side you draw the second, smaller object. It doesn’t make any difference to the eye. When centering objects manually with the help of smart guides, the object stays pixel aligned (technically being 0.5 px off the centre of the one it’s being aligned to). If you use an align feature, and centre them, it aligns perfectly, not pixel-perfect. Then again, Illustrator also has the “Align selected art to pixel grid” feature. Sorry for a slightly harsh tone of my previous post. It’s just that I see a lot of potential in Affinity apps but when I try to use them in a real world environment (aka actual work) I run into various glitches and I end up doing things longer and less comfortably than I would have done it using Adobe apps. Sure, a part of it happens because I’m far (well over ten years) more experienced in the latter, but some features like this clearly work in unpredictable ways (the infamous constraints/ungrouping issue being just another example). Cheers, Matt

Same issue here. This has been around since 2014 (see https://forum.affinity.serif.com/index.php?/topic/452-pixel-snapping/) and still isn't properly implemented. Meanwhile it's 2018 and I'm getting this (this is a part of Grade UI pack, which everyone who has Affinity can grab): Just moved the top box, with with pixel snapping turned on, without snapping override (Alt-key). Fraction coordinates, blurred artwork. When is this going to be fixed? As in: working? When preparing this screenshot I drew an artboard to export this part of the file. Guess what: despite pixel snapping the artboard got a half-pixel height. FFS. I paid for both Affinity apps and even got my company to buy another copy of Designer. I get to read a flurry of posts about yet another platform releases, awards of the year, how Affinity can replace Adobe apps, whereas basic stuff like this still causes trouble. This is extremely frustrating and disappointing. Cheers, Matt

I won't even bother to download this, @dutchshader. Read this carefully: let's say you have twenty layers/objects but sandwiched between each pair of them are other objects that must remain where they are. In this scenario you will still need to select the layers you want to move one by one and keep it that way. If you group them, the sandwiching will be gone. Locking an object within a layer isn't a solution either. You might expect (I did) that if one object is locked, it would remain in place when moving the layer that contains it. However if you move the parent layer, the locked object follows, too. Cheers, Matt

Yes please! I'm amazed, not to say a bit disappointed, that this had gathered so little attention. Linking is essential for the reason mentioned in the above post and groups are not a substitute. Cheers, Matt