PLMan

The truth is that good business practice is to honor loyal users. So Serif should gave additional discount for existing users. But the fact is that Affinity v2 welcome pricing is appealing comparing to competition products. So there is no disaster but still Serif could be more kind to existing users - even giving them small additional discount. From the other side, it is hard to maintain such additional discount from technical point of view. So let's entertain using new features and improved tools, instead of screaming on Serif.

By "inconsistency" I understand that similar tasks needs to be made in different way. If I can easily move edges of shapes without additional keys - just with mouse, then edges of lines should be possible to modify in the same way. "Consistency" is one of basic rules for making projects of user interfaces in apps.

I understand methods of solving the problem. Report was just about inconsistency.

When line is drawn with pen tool, it can be only shortened or extended without entering into node tool. For shapes edges can be freely edited. I think, that when pen tool is active, user can freely edit position of line edges.

I was not checking with TIFF as I'm not using files in this format.

It's a pitty. Im using outline a lot and every time I need to change default colour and outline thickness. I really think that users should have possibility to create their default environment with all the settings.

Checked, problem appears on local files too.

Sure, I will do this next time I will get this error. Should be soon.

I'm storing them on OneDrive folder. I don't think that it is OneDrive problem as cycling Affinity Photo always solves problem.

Sure, I'm normal workflow is: - drag 2 PNG files on Photo's icon in dock - resize canvas of one of them - copy the other to resized canvas - add some lines and guidelines - save result in afphoto format - close documents - drag 2 other PNG files It is not always, but quite frequently, that after second drag I have message as reported above.

When I resize canvas with picture, then new vertical guides are not snapping to edges of picture. But horizontal guides are snapping.

5 months passed and any progress with solution?

Guide lines visibility is not too good in dark interface. There should be possibility to change their color to red for example. Moreover they should not be visible only in the scope of canvas and on rulers but out to the canvas too. In present version guides at the edges of canvas are almost not visible (only on ruler). This should work similarly when guide line snaps-then red guide line is shown on whole window width/height and it is easily visible.

When user crops image and then will resize canvas the way it is bigger than before, then previous crop area is not preserved. In resize canvas dialog there should be additional trigger which will allow user to preserve previous crop area. When enabled, then additional space on resized canvas should be blank. In present situation user needs to go back, set guide lines, resize again and delete extra elements which become visible after canvas resize.

When I'm saving defaults in Photo 1.9.0 it doesn't preserve outline settings for text. Color and radius default settings are not saved.

Quite frequently I have problem that when I'm trying to open file in Photo 1.9.0, I have "Failed to open file" error message with information that "The file could not be opened because permission was denied". It happens only when I was editing other file and I'm trying to open new when I close previous file and drag new file to edit on Photo icon in Dock. In such situation I have to exit Photo and drag the file again. Then file opens without any problems.

Sure, done.

I have TIF file which was generated by webODM. Affinity Photo 1.8.6 doesn't open it with message that "file type is not supported". The same file opens in Photoshop. In the past I was opening many webODM created files in Affinity Photo. File is 0,5 GB in size.

Great, as this may ruin precise work of using guide lines.

When resizing canvas guide lines position should follow original canvas according to anchor selection. At present time they stay at their absolute positions, which moves them in different places comparing to original place. I think that it is hard to find practical scenario when present behaviour is useful. I my opinion guide lines should follow original content. So if I had vertical guide line at 100px and canvas was 200px x 200 px. Resize it to 400px x 400 px with anchor set to center up, should move guide line to 200 px.

+1 vote. There should be possibility to set default anchor or last anchor used should be remembered

I think that applications should be as intuitive as it is possible. So for such basic things consulting build-in help shouldn't be needed. Otherwise Affinity software will be famous of not being usable without studying documentation. Is this the way Serif wants to go? I think that being second Corel or Adobe is not good idea. Corel was hegemonic leader on this market and how now uses it? Adobe is present king but people are looking for good alternative. So don't behave as monopolist even not achieving such position yet. Users will use Affinity apps if they will be user intuitive, friendly, and efficient. Period.

No, it is not. If initial value was, for example, 127 then macro will not know if user entering 300%, want macro to act as 300% or just as value 381. Of course we can limit usability the way that entering % will always act as % and force user to use additional calculator but why? Moreover such behaviour will make dialog to work inconsistently. In macro recording as forced % and not in macro recording as pocket calculator. Inconsistency is one of biggest UI programing errors. No, it is just example that argumentation about supremacy of Affinity over other app in the matter of misusing terms. Affinity apps are not mathematical nor physics apps so putting % in the list of units will not destroy the world.

I think that you have no experience in programming. Present implementation is unusable in the context of macros. Macro engine will not be able to find when user wants macro engine to use % and when physical value (number of pixels for example). The only logical way of solving this problem is to inform application what user wants. And in such case adding percent to unit list is the easiest way and fastest to use and implement. Moreover such way is logical for users switching from other apps. And if we want Affinity not to misuse terms then, for example, crop tool should be renamed to resize as it allows extend canvas size, not only crop it, right? Instead of being language purists we should focus on efficiency of app use.

Still will help as there will be way to easy, logically enter resize values.