Friksel

just trying it, but doesn't do anything I'm afraid

Hi, Does anybody here perhaps know what could cause my layers don't get selected when clicking on their graphic in the viewport? It's pretty difficult to keep on iterating over all layers everytime just to get the one I need. I'm used to click or double click on a curve to select the layer, but somehow this isn't working anymore. Is there some setting I'm missing here or something?

You seem to not wanting to read and understand my posts. I discontinue this discussion now.

No, not at all. It only needs to be implemented the right way: at the end of all snapping options. No matter how many options you have or whatever combinations you make with them; snapping to pixels should always be the last stage after all snapping options calculated. And yes, there is ALWAYS a priority order of snapping options, because that's just the way code works. When you move your node the software iterates somehow over all snapping options and picks some option that suits best or a combination of options are calculated together to get a result, but you always have a position value at the end of the equation somehow. And that value should only then be FORCED to a whole pixel. Where all inbetweens of a curve lie doesn't matter, you only snap nodes to pixels.

I don't agree with this being moved to feature requests, but that should be obvious by my post. Next to this you explain how things are working now, but I know how things are working now. Thing is in my opinion it shouldn't work like this. Snapping to pixels is not something we like for layouts, but to be able to have our fills on exact pixels as far as horizontal and vertical goes. That should never be influenced by other snapping tools, that are used for layout purposes. Because when they do, like Designer is working rightnow, you simple cannot rely on 'Force Pixel Alignment' as a designer, because in way too many scenarios it's just not snapping to pixels and as a designer you don't even know that it isn't working when designing, because you only see it when zoomed in or happen to know this problem. I'm starting to wonder if people realy understand the purpose of this switch. We can talk about all kinds of scenarios with all kind of snapping functions turned on or off, but that doesn't hit the point here. Thing is that snapToPixel should snap to pixel. Nothing more and nothing less. And right now in most snapping-configurations it is not snapping to pixels. Which I call an issue. It doesn't matter how snapping functions are set, in the end in Force Pixel Alignment (snaptopixel) should always be applied in the end. And if a designer decided to turn on snap to the center of a curve or whatever else snapping function and that happens to result to half a pixel, then the same applies as when a user has his cursor on a half pixel: round it to a whole pixel. It doesn't matter if Designer choses the left or right one if it's exactly in the middle of 2 pixels. The only thing that matters is that it's always calculating in the same way. To either exact half pixels all chose the right side, or they always chose the left side. That way we can finally work on whole pixels as designer and use snapping options too. That is just impossible right now.

This is exactly what I mean. In my opinion 'Force Pixel Alignment' (in some javascript frameworks called 'snapToPixel') is not the same kind of snapping as all other snapping functions. All the other snapping options are for layout purposes, while Force Pixel Alignment is related to the technical output. So I really believe Force Pixel ALignment should be treated different and should have highest rank, 'cause it's not about a layout thing per se, but about having technical sharp digital images when using raster-formats as output. Preventing all kind of side effects from happening when using in animations (online).

No, it's not. Look at the video. All objects have absolute integer position and size values and still result in half pixels because of other snapping options. Force to pixel alignment should always be highest priority in my opinion. Otherwise you as a designer would never know for sure (unless you check every node you draw in closeup) if your designs are on whole pixels so can't trust the setting anymore. Or you need to turn off your other snapping options, which would be not very efficient to me. I love those snapping options and use them a lot, but I still want to let Designer pick the nearest pixel after calculating its snapping result-value. Also, sometimes you receive files by clients (or use some older work when you didn't place nodes on whole pixels) and don't want the existing shapes to affect the way you draw new shapes. Now it does.

When 'Force pixel alignment' is turned on all drawing from that moment is snapping to whole pixels. But when you start moving those just drawn curves (all created on whole pixels) around you see they are still resulting in half pixels some times. So I did some switching in snapping options and found out that Force Pixel Alignment isn't on top of it all (highest priority). There are certain other snapping options that still cause Designer to chose off pixels. Like 'include margin midpoints', but also other important snapping options, like 'snap to grid'. Look at this: (for the record: ''Move by whole pixels' is turned off) double-snapping.mp4 In my opinion this is confusing, misleading and error prone and the unexpected endresult remains hidden to designers while designing, because we (well at least I do) assume all graphics will be snapped to pixels when 'Force pixel alignment' is set to true. I place this under bugs, because I really believe designers should be able to trust that 'Force pixel alignment' will indeed force pixel alignment, and right now it's not and most of the time we don't even know it until problems occur (like blurry images as an end result we see when we finished the design and 'render' to png for example). In the video you can see clearly the node is bing placed on a half pixel because it's prefering the margin snapping over pixel forcing. But you can only see that now while looking very closely on a zoomed-in grid of 100x100 and even a visible pixel-grid turned on. Normaly we don't work like that and need to trust Designer to always pick/snap to whole pixels if we set 'Force pixel alignment' to true. Why else would we turn that setting on and the setting is a prominent button on the UI that's different to other snapping options. So it seems like this is causing the half-pixel issues I was having for drawing graphics. I found out that Designer has a 'pixel work' preset in snapping options that turns off all other snapping options making sure forcing to pixels works. So yes, that preset (all other snapping turned off) will probably always work with pixel work and always chose whole pixels. But if we need to turn off all snapping options just to work on whole pixels that seems a little too black and white / one or the other to me. I want to use both and consider that to be a very standard expected workflow more designers like to use; I use snapping options a lot, but I only want to enable force pixel alignment next to that as a top priority(-correction) at the end. In my opinion force pixel alignment should always be priority over all other snapping options, so in practise I would expect Designer to fire it's snapping algorithms first and then correct the end position of those snappings to the nearest pixel when Force pixel alignment is turned on.

