joro_abv

@Dazmondo77 There you go another pretty good example of what we're talking about and how it is used (although I'm pretty sure everyone knows what it is) :

Yup, I also think a voting system for new features would be the most fair way to prioritize what to implement next. But again - free transform is really basic, essential tool, doesn't mentioning it is available even in Affinity Photo, but not in Designer.

Hi, I was trying the isometric studio in the latest beta, in an effort to use it as e replacement for a real "Free transform" tool and ... well ... it does not cut it ! It is hard to use and with a result very far from precise enough to replace a real free transform and distort of an object. So, I'm trying to rise this question again - when do we get a real "Free transform" tool in Designer (both vector and pixel) ? Since basically every other tool on the market including Illustrator and even the now dead Fireworks has it, I guess it is not that hard to implement, for vectors at least.

Android P announced with HEIF support too. This thing is getting popular now.

Yup, I have - a small shell addon called "SVG Viewer Extension". But when I associate the SVG fromat with Designer it stops working for some reason. Designer has support for it's own file format thumbnails and since SVG as supported, but lacks native OS thumb preview support, I though it would be nice to get one from the Designer itself.

Anyone ? ... at least a "Won't happen" or something ... ?

Hi, I'm realy enjoying Affinity Designer on Windows, but I"m missing a feature. For me it is very hadny to have previews of my files in explorer, but since I asscoiated the SVG file type with Designer, I can no longer have them. So, I'd rather suggest to add support for this.

O-o-o-okay ... so ... a few things : 1. Google Speed Insights is useless to say the least, BUT the score there affects your page ranking. And 5-6 bad images on your home page can halve your speed rating easily, so I do give a damn about it. 2. Here a bigger sample test (a sample comming from a randomly downloaded EPS file imported in both apps) - Designer : 874.64 / 749.78, Fireworks : 3295.76 / 475.75 ... so there you go - 300Kb difference and again Designer is almost twice Fireworks. Quality is comparable (no gradients). 3. As of quality ... and I maybe have to create separate issue about it - rasterized linear gradients in Designer suck. They get some jpg compression-like noise/dithering.This is ported (of course) in the resulting PNG files. It is not like visibly worse, but it is there and I don't believe any setting can improve it.

So, here go the results : Designer : diagonal gradient - 7.91 / 6.84, no gradient - 7.74 / 6.41 Fireworks : diagonal gradient - 64.66 / 3.19, no gradient- 64.36 / 1.75 Designer from scratch : 7.46 / 5.51 Fireworks from scratch : 53.24 / 1.73 ... obviosly not very promissing. Seems I'm wrong about the bad gradients handling affecting the file size (although the bad gradients issue remains). On other hand - doing some ideantical drawings from scratch does not make it any better too ... even worse - optimized Fworks goes like over 3 times better size compared to optimized Designer from scratch. Now, I agree no one can beat Fworks in its own game, but 3 times bigger ... there must be something not quite right or at least definitely room for improvement. Again - I'm not trying to argue just for the sake of it. This is a real life, practical and serious issue, as the results do not make Google Speed Insights happy at all, so it affects any webdesigner that need transparent images, having that PNG is the only option (apart from SVG, of course). Unfortunately, I very often use the same image for several purposes, like Facebook etc., so SVG is not always the best option, while PNG is widely supported everywhere.

I doesn't matter for me at all if it is 3.5 or 3.2, but it matters for Google Speed Insights and it lowers my scores, which does matter :-). Anyway - as you can see from my post above - I probably narrowed it down, but will also try what you suggest - identlical files from scratch in both Designer and Fireworks ... results to follow :-).

