pixelworker

I really regret having bought the v2 update. I can't imagine any positive impact on Affinity. I doubt that they get just more development resources. I don't want cloud integration. When I want to work collaborative I use figma and I couldn't care less about canva. Do you have any non-web-based, professional alternatives in mind for designer and photo to create screen mock-ups? (vector and pixel based) and simple photo editing?

It's pretty awesome that the staff is listening and discussing here. I'm wondering. Could this not be solved by a way to add your license to your affinity account after purchasing. And when you have it registered in you account you get a serial and you could use the this serial for any activation?

I can't count how often I've converted picture to pixel layer for assets that I've added via copy & paste or drag & drop into Affinity. An option to do this by default would be a hugh help.

Still a very important topic. Please enhance it for ui design use-cases.

Do you know by chance why it's not existent in Windows?

I like it a lot that you ask for the data and try to be transparent. It's very much noticed that you trying it to do the right way! And it should be the standard to show the raw data of what will be shared. Is it be possible to add away to the program to show the actual shared JSON data that will be sent? A simple save as to disc or showing it in a pop-up is more than enough. This would increase trust a lot. I like to help with data as long as I'm 100 percent in control if I want to do it and can check what I share.

From Affinity: If you’ve purchased from the Affinity Store — each time you start the Affinity Store software it will check for updates and offer any available update. The latest update will install over the top of any earlier version, with no need to uninstall. You can download the latest installer by logging into the affinity store here and find the order in your account and use the "Download" button in there. Alternatively, this new release (and previous versions of Affinity Publisher for Windows) can be downloaded from this link. (those installers are NOT for Windows Store purchases). It says there is a automatic check at startup. Is there a way to disable it? Please add a way to do so if there isn't. I prefer no automatic established connections from a program. I prefere to pull for updates manually.

Firstly, it's not only in Designer. Photo has very similar issues. I agree with a lot of what you wrote but I don't understand your conclusion. 😉 The user should decide. That's why there are options like "Force pixel alignment" etc.. The only issue is that it's only working for some workflows, while others ignore it. Currently it's rather a "Force pixel alignment for some actions" It should be no problem to add something like "quantise clicks to pixel" and "keep whole pixel at transform" to the menu to solve these problems and stay as flexible as now. Correcting it manually all the time is adding hours and hours of overhead monthly for me, it's prone to error and simply frustrating because of many manual corrections I have to make. I think the way Figma and Adobe doing it is the better compromise for daily work. When you need precision you simple use a higher canvas size. It's not that I don't like the freedom in Affinity and Affinity could be better by combining both things via options, but established workflows like pixel perfect work have to work time efficient too. By the way, for other units like mm or pt there is no real force snapping at all. Even setting a 1mm grid does not work really well. You can still place between the grid in some cases and need to correct it manually. When you doing these things as professional work on a daily base it adds up. I have no time to correct these things all the time manually when the computer could support me.

Affinity Design is a hybrid design application. Advertised for screen design too. Photo is a pixel manipulation software. It's not rocket science to force the pixel to the grid, I don't request any next level AI feature. Just that "force pixel alignment" actually works reliable. I really do appreciate the help and the suggested workarounds, but at the same time I'm slowly starting to wonder why the need for pixel perfection in Affinity has to be discussed.😉 It's a absolute key requirement for many professional tasks like screen design. It's not about the need to craft pixel art. At least for me. 😉

I support the request to know what this means. Blocking them is no answer 😉 I use Affinity to avoid cloud. If there is a connection all the time I would like to know too why and what is transfered. I see no requirement to open connections in the background after activation.

Exactly 😉 And I expect that Affinity will help me with that. Like any other program does that I'm aware of. That's why I expect that placing e.g. an artistic text will always be places at integer values with "force pixel alignment" that the outcome is reproducible. That's why scaling items with locked ratio should 'optionally' only make whole pixel positions possible that I don't have to correct it all the time manually. I'm have not given up completely. I still hope someone from Affinity will join the discussion in some way.

I appreciate your help. But I think you got it wrong with the issue of font rendering without locking to the grid It's not about the font. It's about that a font gets a different raster representation when moved by by non integer pixel values. This creates (different) aliasing. To give you an example. - Use Artistic text "abcdefg" and place it at X (100px) Y (100px) with font size 10px. Use any font you like. - Copy it below that you see both. - Go to transform panel and make sure that the first one starts at integer pixel values (100; 100). - Change the X of the second to non integer value (x.7). - Make sure to use view mode pixel or export it as an image. The result is that both texts have a different outcome on the pixel grid and thus look differently. This is obviously mostly an issue for exports to screen resolutions (90 - 200ppi) obviously. This will be especially obvious when you use font with perfect pixel hinting like the examples above. There is no solution other than respecting the pixel grid when "force pixel alignment" is active.

Thanks for the explanation. That's a drawback. But good to know that I'm not just to stupid to find the right option. Maybe it's a different use-case. I can imagine doing that for a headline in single image. But for gui design this is not a workflow that is possible. Aligning front at multiple document and at many places all the time is not a possible workflow. It'd take ages. I need to edit text often so live edit is a requirement. That said, for this use-case text frames are a solution which work ok. They do not not start on subpixel level and font looks the same all the time. By the way. When the artistic text tool started always on the pixel grid with "force pixel alignment" active it would not be a problem. In general, I'm a bit disillusioned currently. I would like to see a bit communication by Affinity about the problem.

One point I do not understand. The suggested manual hinting at subpixel level is super dangerous and I want to avoid it at all cost, because same characters will look differently. And "a" should always look like another "a". The differences by subpixel movement on the raster rendering for small and normal font can be quite big.