Thanks for your effort and the time you take to help. For some reason with my working project this Force Pixel Alignment was still resulting in portions of (floating) pixels. As a test I followed your steps exactly from start to finish with Move By Whole Pixels turned off on a new document exactly as you described. Just to find out all drawing is indeed snapping to whole pixels. But than I started moving the just drawn curves (on all whole pixels) around and saw they are still resulting in half pixels some times. So I figured something must be different in my configuration in comparison with yours. So I did some switching in other snapping options and found out that Force Pixel Alignment isn't on top of it all (highest priority). There are certain other snapping options that still cause Designer to chose off pixels. Like 'include margin midpoints', but also other important snapping options, like 'snap to grid'. Look at this: double-snapping.mp4 In my opinion this is confusing, misleading and error prone and the unexpected endresult remains hidden to designers while designing, because we (well at least I do) assume all graphics will be snapped to pixels when 'Force pixel alignment' is set to true. In the video you can see clearly the node is bing placed on a half pixel because it's prefering the margin snapping over pixel forcing. But you can only see that now while looking very closely on a zoomed-in grid of 100x100 and even a visible pixel-grid turned on. Normaly we don't work like that and need to trust Designer to always pick/snap to whole pixels if we set 'Force pixel alignment' to true. Why else would we turn that setting on and the setting is a prominent button on the UI that's different to other snapping options. So it seems like this is causing the half-pixel behaviour for drawing graphics. And I also found out now that Designer has a 'pixel work' preset that turns off all other snapping options making sure forcing to pixels works. So yes, that preset (all other snapping turned off) will probably always work with pixel work and always chose whole pixels. But if we need to turn off all snapping options just to work on whole pixels that seems a little too black and white / one or the other to me. I want to use both and consider that to be a very standard expected workflow; I use snapping options a lot, but I only want to enable force pixel alignment next to that as a top priority(-correction) at the end.

Sorry @walt.farrell I can't/don't share professional projectfiles. When experiencing issues I always try to create a reproduction-file to show the issue, but I can't think of a way to do that in this case. I was hoping somebody here experienced the same issue before ('moving' artboards to portions of pixels) and could help me in the direction of 'don't use that and that tool, cause it's error prone' or 'you forgot this and this setting', or something else I might be missing here. Nice resource you're pointing to here. I did a quick read and will continue reading when I have a little more time. Thanks for summing things up a little and completely understandable. I understand when using strokes there are choices to be made by the software to put colors either in one or the other pixel when we have odd/even width 'issues'. But I need pixel-snapping on fills only and would expect the pixel-snapping to look at the positions of the nodes rather than worrying about strokes and what not, cause the strokes can have all kind of difficult settings adding to the calculations, like what are your choices when you're not using an odd or even strokewidth, but a varying strokesize. For pixel alignment I expected Designer to look at the positions of the nodes only as reference for what pixel it snaps to. For example like this: What I would expect: When a user starts drawing a shape, like for example this rectangle, the cursor automatically snaps to the closest pixel while moving the mouse or pen. In that case you always have your fills on whole pixels instead of portions of pixels. Yes, strokes are left out of the equation and could be off if you choose the 'wrong' stroke-width, but in my opinion it's perfectly acceptable and understandable that the decision to use 'wrong' stroke widths, so strokes resulting in half pixels, is left to the designer. This way when a designer draws shapes (snapping to a pixel grid), he just sets his stroke to an odd width (1, 3, 5 and so on) and knows for sure all his strokes are rendered on whole pixels too. And if it is build like this Designer could still throw a warning-message somewhere when a user uses a stroke (or brush) with stroke-widths resulting in pixel-portions and leaving the whole-fixed-pixel path. Just some exlamation mark on some yellow triangle or whatever suites the UI. I don't see any difficulties in that approuch on the moment, but I could be missing something. This way it would also make more sense (at least to me) to convert strokes to outlines, because you as a designer can see what pixels Designer has chosen for you to snap to. And the Designer software knows exactly how the full shape looks like, so it can convert it to pixels much better, 'cause it's knowing all details of the shape, like direction of the paths, where it is on the screen and so on. So this should work on both open and closed curves. So really what I'm after is just a grid of the size of one pixel for each row and column, where the cursor always snaps to when drawing shapes and nodes.

