max1josef

What a coincidence! Only last week I started working on old SVG-Files with Affinity Designer, but soon I switched to Inkscape. The "philosophy" behind layers seems quite different between Inkscape and Affiniy Designer. In Designer levels are used more inflationary and even operations like adding two objects are obviously regarded as layer operations (Menu: Layer -> Geometry -> Add). My workflow is more about building a well thought-out layer hierarchy, which is not as comfortable to handle in Designer as it is in Inkscape.

Thank you Affinity Team for making this possible in Version 2.6 👍!

I would also have several use cases for this function, e.g. a catalogue with a QR code next to the product information.

I don't see a limitation to 32767 pixels, when I look at the official specs: https://www.w3.org/TR/2003/REC-PNG-20031110/#11IHDR If I'm not mistaken, the permissible image dimensions are 4 294 967 296 x 4 294 967 296 pixels (2^32 for a four-byte unsigned integer). Even with four-byte signed integers, it would be far more than 32767, namely 2 147 483 647 x 2 147 483 647 pixels (2^31-1). So, where is my mistake in thinking?

And what's more, the warning contains a false claim! PNG files are not limited to 32767 pixels.

If there is such a limitation in Windows... ... why does it not apply to TIFF... ... and why does it not apply to other programs like Adobe Photoshop or GIMP? I did indeed overlook the warning. It really should be more conspicuous.

Please remove the image size limitation (32767 pixels) for png files! I have a 48138 px x 72518 px tiff file that I wanted to export to a png file of exactly half the size (that would be 24269 px x 36259 px). But Photo only saves a 21750 px x 32767 px file without any warning! I can't see any plausible reason for this behavior, especially because saving to a 24269 px x 36259 px TIFF works fine.

You have omitted a word in your statement: Most likely Inkscape's programmers decided to implement good code which Affinity programmers decided to not write. Seriously: I am not accusing affinity of deliberately writing bad code, but rather of lack of time and prioritizing other tasks. This is just a suggestion to the Affinity team to improve the "deleting nodes" issue. Nothing more and nothing less.

As I wrote As far as I observed, designers "fit to curve"-functionality doesn't handle sharp edges at all. ", don't you think I haven't already tried that? The problem with this is, that not only the nodes to be deleted have to be smooth, but also the neighbouring nodes, which influences the shape of the path outside the affected section (turning straight lines into curves). @Old Bruce I don't know what you're trying to say. Inkscape proves that it is possible.

I often have to deal with polygonal pathes, which represents curves*). Look at this comparison between Designer and Inkscape**) (there is a red copy of the line to visualise before and after): As far as I observed, designers "fit to curve"-functionality doesn't handle sharp edges at all. Am I right with this observation? Are there plans to change this? This would turn Designer from an almost perfect to a perfect map drawing tool! *) the pathes are derived from openstreetmap which has no real curves. So all curves are approximated by small straight lines which results in a large number of nodes, which I'd like to reduce. **) In case of Inkscape make sure that "Deleting nodes preserve shape" is selected in the preferences.

I didn't know about the meaning of the path field... The user interface of the export persona could take some improvements anyway: easy copy/paste of settings between slices or duplicating of slices easy inclusion/exclusion of layers per slice fix the following: if one exports only certain layers the background will always be transparent, independently of the setting in the document menu a variable for dpi (which takes the value of the Export-dpi field or the source-dpi x scale factor) fix the following: scale factor takes only "." as decimal point (no localisation to "," under German speaking environment as anywhere else) and last but not least user variables should be global to all slices. I have managed most of the above issues with templates, but any improvement to the export persona would be appreciated.

There is a path field in the slice properties of photo's export persona. When I enter an absolute path there, like E:\secondary_project\exports it is converted to E\secondary_project\exports i.e. th colon is omitted. When I export this slice, I am prompted for a path. If I chose e.g. E:\primary_projects\export (just confirming the prompted path) the exported file is stored at: E:\primary_projects\export\E\secondary_projects\export Saving the path without drive letter doesn't help, becaus in this case the leading backslah is omitted. "\secondary_projects\exports" becomes "secondary_projects\exports". As a workaround I save relative paths and chose root directory on export.

I was about to ask a similar question (I needed blend mode "darken"), but like many other questions it has already been answered by @walt.farrell. 😉

I would also welcome this feature. Since I use export persona a lot, it would be nice to include this feature there as well. For now, Loukash's suggestion to use Lanczos 3 (non-separable) as a resample algorithm is very helpful.

Wow this works really great and flawlessly! What a savings of tedious editing and time! Thank you so much, you made my day! What do I say, you have made my week, month and year! 😀👍🏆 Some years ago (didn't have Affinity at this time) I tried the same with PTGui panoram stitcher. But PTgui cannot handle images without lens information properly and produced weird distortions. Since than I didn't even think of using a panorama stitcher for this purpose.