It is not indeed. But anyway - I just gave it a try to check would it make any difference. You should look more to the results from my first post. I think I know what could be wrong, though. Actually I narrowed it down to the following very simple test : New file, background black, add rectangle with vertical linear gradient from white 100% opacity to white 0% opacity, big zoom in - perfectly smooth ... now rasterize the rectangle ... :-(. The result is a unevenly dithered/noisy, which means the rasterizer deals with the gradients in a horribly wrong way at first place. I would inderstand dithering for a diagonal or radial gradient, but not for a perfectly vertical linear one. So, my understanding is that the whole thing goes wrong from there. I mean - dithering definitely leads to weaker lossless compression, hence - the bigger end file size. There might be more issues, but I believe this is the most significant at first place. When I have the time, I will make some tests with a diagonal gradient and without any gradient on back, to check if Designer would get any closer to Fireworks and will let you know the results. If it get's closer (espcially without the gradient), then that must be the culprit ... but we discuss further, when I have those results.

... and this is how the gradient comes from Designer, as it looks worse in the PSD too.

Ok, but I don't believe it's a matter of optimisation. I think something's wrong. Why ? Example (that I just figured out) : Fireworks -> save as PSD - Quick save as PNG from Photoshop : 2.53 / 2.27 Save for web from Photoshop : 2.4 / 2.27 Designer -> Export as PSD - Quick save as PNG from Photoshop : 5.87 / 5.14 Save for web from Photoshop : 5.47 / 5.14 The image actually have a background gradient that fades from color to transparent and here comes the BIG surprise - the Designer sample is not only twice as big, but also the gradient have some JPG-like compression artifacts that makes it look much WORSE than the one coming from Fireworks.

A small update how I achieved the 2.37 KB png. The source is actually 250x250 px. So, optimizing directly the original 80KB source fireworks file, then resizing it with php to 100x100px and then optimizing again the resized result, gives a file that is just 2.37 KB. ... which, of course, simply means, that if I resize the vectors (and canvas) directly in Fireworks and feed the result to the optimizer a 64KB source file result the even more stellar 2.24 KB :-).

I'm trying to migrate all of my work from Adobe Fireworks to Affinity Designer and I'm hitting a major show stopper. Since I'm mostly a web designer, the size of the output files matters a lot for me. Now, here comes the issue, that Designer creates drastically bigger output files than Fireworks. I'm giving an example with a 100x100 image. It was initially created in Fireworks, then saved as PSD and this way - ported to Designer. Results (original / compressed with optipng and pngout) : Designer export directly from vector (no ICC embedded) - 9.69 KB / 6.41 KB Designer resterized (no ICC, no metadata embedded) - 6.83 KB / 5.85 KB XnView from Fworks source png - 3.61 KB / 3.41 KB Fireworks save to flat png (compression - 9) - 3.51 / 3.15 KB PHP resize and save from Fworks exported png (compression - 9) - 4.42 KB / 3.07 KB (this one is really odd :-)) I also have some old 3.30 KB flat file from Fireworks, that optimizes to tha fabulous 2.37 KB, but unfortunately I can't remember with what approach I squeezed it out of Fireworks. Have in mind those sizes are with resulting files that are either very, very close or completely identical as output quality. So, obviously Designer generates files that not only are too big, but also - hardly can be further optimized in to the necessary levels.

Good ! Can't wait ;-). Thx.

Any feedback on this ?

Correct. My fault. Thx.

Hi, guys I have a few recommnedations about how the measures on guides work. Hope you will consider implementig them. So : 1. The giuides show the distance from top/left, but only when you move (edit) them. The measure us not shown when a guide is initially added. 2. Top/Left distance is needed, but also the bottom/right distance is necessary in the same time. 3. Apart from distances from the document edges, actually the distance measures are mostly useful to check the distance to the closest guides on both sides of the current. So, when an adjacent guide is present, the distance to it would be much more useful, than the distance to the edge. Both disance to guide and edge is a bit over the top, so if I have to choose - show distance to the edge in the given direction if no adjacent guide, distance to the given guide otherwise. 4. There must be a way to check the distances without actually touching the guides. A keyboard shortcut or something. This would be really of great help, especially for web and UI design (which I usually do :-)).

And what 'Show Selection in Layers Panel' does, as I can't notice any difference (except the crash :-) ) ?

Any news wether this was accepted or rejected ?

@MEB You can find an example file attached to one of my posts up in this thread. @Chris_K I actually do (see the example file, I mentioned)

I think it is the same as mine here : https://forum.affinity.serif.com/index.php?/topic/23886-locked-objects-prevent-drag-to-select/

Yeah, it works ! Thanks for the advice. But where the difference comes from ? In some files this works as intended (locked background not mouse selectable), in others (like my example) it get's selected. Is it some bug, or there is some detail that I'm missing ?

Ok, that was quick, but there you go - the attached file behaves as I described in a very stable way with beta 12. At least at my place, when you try to drag over the locked background it gets selected and the drag-to-select doesn't work. untitled.afdesign