Hi @R C-R, I just see your post now, somehow I missed thisone. Thanks for this. I will dive into the article when I have a little more time. For now, what do you mean by this: "it would only work for odd or even integer line weights."? I understand you probably mean it's working for either odd or even integer values, but this moment I can't find a reason why that should be either the one or the other. Well, maybe that's in the article.

Yes, I am absolutely sure I had all artboards in integer values, cause I was doing that on purpose on all artboards today because I don't want blurry graphics on my webproject and so put everything on whole pixels as far is possible. I have have my document in pixels and use pixels everywhere. Both position and size of all artboards were set to integer values. What I did see though one time today when I was adding a new artboard in an open space suddenly all other artboards were moving on screen as if they needed to re-arrange themselves to make room for a new artboard. That was pretty odd and didn't feel stable at all, especially because they were all on lock. There was no need to make room and I don't know of any function that does that in Affinity neither. But thank god that only happened once today and after that the values of the artboards were still integer values I believe. At least later today I checked all values (and changed some), but even after putting them back to integer values again later today they were on half pixels again. Crazy. As if Designer is calculating the position of each artboard when a new artboard is placed and then makes mistakes in the calculation resulting in values with decimals. I'm working in this file whole day now and locked all artboards this morning after putting them to integer values. But at this point I don't trust that lock anymore at all to be honoust.

@walt.farrell do you perhaps know if this is caused by the same bug?: After placing all my artboards on exact pixel locations (so no decimals) and even locking them, just to find out after working a day in the file (not changing those artboards, only adding new ones), that all my artboards are suddenly moved decimal pixels. Causing the slices to be wrong... causing wrong filesizes on the output from the export persona... causing me wondering why locations aren't right in my webprojects... just to find out Designer changed the artboards for some reasons and so all outputs are wrong... I need to have the exact dimensions on the output files as orginally set in my artboards. So I find myself unlocking all artboards again and putting them back on whole pixels again. I already had to do that a few times only today for this project. As you can imagine it's getting pretty frustrating after a while and it now takes a lot more time to do my project. Do you perhaps know what is causing this issue? Could this be the same issue as you refered in your last post here? Anybody have any ideas on what is causing this issue, so I can keep it from occurring everytime again? Thanks, it would really help to have some knowledge on why this issue keeps on appearing!!

Thanks @walt.farrell . That's unfortunate, but thanks for the warning. I stop trusting it and putting it off for now.

Hi everybody, I try to keep nodes on whole pixels, so I put snapping like this: - Checked Force pixel alignment - Checked move by whole pixels (- snapping is on) But for some reason I still get half pixels when moving or creating nodes or moving curves. I'm out of ideas on what I could do wrong here. I always thought putting snapping to these settings should prevent creation of half-pixel positions, but it doesn't seem to work as expected. Anybody got a clue on what I might be doing wrong or missing here? Thanks!

Just curious, I'm using the windows version and in both the 'stable' as the beta-version we see blue selections. In your example everything looks only gray. This is what pc-users see in both designer versions, and that seems pretty easy to spot: Is the Mac-version that different to the PC-version? (serious question... I am surprised)

Interesting. So sqrt(2) returns a 'constant' value, so independent on the current value of a textbox. But how does this relate to a textbox, like width or height, set to '50%'? (When entering 50% the %, instead of sqrt(2) ís dependent on the current value since it returns 0.5 * value. Which is actually a pretty great feature btw), so that seems to be a different approach?

