Patrick Connor

Agreed, it's hardly ideal

If it's the last thing you did, you can undo, as selections are part of the history.

Those files have absolutely no data in them (only zeros 0,0,0,0,0,0,0,0,0,0,0,0... etc). As MEB says we need to find out why your saving process is not working, first by saving somewhere easy like the desktop.

ahhh, sorry. We will see

MEB, looking at Petar_MK's footer, I think he means the Windows Photo Beta....

drewbeck, Welcome to the Serif Affinity forums. :) Thanks for your input and support for this feature.

That currently requires owning Photo 1.5 to create the warp "template" that can display the embedded designer document, but I think it may lead to some cross sales, and show people the power of both apps combined. Indeed we should make a series of videos emphasising the benefits of owning both products. Our guys are very busy with release videos for Photo 1.5 and Windows Designer, but I will mention it to them.

martynh, Welcome to the Serif Affinity forums. The iOS kit is the first ready made content that we have made for the new Assets feature. I'm sure it won't be the last. And no you are not the only one who thinks this is a good idea, see the 3rd post in this thread for example https://forum.affinity.serif.com/index.php?/topic/26045-ui-templates/

reza55n, Welcome to the Serif Affinity forums. Thanks you for your clear report. I too found this last week and reported it to the development team to be addressed in a future build.

Funny, but as Ben says, it's not those that know the difference that need the option, it's those who don't (who are in the majority) and would never set it. It's exacerbated by some printers demanding images are submitted at specific 'DPI' or higher (rather than PPI) . They of all people should get it right. Perhaps I have been working with home users for too long, but I know what they come to the forums and ask, and it isn't "how do I export at 300PPI?"

It should be and I'm sure it will be added at some point. You should simply apply a spot colour fill to the image and get this automatically.

OK, it was a stupid question if it doesn't practically happen.

Please try again being careful when you type your email address, and report back if that still doesn't work, and if not someone can PM you a link.

MikeW, Thanks for your input. I am aware that the X and Y can have differing values, but for the sake of discussion for now let's pretend they are the same. Clearly our programmers have come across this many times, when a files header and it's metadata conflict, and we have to decide which to honour without confusing the user or making the normal process of opening an image arduous. [independent resolutions in X and Y only further confuse, and have not been dealt with well sometimes]. I have always thought that if most other programs honour the misnamed file DPI setting, that users would expect to be able to "control" that in our software, so it is 'clearest' when called DPI (in the app) so we seem to be giving them that option. I totally get that we are not specifying the printer DPI (it's out of our control and printer specific) and that until an exported image is physically placed (on a device/page) we are not actually "controlling" the PPI either, merely hinting at it in the file. To ignore what users think they are looking for (DPI) and re-educate (to PPI) is laudable so I understand why it's being asked for..

The Gradient Map work around by Lee D above is just that, and is not ideal, as it will not export as a single Pantone plate. It may be better to set the right hand node to a 0% tint of the Pantone same swatch on the left, but I have not tried exporting that. I have discussed this with the developers, who accept that the software does not currently lend itself well to a Pantone recolour workflow, as by default it does an (HSL) lightness recolour from black through the colour to white.

@Balling Your explanation is clear for the scenario you give. Putting aside for now what we call the thing in the UI of the program, we also have to deal with real world files and the information that other programs expect to be read from and written to the headers, so please humour me. Do you agree that until you chose to place those 3780 by 1890 pixels at 400mm by 200mm the image itself may have an independent value stored in it's metadata that is in many cases wrongly referred to as DPI but has no meaning, because it hasn't been placed. (the source of the confusion for many) Clearly until you chose to place those 3780 by 1890 pixels at a size of 400mm by 200mm it's effective PPI is nominally unknown. An image file itself may be from another source and have a value stored in it's header/metadata of DPI and/or PPI. This PPI and/or DPI value can be overridden/ignored if it is placed at another size, but at least gives a hint as to how it could/should be 'placed', meaning we are treating this stored value to mean it's PPI. I'm curious, if a file has DPI tags and not PPI should we, in your opinion, assume it meant PPI, If it has PPI and DPI tags, should we honour one and not the other for placement, and if so which? I can imagine a scenario where both exist but we read PPI tags and the only one that the user can control in their software is DPI, with all the confusion that would cause In your experience which one does the other software you use honour, in terms of file resolution declaration? Does it honour the PPI tags or the DPI tags when both exist in a file? and what about when only DPI exists, (the most common case).

Yes it does.

Agreed AdamStanislav, Nat has made this post in the equivalent forum thread, with his recommended viewing order for the new (6 Oct) tutorials. It would be astonishing if they weren't but perhaps complacency has set in.

No they are independent and you can uninstall the trial with no affect on the beta build, as MEB says.

It was there hidden by a bug in the forum code

What sort of text, artistic or frame and what "editing" ??? (typing, deleting, formatting, copying, pasting, scaling, cropping, recolouring, I could go on). Any recipe would help.

You're welcome. PagePlus 7 onwards, but it's a pretty long time, yeah

Your files created in the old beta will open up in the new beta. You can proceed, yes. The only ever exception might be if we messed up big time and had to change one of the unreleased features so radically that beta files couldn't be honoured. If we did this we would make it very very clear in the Beta announcement. We have not had to do this AFAIK, but knowing that possibility exists is important, so you should not to use it unaware for real work in case we have to change things radically. Once formally released we would always promise to load the files saved by the sold application. As Affinity Designer 1.5 for Mac is now public, I can't see any circumstances where the existing Windows 1.5.0 beta files wouldn't work, as they share a common file format.

I think we should leave the initial launch offer to the marketeers, but it would be fair to offer parity on price and the content give away. Not long to to wait and see....

No other steps Michael, I thought you were sent it shortly after the email address was submitted, but I have not tried myself. Perhaps someone who has done it can comment. We will PM you a link soon, though it may be Monday, sorry