😉 Thanks for all the input. That's true. It's a serious issue and I'm at a point thinking that Affinity might not the right product for me. Which is strange because I consider pixel perfect workflow a totally basic thing. I like Serif a lot and would like keep using their products. That's why I try to bring it up again. I tried it long time ago without any success.

My needs are simple. When creating assets or guis I need a to work pixel perfect. That means I need a way that Affinity always respects and forces integer pixel values. Force pixel alignment does not work in all cases. Affinity is working with a higher precission means I need to be super carefull not to be between pixels, which results in aliasing for pixel rendering. I can't remeber any other software which makes this so complicated and time consuming.

Right. It's about the tools not about the inner rendering. Affinity has many places that can mess up pixel perfect work, resulting in aliased rendering because pixels are between physical pixels. Sorry , but Affinity is the only application I know that require so much care to work pixel perfect. It's no solution to tripple check everything and correct many values manually in a second step. I can't justify this overhead and correct it manually in a productive environment.

Yes, that's how it's designed to work. That's why I use other methods to scale. But that's basic operation in almost every software. Dragging on a shape with the mouse to scale it. I can't imagine an alternative for daily work. How do you deal with it exactly? Same here. That's how it's designed to work. Pixel alignment of vector objects affects bounding boxes. If you want alignment of strokes, you must set them to "Align stroke to inside". If you align them to center of the bounding box, then you must always use even numbers for stroke width. The math is actually quite simple here. Oh, and you'd better avoid prime numbers… It's about the method to change the "width" value. You have a slider for that too. You need to use arrow keys to set integer values. With the mouse you get non integer values quickly. "Force pixel alignment" should restrict to pixels as well. It's the issue in Photo which should be about pixels. Artistic text, yes. I guess that's by design because its bouding box is not really relevant. You will always have to align individual characters manually. (Been there done that many times when designing banners or logotypes for Teh Interwebz…) It's relevant. Consider this. Starting at non integer values means the resulting text is moved off the pixel grid. You will get aliasing and a different text rendering. Test this. Write a text. Copy it and start at x, y 10; 10. Now copy the text and start at 40,4; 40. The text is rendered differently.

So far I can trace back many of these issues to scaling an item with locked aspect ration. Scale a shape 100 x 50 will scale down to 99 px x 49,5px. That keeps the perfect ratio, but it's moving of the grid and overrides the "Force pixel alignment" option. Another source is setting "Width" of a Stroke. It's non integer when dragging on the slider even with the "Force pixel alignment" option. You have to use arrow keys to set it in px, which reduce working speed a lot and you have to be very careful to not to drag on the "Width" slider in any situation. Another source is placing items. I can place a text easily at X 1583,9 px and Y 96,3 px when clicking on the canvas. The same is true for many other tools like the pencil tool. It's not forcing things to the grid. It's the same in Photo by the way.

I'm sorry to say this but it's not a solution for an operation that you have to do hundrets of times like resizing via mouse. This have to work out of the box like in other programs. Too many sources for human error otherwise and too time consuming.

Thanks for the hint. I have to check it carfully and comparing it to actual pixel rendering. I did only a quick check and thought that might be the missing option. At first glance it looked like that. Could be a mistake. But "Force pixel alignment" is not enough to work pixel perfect. One example. Just resize a shape (dragging on the edge of the selection) and you will quickly get non integer values.

Two ideas to fix this. Not sure if that will fix everything. - "Force pixel alignment" should automatically use zero decimal places internally to avoid any placement outside the pixel grid. Or the setting for decimal points should be accessible in the snapping panel. - Non integer values coordinates should always be shown, maybe in a different color when "zero decimal places" is active to show that they are not on the grid.

I'm sorry to say, but you can't work pixel perfect with the "Pixel work" preset without 0 decimal places. Just do a transformation like changing a shape size via mouse and you get non integer values quite quickly. To summarize: Option 0 decimal places for px seems to fix all actions for newly created items with the mouse. But the inspector still has fundamental issues. Like you said, it hides the problem. But it looks like a bug to me. Previously created items do not change to 0 decimal points after changing the option, which is somewhat understandable. A button to quantize all items would be helpful for old and external document. But items with decimal points (line with 1.3px) are rendered with decimal points as a shape (so not in the pixel grid), but in the inspector value display them without decimal points. The value does not show correctly what's rendered on screen. You can still type decimal places with option 0 decimal places. That's unexpected but not a big problem as you have good control about what you type, but then again, the value in the inspector say they have no decimal places. Same as issue above. @Affinity Team. It would be super nice if you could join this discussion. Dealing with basic issues like that is super expensive as you waste hours checking and correcting these things manually, which should work out of the box. Without any feedback or acknowledgment of the problem I think I can't justify keep using Affinity products in my day job.

No, I create assets that needs to work perfect on a pixel grid. And you have all the pixel snap features, they just don't work right. Photo has the same issues by the way. It's not just a Designer problem.

Unfortunately you're right. It's still a total mess. 😬 I think for newly created items via mouse it works quite ok with 0 decimal places. Also for transformations. Great that some problems can be fixed by this setting. But existing items do not snap to the grid after changing the option, which is somewhat understandable. But the big issue is that items that still have non integer coordinates are shown without decimal places but are clearly not rendered that way. And you can still type non integer values, which are rendered like that, but the gui shows integer dimensions (a shape with a 1.4px line is rendered with 1.4px but the transform panel says 1px). I had strong hopes to use Affinity for my gui work and kept using it out of idealistic reasons, but after years of problems which are still in Version 2 I'm currently strongly evaluating to change to Figma or Sketch again. It's just too expensive to run in these kind of issues.