Thanks, but again, as a professional I'd rather have stable software that just works than 'free' updates with some minor bugfixes that don't address mayor flaws. The issue of outline-strokes not working is open since 2013/2014.... that's 4 to 5 years!!! You just can't sell that to professionals. It seems like Serif thinks it's an open-source company and working for amature-users. But in realitiy it's paid software and you advertise the software to be made for PROFESSIONALS. We have our problems too and we need to be able to rely on Affinity products. I trusted Serif on this promise to fix with regular updates and making software for professionals. But this is not the type of reaction I would expect from a professional company understanding client needs. You reaction seems to state we should be happy with every small bug fix we get in months. But the realitity is that that's nothing extra or optional, it's just basic stuff a software company SHOULD provide it's customers. Software should just work and if it doesn't it should be fixed. If the income is too little Serif simply set the price too low or their expectations to high. That's not something you could lay on the shoulder of your clients. It's something Serif should fix or customers just walk away. What could you do with a product and new features when there are no clients left because the product isn't stable and clients got tired of waiting and waithing and waithing for basic stuff to get fixed? Even open source products have better update cycles and don't have these kind of flaws. This is just just crazy. You can't treat professional customers like this. It's amaturistic. Maybe I just made the wrong choice trusting Serif in accomplishing what they advertised to do. Or maybe Serif is advertising at targeting professionals although they in realitity target a private, 'amaturistic' crowd that was already happy with open source software and everthing they can get for free and just needed a dark interface. Sorry to tell you, but I just feel betrayed with these kind of silly reactions and the same lame excuses over and over again we get everytime after years of bugs not being fixed. You also seem to forget how much effort people put in reporting bugs and feature requests. And testing software for you guys. Without seeing anything in return in the form of fixes or additions we REALLY need. Who asked for bullets in a textbox? We need vectors to work, outlines of strokes to render the way they were designed, boolean operators to work etc etc. All issues reported thousands of times and nothing happens. Promises and promises.... soon... next... later... but still nothing. Come on guys... get a reality check and fix it instead of making more products while the existing products are left with bugs.

That doesn't work that way. You can only hit period AFTER you drag'n'draw the shape and than you have to resize the shape again

