fde101

No, you should change your entire system for your entire system. That way everything is consistent, if the apps are responding the way they should be to the scale. If an app provides an option to adjust its overall scale independently of the OS setting, it is in effect giving the user the ability to make things inconsistent, and that by its nature is a misfeature. Providing an option to adjust (for example) toolbar size relative to the OS scale makes sense and would be reasonable, but to scale the overall interface differently from the OS setting is a bad idea. Apps which provide that option rather than following the OS setting, or which do not follow the OS setting correctly, need to be fixed. The only possible exception would be something that provides an immersive experience, like a video game, which presents an interface unique to that experience which is by its very nature separated from the rest of the system. In this case the whole point of the application is to let the user become lost in an imaginary world, and it makes sense that the interactions would be tied to that world instead of the real one. For applications that are grounded in reality, however, it is more important to be consistent with other applications which are similarly grounded in reality. This includes productivity and creativity apps such as those from Serif.

Apple is more security-conscious than are many of those financial institutions and they have you logging in using an email address. Not that they are particularly security-minded, but so does Microsoft I think? Whether it is a simple username or an email address makes little difference in this context as any site or service worth its salt these days is going to encrypt it in transit alongside the password, and the forums do not display the email address for others to see, so the chance of the email address leaking is really no different than the chance of some arbitrary username leaking. Behind the scenes they would generally be stored in the same table in some database either way if they were separate, so if a hacker got ahold of one by hacking the back-end, they would probably have the other too. The notion of a separate username somehow protecting your email address from spam is a false security at best. A more legitimate case for not using an email address as a username seems to come from the potential for the email address to change, and the possibility of someone else being assigned that email address after you stop using it. If you are using some email address to log into a site, and your email address changes while you are not actively using that site, then when you try to go back to that site and forget your password, if someone else has taken over the email address, the confirmation for the password change would go to them. In and of itself this is bad, and the same problem exists even if you are using a different username than the email address - the password change confirmation would still go to the registered (now incorrect) email address, probably even listing the username so that whoever receives it then gets a big hint on how to take over your account. It becomes a slightly bigger problem when someone tries to register for a new account using their new email address which happens to be your old one. If they try to register using that email address but the username doesn't match, you might think that would prevent them from taking over the account as they are unlikely to try the same username you picked and it will never match up, but most systems which allow alternative usernames will accept either the username OR the email address for authentication, and those which do not, will often still have a way to "recover" your forgotten username by emailing to the registered address - so if someone gets a message that the email address is already taken when they try to register, they can still recover the username and password and take over the account. In the end, this too leads to a separate username providing false security for most sites.

For the 1.x versions they had four areas: one for questions common to the products and one for each individual product. The problem is that people would post the same thing separately for each product, and duplicate threads would still be created within each product, so instead of 2-3 redundant threads all asking for the same thing, there would be... a lot more than that. Of course, combining them like this does create a different set of problems, as you pointed out, so in the end it is something of a toss-up.

Hi @Blendan, welcome to the forums. This has come up several times in the past:

It doesn't need to be though as its first character can be formatted using the drop caps feature, as I explained above. Ideally the list would be set up in a paragraph style (one for each of "figure", "image", etc.) so that the whole thing can be automated to that extent.

Create a character style All Caps which is derived from No Style. Choose All caps on its Capitals page. In the paragraph style where your numbering is set up, keep the word "figure" all lowercase in the numbering style definition, then on the Drop Caps page, enable drop caps, set both the height in lines and the characters to 1, and choose All Caps as the style.

If the mask was originally applied as a child of some other layer: Drag the mask out from underneath the layer and place it above the layer that was masked. Group them. Place a Curves Adjustment as a mask of the mask layer, and adjust its Alpha (not Master) curve.

That option for PSD is to allow round-tripping with RAW/DAM applications, many of which can work with PSD but not with afphoto files. If you use Capture One, for example, you can have Capture One export a PSD with any enhancements / adjustments you made within Capture One and sent it to Affinity Photo for further editing, then when you save in Affinity Photo, it is updated in the catalog of Capture One, and you can re-open it from within the catalog, keeping your photos organized within the context of the project you are managing within Capture One. Other RAW processors / DAM applications can do that same thing, either with PSD or with TIFF, so it makes sense to support this for those two formats. However, none of them would be doing this with SVG or other formats, so it is less clear why that should be necessary. There are downsides to saving in those formats as opposed to the native Affinity formats - not everything is preserved 100%, and it is slower when saving, so things may be lost each time you save if you are using an option like this.

