Lucaspchara

For me there have been many bugs when I work with symbols:
1. when they have an image with mask, if i copi it it broke the program
2. if I have text in the symbol sometimes it does not update for all
3. if you copy a symbol to another file when you resize it it brokes the program
4. others that I did not identify why...

I can confirm the Text updating in the symbols which seems to randomly work and not work sometimes. Another weird behavior regarding symbols: if I have a symbol inside multiple parent symbols, if I delete it from one parent symbol it disappears from the other parent symbols as well. If I hit Undo, only the current parent symbol gets the removed symbol back. This bug is the same in the stable 1.5 version as well. Hopefully the Symbols will get improved cause they are a real headache right now!

I discovered a trick to export an .Affinity file into .PSD while maintaining the possibility of editing text.
 
Lets go. It's quite simple:   1. Save your file in PDF (for export) 2. Open in Illustrator and export to PSD (while retaining text editing)   Ready! Simple right?   Here's a video showing you step by step.   It is worth remembering that some things can get lost but if you simplify the Affinity file it will get easier to turn it into PDF and then PSD and keep all fonts editable. In my tests I had a group of texts inside a layer with opacity and this was lost, but if I take this text from the layers it is possible to keep editing (the video shows some tests)   https://www.youtube.com/watch?v=f-p3J1umYIg

I came here to ask precisely this question as I noticed it was rasterising the layer. I'm not sure whether the most common use case would be to rasterise or not, but for me it seems logical that you would want to use non-destructive methods on embedded documents. Could the assistant switch to live filtering if you try to do a destructive transformation on an embedded document, with the option to switch back if you were actually going for destruction?
 
I mean, I can always rasterise manually before transforming, if that's what I'm going for.

Actually even with snapping turned off, the "whole pixel" move and alignment do not work correctly.
 
If an object is at 36.1pt, it will move by 0.5pt and not check if the object was pixel aligned in the first place.
Basically the code supposed to align objects is just doing +-0.5pt when you check the options. Not smart at all.

Pixel alignment is not perfect in Affinity Designer, in fact non pixel align situation is VERY EASY to happen.
 
When shapes align to TEXT object or, a integer position&size shape with a little ROTATION, it's position no longer integer.
 
I think AD should learn from Fireworks pixel alignment design, no matter cursor position, text/shape geometry, once user start to draw, all  objects' bounds should be treated as integer in pixel alignment mode.
 
Now we can turn off "snap to object bounding boxes" to make this happen, but it also make AD become useless, I think what we need is  "snap to pixel-align bounding boxes",

I'm a Web developer and director of a small Web design agency, I believe I'm not alone when it comes to use a good photo and vector software in Linux. Right now everyone has to swicth on and off from one OS to another because some things we need a design software. Its painfully, and tedious. You guys can crowfund the project and let us know! Believe me, everyday it passes, there's more people that need Linux compatibility. The thing is there are users like me that use Linux because is better for Web development, not because is free. Kickstart the project and you will get a nice surprise, I'm confident that you'll get more that 500k because there is actual need of it. You have my word I make sure all my team use Affinity and we would be very thankful for that. What you have to loose? Crowfund now!

Ahhh! I can totally feel you! I keep pressing Cmd+Enter to exit the text editing mode and by the time I discover my error, I have to rewrite the whole text!

I'm sure somewhere on this whole forum is a big discussion about Affinity Designer's decision and recounted inconsistencies about how it handles SHIFT + <resize object>. I'm sorry if I've tread into an already well-debated topic with a new thread.
 
While I believe the original Affinity idea and implementation is that proportional resizing is almost always used so it should be the default (therefore SHIFT + <resize object> performs the action non-proportionally). However, I find the implementation across different types of use cases in AD is extraordinarily inconsistent.
 
In fact, when I try to recount the different use cases, I can't remember if they scale proportionally or not because of the inconsistencies and variety of use cases.
 
At the most basic level, it seems really inconsistent that a group is sized proportionally, but a shape (rectangle, circle, etc.) isn't. Turning a shape into a symbol then makes the default resizing action behave proportionally.
 
Layers and groups are symbolically the same, so their resize behaviour seems the same too. However an artboard (effectively similar as it holds objects) is not resized the same as a layer/group (holding down shift and resizing the artboard does it proportionally).
 
Images and text are sized proportionally. Drawings (i.e. with the pen/pencil tool) are not sized proportionally.
 
If the default proportional resizing action is to <resize object> WITHOUT holding down shift, then it should be carried across all use cases, making holding down SHIFT + <resize object> resize  non-proportionally.
 
User experience-wise, I don't like having to keep track & adjust for the inconsistent behaviour — it is not intuitive nor consistent and causes friction. I just want non-proportional resizing when not holding down SHIFT, and when holding down SHIFT for the resizing to be proportional. Is it possible to have this as an option in the app?