leshido

As of the just released 1.7.2, this issue is still not fixed.

As of the just released 1.7.2, this issue is still not fixed.

As of the just released 1.7.2, this issue is still not fixed.

I guess what I was actually talking about is "Force Pixel Alignment", where "pixels" don't make much sense to me in a Point based document IMO, and would rather be aligning to the Point Grid. Sorry for the misunderstanding! (In any case, @Ben's suggestion for using the grid with 1 pt divisions is a nice workaround, though it does require having the grid displayed to force alignment AFAIK) Thanks!

If anyone is interested, I now just realized a workaround to this: select all images in a Finder window and drag to the document. This acts exactly the same way as the old "place" command used to, placing all images one on top of the other at the exact same location. The first time I tried it, I ended up opening all images as a separate document, resulting in 42 tabs But now it seems to work fine for me. Again, if anyone is interested...

Just as the title suggests, converting a shape to curves removes the slice previously attached to it. This is also true for shapes that have nested content. Steps to replicate: Create a rectangle of any size Switch to Export Persona, and Create Slice from that layer using the layers panel Back to Designer Persona, select the rectangle and click 'Convert to Curves' in the top bar Switch to Export Persona again and the slice is gone Expected: The slice should not disappear. BTW, I posted quite a few bug reports since 1.7 came out, which is only because I want to recommend the whole Affinity suite to my friends so bad, now that Publisher is out. Hoping these issues are fixed soon!

Interesting. I guess I should get used to clicking the 'W' & 'H' labels to set size until this issue is resolved...

In 1.6, it used to be possible to choose "File>Place", select multiple images, and Designer would place them all in the same position automatically, one over the other. This was opposed to using the Place Image Tool, which would have you place each image on it's own one after the other (as far as I remember, hadn't used this tool much). Is this feature of the Place menu entry no supported anymore? In 1.7, both placing methods seem identical and both require me to place each image separately. I used to love the old behavior because it allowed me to quickly import animation frames and export them through Affinity to all sizes I need them (x1, x2 and x3). Was this an intentional change or a bug?

Hey, When designing for devices with high DPI, I use Points as document units, which is also the default option for these kind of presets. To keep items nice and crisp when exporting at x1, x2 and x3 resolution, the objects need to align with the Point grid (which is equal to 3 pixels in my case). However, choosing "Snap to Grid" in snapping options only forces them to align with the Pixel Grid, making objects sit at awkward positions such as X.667pt or X.334pt. I then need to manually make sure they are moved to a whole point value. Would be great if "Snap to Grid" would honor the document resolution in such way that object are easily aligned with the Point Grid.

Hey @Hangman , Interesting this issue isn't happening to you. I get the exact behavior as shared by @Old Bruce. Here is a video demonstration. Notice how in the second shape, I enter a specific value which is then overridden by some arbitrary number. Also verified this is happening on two different Macs I own, so this is definitely reproducible. The AD version is from the App Store if that makes any difference. AD_transformbug.mov

Moreover, after testing for a few more use-cases, the Transform Studio seems utterly broken. Sometimes the values appear to change in the panel, but have no effect on the actual object. Other times, the values change but when moving to another field in the panel the change is reverted. All of these issues also happens with X and Y of course. 1.6 had none of theses issues.

In my workflow, I'm constantly making sure items are aligned to grid by using the Transform Studio and verifying the X&Y coordinates and the Width&Height values do not have a decimal point in them. This is usually done by placing the cursor in the respective text box of the Transform Studio and pressing the Up/Down arrow which causes the number to round to the nearest natural number. In the latest version, there's a very annoying bug which causes the second value changed to jump to a seemingly arbitrary number. Steps to reproduce: Open a new document Create an ellipse of any size (do make sure the width and height values are NOT equal and ARE fractions) In the Transform Panel, click the Width text box and press the up arrow. the value should round to a natural number. Click the Height text box and press up arrow again. Expected: The value should round to the nearest natural number. Observe: The value changes to an arbitrary (non-natural) number and the circle is transformed. This also happens when a value is entered explicitly, after pressing enter to commit the change, the value jumps to an arbitrary value. However, I can confirm this does not happen for objects with an equal height&width, like a perfect circle. Please fix this bug soon, it makes basic workflow tasks very annoying!

Hey @Hangman . Yes, the slider does work as your video clearly shows. However, I'm referring to the label, meaning the word "Corner". In other similar controls (the word "Opacity" in the layers panel for example) you can scrub the word and change the corresponding values.

Unlike other controls in the contextual top bar, with a rectangle selected, scrubbing the label for "Corner" does not change the corner radius. Other control labels are working fine as far as I can tell. I believe this is a regression from 1.6, but I'm mostly relying on muscle memory here...

Thanks @Sean P , I am aware of the icon next to the eye in the Layers panel, however currently these two icons seem to have largely the same functionality, and both cause the exported layer to behave as if the layer had 0% opacity when exported. So just to verify, you are considering this as a bug, right? It should be possible to export a hidden layer?