First of all, this post violates the principle of ONE REQUEST PER THREAD which is spelled out clearly here: https://forum.affinity.serif.com/index.php?/forum/52-feedback-suggestions/ They most likely did and designed the tool accordingly. Not everyone works the same way or wants their tools to work the same way. You will need to be more specific if you want this to have any chance of going anywhere. If I am correctly interpreting this there are a few options already: In Designer you can use symbols. You can also access these from within Publisher by using the Designer persona (if you have Designer), and if you also have Photo, you can access most of the tools of the Photo persona by switching between them within the same app. In Photo (possibly only on the desktop versions) you can save the common parts in a separate file, set your placement policy to Linked, then place the file within the intended document. Updating the original file will then cause those updates to apply to all of the linked instances within the document where they are placed (but you obviously need to keep the linked-to document along with the one in which it is placed). If the "thing" you want to keep copied is a single layer and not a group or other compound object, you can also use "Duplicate Linked" in Photo to create a copy that will be linked back to the original, and use the Links panel to identify which of various types of properties are kept in sync between the linked copies.

How big would the page need to be for that to be useful at readable point sizes? 🤔

One possible interpretation: Check the status bar for a modifier key you hold down to "force cusps on either end of curve" - you need to be pointing at the segment where you are about to pull down on it to see that modifier. If you are on a Mac, it is the option key. Hold that modifier down while dragging. Another: Convert the node to a smooth node to give it a control handle, then drag on the control handle. You can perform this conversion either by holding down a modifier key while clicking on it (control on the Mac), or by selecting the node and clicking the "Smooth" button in the context toolbar.

Publisher has that capability as well.

I could kind of see this with the pen tool, but if the option were set to NOT retain the selection, you would only be able to deselect a stroke after closing it. If you are creating open paths, you basically need to deselect one in order to start another anyway, or the tool extends the existing curve instead of starting a new one. Curiously, there is an existing option to do the opposite of this new feature: normally, when starting a new curve, the previous one is deselected; there is an existing option to keep it selected when starting the new one. Sadly, it also breaks up all existing curves when doing so, limiting you to the two endpoints on each curve. A rather strange feature, but I'm sure someone must have a use case of some sort for it.

If I pick one of the other raster selection tools, such as one of the shape selection tools, on the Mac, all four modifier keys are taken: shift to constrain, control to add, option to subtract, command to move layer with selection. The flood select tool only uses two of these, but they are the same as for the other selection tools: control to add, option to subtract. In other words, the flood select modifiers are being chosen to match the same actions on the other raster selection tools for consistency. I believe the right mouse button was used for one of these on Windows due to the fact that Windows only has three modifier keys to work with. This is ultimately an attempt to maintain consistency on a more limited platform. You can already get a more "normal" modifier key for this by switching to a Mac, which has four modifiers to work with. To add support for this on Windows, they would need to drop consistency with the other tools, choose a non-standard modifier key (such as a letter), or remap all of the selection tools and choose one of the other two actions (constrain or move layer with selection) to map to the right mouse button instead of what is there now (or to drop support for completely on the Windows platform). Given that the alternate tool mode is available for this action, and that the constrain and move layer with selection actions are not available in a similar manner, choosing either add or subtract to be the "odd one out" means that the same thing can still be done in that manner for those who have trouble with the right mouse button "modifier", which would not be the case if they picked one of the other two actions.

The plugin API is still a work in progress and is not ready for customers to use yet. Refer to the thread linked above, on Scripting, for various posts explaining this. The plugin API and the scripting API are apparently being developed together, so it seems likely they will be available around the same time, whenever that happens to be.

My understanding is that it preserves the corrections from Lightroom within the file, but does not make use of or update them. I've never used Lightroom (and have no intention of ever using it), so I can't verify, but that seems to be what I am finding when looking around at various places.

As this is specific to certain tools I am wondering if a button on the context toolbar might be more appropriate? Either way I agree that a feature like this needs to be exposed in more ways than just a keyboard shortcut. It should either be in a menu or have a button somewhere that brings it up.