Thanks for your response @MEB. I don't having any doubts you guys are working hard. But I keep on wondering why you (seem to) keep the development team so small and (at least as far as I can tell, sniff, see on your website) don't hire extra developers to fix these things. I understand it needs testing and all, but these bugs are open for months to years now. I would say plenty of time to fix them, but the priorities Serif put on an additional product (Publisher) and new features instead of fixing long-and-lots-of-reported issues keeping us from doing regular, basic artwork stuff everyday as professionals. This to me is not a matter of you guys working hard or not, it's a matter of thinking as a company to have enough manpower to do the job. It seems like you guys took way too much work on your head for a small team, without growing and expanding. That's asking for problems and complains of users. Again, I am a faithfull professional customer and I am sure you guys are on the right track of things and you guys have great responses on the forum and enthousiasm, but in the end for professional users it's important that the software works too. Rightnow you just can't sell the amazingly long waiting (I'm talking about years!!) it takes for bugs to get solved. And I'm not talking about exceptional issues, but basic stuff we use everyday. And when this is a matter of finances (which I doubt with such a user base), I'm possitive professional users are happy to pay some extra for your products if it's stable and has basic functionality like simple deformations in it. But I'm talking in circles, I wrote this way too often and other users did too here on the forum and it doesn't seem to change so far. Hopefully things will change if the publisher if finally released and there's time to help Designer and Photo-users again. I just hope Serif will finally see this and change it and keep my fingers crossed. Again, I'm eager to stay and hoping for a change. But to be honoust and sorry to say; last weeks I was longing back to the days with Adobe where we paid a lot monthly, but didn't have to spend all the times for workarounds costing a lot more mondy in the end. But again, I like your products and I'd rather stay and don't want to go back to that silly licensing system and being held prisoner with their system. I try to understand... and keep my fingers crossed. And to conclude: it's the briljant base of very promising software and I really like it. That's what keeping me waiting. Hoping for the best and thank you! [BTW I just wanted to add a THANKS to your post, but I seem to be out of THANKS and LIKES on the forum... ]

I admire your positivity, but bugfixes are not really extras but things that needed to work in the first place. And those bugfix-updates were not really addressing mayor bugs unfortunetely. This is not an open source project.

Hi @MEB Thanks for this explanation. As others I reported a lot of issues and requests, but this is the first time I read about this (that Designer and Photo trunks will be updated in a large step from the Publisher trunk and thus have a lot of fixes at once applied). Because of not knowing this this caused a lot of people a lot of disconfort/irritation, because a lot of issues aren't fix for a long time and people are waiting for looooong requested features. Also I see the same bugs and requests reported pretty much everyday here on the forum and people don't know about statusses and therefor keep posting them and opening new threads with all frustration coming with it if there is no response from Serif. Well, at least that's what I am experiencing a lot till the point I really start asking myself why I still report bugs if we don't see any fix (or know about what you guys are working on) and I really wonder if we can still trust Serif in fixing bugs (and thinking about professional customers working with this software all day). Would it be possible for Serif to create and keep up to date some general forum/sticky thread to keep us users informed on what you guys are working on and give us some trust Serif is really (finally) fixing some nasty bugs and communicate this in a more central way? That might perhaps also prevent all the double threads on the forum to be opened. I am hoping some mayor bugs will finally getting fixed the coming days, although in the Mac-forum I unfortunely still read mayor bugs like the boolean-operators are still not adressed in 1.7 beta. And probably (but I hope not) the same goes with convert-to-curves issues?! I hope not! I keep my fingers crossed in that some mayor issues will get fixed soon. I really would like to renew that trust in Serif, I really would like to, cause next to this this is such a great tool with a lot of potential. Thanks!

Thanks for your response @Ben. I appreciate you take the time to answer and explain your view on it and why Serif decided to build it like this. I didn't talk about needs to have it 1:1 proportional (I think you mean keep aspect ratio to 1:1 by this?). I want to stretch-draw the shape where the position of the drag-cursor shows the position of the boundingbox of that shape during drag. In my usecase it didn't need to be squared (1:1). But if I needed it I should hold shift during drag-draw. So that would be my view on an intuitive way of creating 1:1 proportioned dynamic shapes. I understand your view on this and it seems like there are 'two kind of people'/views on this: 1) Having focus on the center of the shape [how it is build now]. With this method all points of a star are connected to a virtual circle, where the center of the shape is always the same as the center of the circle and the shape doesn't move while switching amount of points. If we stretch/draw the shape we in fact keep the center of the shape in the center of the drawarea. Let's call this view: center-focussed. 2) Having focus on the boundingbox of the shape, so treat all shapes the same; like a width and height we can stretch. If we strech/draw the shape we in fact keep the center of the boundingbox in the center of the drawarea, independent of what the center of the shape is. Let's call this view: bounds-focussed. It's clear to me that both views has its pros and cons. And that both ways are possible in Designer now, where the first is user-optimized and the second takes more steps to accomplish and therefore takes longer. Especially on projects where this happens a lot. I'm clearly on the second 'camp', but I can also understand where you're/others are coming from and probably there will be situations where the first solution would fit a certain job better for me too. But mostly I would need the second way to do things for my projects, because when I need, for example a star, I want it to be a certain size and snap to bounds. For my use cases I don't care if the shape will stay on the same location when switching starpoints, because I set the amounts of points first and then draw the shape on the exact size and location they way I want it to be. In my mind and workflow that makes the most sense. But again, I understand where you are coming from and that there are usecases for the other method are too. That said, it's pretty frustrating when you are on 'camp 2' (like me) and find yourself being frustrated all the time, because you first select the amount of points, than draw the star (or other shape) to find yourself not being able to snap the corners of the shape to the bounds/size you want it to be. So than you have to release your mouse, hit period (.) and do another resize of the same shape you just drew. For the projects I work on that's a crazy workflow that will cause frustration easily, especially when working on projects with lots of shapes (like I do for illustration work) and disturbes the fun and is pretty timeconsuming too. So I understand there is a place for the first method and see there are some people like to use it that way and probably there will be situations I would use the same methods for a special case. But I agree with @Mithferion in that it would be best if there would be at least some way to do method 2 (bounds-focussed way) on the first draw, so with some optional keystroke to hold while dragging to draw or resize, to fit my (and I'm sure a lot others) workflow as well. Or else a toggle in the toolsettings making drawing either 'shape center based' or 'boundingbox based'. Please consider this! Thanks.

Thank you darling for the nice words . You didn't read my post, but I still love you

Yes, but unfortunately it's still not cropping the vectors if you need vectors as output. Real cropping in Designer is only possible when converted to pixels. Impossible with vectors if you don't want to go through all curves one by one and do a lot of work using the boolean tools. I need a real destructive vector crop tool too. Right now cropping vectors is a real pain and takes forever.