Jump to content

Friksel

Members
  • Content count

    182
  • Joined

  • Last visited

About Friksel

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. @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!!
  8. Thanks @walt.farrell . That's unfortunate, but thanks for the warning. I stop trusting it and putting it off for now.
  9. 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!
  10. Friksel

    [AD] bug-list (split)

    Thanks a lot @>|<! That other fill mode is indeed working. I have to look for some description online on those fill-modes, 'cause at the moment I don't know nothing about it and it seems to be pretty important. When creating a new document in Designer, adding two rectangles and add them using the boolean operation the fill mode is set to 'Alternate (Even-odd)', so that's the right fill mode for such operations? So I wonder why my blue shape was set to the other fill mode. Any idea on that? I never switched fill modes myself. On the other hand, I once created this graphic in Illustrator and imported it now from .AI into Designer. Could it be Illustrator set it to that other fill mode somehow? Or could that also be done by the import? Anyway, I have to read more about that fill mode. Thanks again, you are king! This really helps a lot!
  11. 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)
  12. Friksel

    [AD] bug-list (split)

    @Sean P To come back to 'BOOLEAN OPERATORS 1. Bugs: Sometimes boolean operations don't work anymore since the last update (1.6.123)': Today I had the problem with the boolean subtract again. Look at this example (don't look at the layout, I just did a raw strip of the original layout to eliminate the problem/complexity as far as I could to leave as little as possible to illustrate the problem): subtract-issue.mp4 Steps to reproduce this: 1) The purple parts are simple shapes taken directly from the toolbox. The top is a circle and the bottom ones are rectangles made round with the rounded-corner tool and than converted to curves. After that I selected all purple symbols and merged them by using boolean add. It feels a little strange to use add on curves that are not overlapping, but it seems like underwater Affinity creates some compound path?! Anyway, it looks perfectly fine to me so far 2) Than I select the purple 'curves' and the blue 'curve' and hit subtract 3) As you can see everything gets subtracted from the blue shape, except for the circle 4) Now undo and change the blue shape a little by removing some vertices on top and try the same 5) Sometimes we get the same issue (the circle doesn't get subtracted), but with certain vertices removed suddenly now the circle does get subtracted, but the other shapes are not... Which doesn't make sense to me, because the blue vertices are still on top of the purple parts and the blue clearly covers the purples without any complexity or whatever. I get the feeling this has got something to do with shapes not being well made, or not closed or something. But that doesn't seem to be the case here. As far not that I can see. These are just normal shapes and pretty simple ones. There is also no strange complex overlapping going on. I've tried this in both the current afDesigner version (1.6.5.123) as well as the latest beta (1.7.0.188), but both versions are having the exact same issue and show everystep you see in the video exactly the same. I'll include the afDesign-file. Hope this helps!! Then there's another thing I wrote in the list: 3. Bug: Don't know when or why, but sometimes the transformpanel of a group is disabled. Lately I found out the transformpanel switches it's use according to the tool you use. And that makes sense. So I'm not sure if that's what I was experiencing before, but it seems like this is what's happening: when the selected tool is the anchor-tool the panel gets 'disabled', because there is no anchor/node selected when switching to the tool. In that tool the transform-panel shows the values of a vertex/node/anchor. So probably this was my misunderstanding. AffinityDesigner-Subtract-issue.afdesign
  13. Friksel

    Math Functions Not Working?

    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?
  14. I believe we just came to the same conclusion. I found the svg 1.1 spec here: https://www.w3.org/TR/2008/REC-xml-20081126/#attdecls But I think it's pretty difficult to follow at this point. But I found this in the spec: So they refer to the Name production, which is here: https://www.w3.org/TR/2008/REC-xml-20081126/#NT-Name Where these seems to be the rules for ID-names in svg 1.1: Where it indeed looks like we are allowed to use underscores ('_') and capital or lowercase alphabetical characters and some other chars, and even a ':'. But no number to start the ID with. So if I understand this document right the way Designer works right now is the right way indeed. Bummer... I have hundreds of logo's that need to be called by their ID-numbers and it would make more sense to me putting them as just plain numbers under the 'logos' group instead of things like 'logo01', 'logo02' and so on. But if this is the way the spec works... this is the way the spec works and at least Designer is exporting the right way as it seems! That's great to know! Thanks for your help again @walt.farrell !
  15. Good one @walt.farrell. Thanks for that. I didn't know there were differences between naming conventions for IDs between HTML4 and HTML5. That said, we're not dealing with html4 nor html5, but svg spec, so I'm not sure which rules they use (didn't find it yet because the spec documents aren't always easy to follow with all kind of sublinks and all). But if they decided to take id-naming-rules like html4.0.1 in the svg 1.1 spec, then still the svg export renaming of Designer isn't right, because in html4 it wasn't allowed to start with an underscore, because it had to start with an alphabetical character. At least according to this: html4 vs html5 ids and classes Also, not only is HTML4 stone age in internet-ages and no new website build last years should be build in html5, chances are pretty small that people working with SVG on websites now will use the svg inside a HTML4 doc. And even if they do browsers nowadays will probably accept id's by the much more flexible html5 rules anyway and be pretty forgiving. The freedom of characters in ids is actually pretty great in html5: there are some keywords and little characters (like '#', spaces, '.' and some others ofcoarse) we are not allowed to use, but next to that almost everything is allowed, even pretty weird characters.
×