Only for metadata, not for adjustments. The standard provides a few "standard" things that can be stored in the files plus a mechanism for each manufacturer to store custom data unique to their own applications. Adjustment data is not part of the standard, but rather something that is application-specific, so no application really tries to read the adjustment data meant for an application from a different manufacturer. Corel spells this out clearly in their documentation: http://product.corel.com/help/AfterShot/540111121/Main/IT/Documentation/index.html?background_editing.html Other applications only bother to store metadata in the xmp files and have an additional proprietary sidecar for the adjustment data: On1 Photo RAW: https://www.on1.com/products/photo-raw/ideas/idea/switch-to-xmp-sidecar-files/ Capture One: https://support.captureone.com/hc/en-us/community/posts/360009383858-Do-XMP-files-save-editing-information, https://www.google.com/search?client=safari&rls=en&q=capture+one+xmp+support&ie=UTF-8&oe=UTF-8#ip=1) DxO Photolab: https://www.dpreview.com/forums/post/66715331, https://tutodxo.com/en/side-cars-dop-files-and-database/ In order to use an XMP to sync adjustments Serif would need to reverse engineer the adjustment formats of each manufacturer that actually stores the adjustment data in these files (and as per those links many do NOT, using their own proprietary sidecar formats instead), and map it onto their own data format, which would still not be a 100% match. Even if they save adjustment data in the XMP, they would need to save multiple copies of it, similarly mapped to multiple other applications (with their custom, proprietary formats that may change between versions and are not likely to be publicly documented anywhere) for those other applications to read it again. There is nothing standard about the way adjustments are stored in sidecars - only metadata such as star ratings, author information, etc.

Sort of. Consider that originally Photo did not even save the RAW edits into the .afphoto file but applied them immediately upon leaving Develop mode and if you went back into that mode you would start over. While they did improve this, Photo permits a range of destructive edits that cannot be represented easily in an xmp file. Use of an xmp file would be misleading as any changes made using tools which are not easily reflected in such a file would either need to be stored using a custom format that no one else would understand anyway (eliminating the portability benefit you seem to be looking for) or would be missing entirely from the xmp. Even if it did, you would only get an approximation at best of the adjustments that photographer intended. Different programs apply these values differently. Just because the XMP files transfer values between them, those values will produce different results in different programs which use different algorithms for similar tools - you would not get the exact look the photographer intended unless that photographer was using the same software you are. You would still need an exported reference from the photographer to compare against to finish adjusting the values to match, and even with one, you may only get close, as one program may not be able to 100% match the output of another unless you recreate the image pixel by pixel. If the photographer had already made the appropriate adjustments on the RAW image, he should have exported a high-color-depth, full-resolution version as a TIFF or PNG file and sent you that as a starting point. As long as he got close to the final results of the RAW development process, any adjustments/changes you would make from there probably would benefit little if at all from restarting the process from the original RAW. Note also that the original purpose of XMP was not to store RAW adjustments, and the storage of RAW adjustments is mostly in the form of extensions that vary between programs (and thus their interpretation will vary or will be omitted when transferring them between programs). The original (and portable) purpose of XMP (whether embedded in an image file or present as a sidecar) was to carry custom metadata such as title and author information - not image adjustments, but textual information for cataloging/identification purposes.

"Linked" means that the .afphoto file references the original RAW file by its path rather than copying the RAW data into the .afphoto file. This saves disk space but also means that if you ever move or rename the original RAW file the .afphoto will need to be relinked to the new location or name; if you ever try to send the .afphoto to someone else you need to send the original file along with it. This has indeed come up before but it doesn't really make sense for the type of application that Affinity Photo is. Those sidecar files are more relevant to dedicated RAW developers and DAM-style tools such as Capture One, On1 Photo RAW and the like. An .afphoto file with a linked RAW layer is probably the closest you can expect to get to this type of workflow when using Affinity Photo, the major difference in practice being that you need to open the .afphoto file rather than the original RAW file in order to get back to where you were. Does Photoshop seriously use sidecars? I would not expect that. ACR (camera raw) is bundled with Photoshop and uses sidecars but it is not Photoshop - it is a separate application designed to integrate with Photoshop. ACR is a dedicated RAW developer for which a sidecar workflow makes sense, but Affinity Photo opted to integrate basic RAW development into their otherwise Photoshop-like application instead of implementing a separate development tool, and a sidecar workflow doesn't really apply to Affinity Photo any more than it applies to Photoshop. Wrong type of application.

The more relevant factor is how many of them will fit on your display when you are zoomed in far enough to see them. Boxes scrolled out of view won't matter much.

That is unlikely to help - gimp is in the same category of software as Photoshop and Affinity Photo and will have the same workflow issues if you are looking for something else. Nothing wrong with gimp, just as there is nothing inherently wrong with Affinity Photo, but from what you are describing it is not what you are looking for. Try RawTherapee or DarkTable instead. Those are both free/open source and are more likely along the lines of the type of software you are trying to find. https://www.rawtherapee.com https://www.darktable.org

No. Agreed.

Correct. V1 was a one-time purchase, and you don't need to pay again to continue using V1. V2 is a one-time purchase, and if you have purchased a V2 license you don't need to pay for that license again to continue using V2. In other words, this is a perpetual license, not a subscription.