fde101

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.

A dedicated RAW developer / DAM tool / organizer such as Capture One, DxO Optics Pro, or On1 Photo RAW is a good place to start when you are working with your photos. For culling, initial RAW development, organization and basic image enhancements, they will generally provide a much better workflow than what is possible using a single-image-editor such as Affinity Photo / PhotoShop. However, you will eventually run into a few images here and there which will require more careful or direct editing than is realistically feasible in those programs. Then you would use the developer/DAM to do the basic enhancements it does well, and open the resulting image in an actual editor such as Affinity Photo to take care of the finer detail work that programs of this nature excel at. In spite of some apparent overlap, they are complimentary tools - neither is a particularly suitable replacement for the other.

If they don't get it done before then, this would probably be a relatively easy thing for someone to do with a macro once that feature is available.

This has come up before. There should really be a command to convert an embedded document directly into a group.

This is highly debatable: https://ux.stackexchange.com/questions/30682/are-there-any-recent-studies-of-the-keyboard-vs-mouse-issue People feel like they are working faster when using keyboard shortcuts, but in a great many situations, if objectively measured using an actual clock, using the mouse actually turns out to be faster in practice. There have been studies in the past which prove this out. Note that I am not saying it is true across the board - there will obviously be exceptions - but it is definitely true more often than most people realize.

A few existing options in the meantime: Drag the eyedropper over the swatch As you are on a Mac, look at /Applications/Utilities/Digital Color Meter Also as you are on a Mac, go to System Settings -> Accessibility -> Zoom and try a few of the options there, for example: Enable Use Keyboard Shortcuts to Zoom Set Zoom Style to Picture-In-Picture then click Size and Location to choose where on the screen and how big an area you want to see them in Click Advanced and turn on Keep Zoom Window Stationary Use Command+Option+8 to turn it on. Point to the middle of a swatch and tree Command+Option+"=" repeatedly until the swatch color fills the zoom area on the screen You can now toggle the display of the enlarged swatch using Command+Option+8 Note that screen colors may not match print colors, and colors may not always match 100% between displays, particularly if any of them are not calibrated or are prone to be moved between differing lighting environments.

This has been requested many times.

This is normal and expected behavior for floating toolbars on a Mac (for the style of windows that these are). Practically all standard Mac applications with floating windows like that behave this way. Those windows are not usually relevant when working in other applications so they get out of the way to avoid obscuring the interface of the other applications - it prevents them from blocking access to the other apps' windows and controls. From what I gather it is also happening on the Windows version which is likely yet another flaw in Serif's interface design as it is not a typical or expected behavior there. Mac apps should look and behave like Mac apps (more elegantly and sensibly, staying out of the way and letting people get things done); Windows apps should look and behave like Windows apps (more disorganized and confusing, getting in the way of what you are trying to do). When companies try to make things look "the same" on multiple platforms, they typically wind up creating a product that is inferior on all of them, generally in different ways.

They should really take a cue from QuarkXPress on this one. You can, for example, set up an object style with a horizontal position and width so that applying it to a text frame places that frame in a specific column or within a margin, while at the same time setting its line style and the like...

If you are on a Mac and have Keyboard Maestro, as a workaround, Keyboard Maestro has a feature which will search the screen for an image (take a snapshot of the button) and click at some point relative to that image. If the button is at least on screen and stays in a reasonably consistent place, you could set a search area around that and code a macro to click the button for you when you use a key sequence. It is not optimal, but it is something.

You can combine the first two steps using a third-party macro utility (such as Keyboard Maestro on the Mac). The tricky part is that the spacebar would need to be held down if I correctly understand the request. If you deselect the items instead, then the entire request could be handled using that technique.