fde101

This is hardly unique to Serif.
Most companies license 3rd-party technologies to use in their major software packages, and they all impose limitations of various kinds on what can be accomplished.

That was something which I forgot to add to my earlier post, thanks for mentioning it; I’ve fixed my earlier post now.

I watched that project for a while and I don't believe it was ever completed.  It was a perpetual work in progress until everyone finally gave up on it.
 
 
EDIT: http://www.xaraxtreme.org
Note that the porting was "almost complete" as of the latest update in 2008...

I just checked QuarkXPress and VectorStyler, neither of them behaves in the way the OP is describing.
The ESC key clears the selection, but does not change tools.
That is the behavior I would expect.  Changing tools is not a "normal" function of the ESC key in professional software.

I just checked QuarkXPress and VectorStyler, neither of them behaves in the way the OP is describing.
The ESC key clears the selection, but does not change tools.
That is the behavior I would expect.  Changing tools is not a "normal" function of the ESC key in professional software.

Blender is a great example of a program doing a terrible thing.
It is ignoring all OS conventions and rolling its own user interface, making it inconsistent with EVERY operating system it runs on.
 
The only legitimate reason it could possibly provide for that is to ensure neutral grays for more accurate color judgement.  That is the only reason that I would give it credit for, as most operating systems are lacking in providing for this requirement.  I consider that a flaw of the operating systems which should be addressed so that applications with critical color judgement requirements can inform the OS as part of an application manifest or an API call and the OS would provide an appropriate neutral gray appearance which is otherwise consistent with the rest of the environment.
 
Other reasoning I have encountered is generally misguided.  In particular, many developers cite a desire to keep the application consistent between operating systems.  The problem is that a user of a computer is likely to use multiple applications, and it is more important that they be consistent with each other than that they consistent across operating systems - someone sitting at one computer and trying to use four different applications will find things that work four different ways and trying to juggle them while switching back and forth is not a good thing.
 
Don't get me wrong, I have blender installed all over the place and use it from time to time myself - it is a great program in terms of the functionality it offers - but the situation with the user interface is something that should not be emulated, except by video games and other immersive environments.
 
The use of configurable panels to lay out controls appropriately for the task is definitely a good thing.  This is one area where Apple is making a misguided recommendation to avoid this.  It makes some degree of sense for consumer-level applications to limit options to some degree, as more casual users may easily get lost wondering where something disappeared to when the visibility and positions of panels are easily changed, but for many professional applications they are largely a requirement.
This does not provide an excuse for the controls placed on those panels to defy OS conventions, including scaling.  Other than the neutral gray issue, there is nothing that would prevent normal OS-provided controls from working in place of the highly custom ones Blender provides.
 
It would be better to design the app in such a way that this is not necessary, but if it is going to provide a global scaling feature, that is certainly the least problematic way to do it.
 
Yes, that is how things are.  It is NOT how things should be.  I think we are arguing two sides of a coin: I am indicating how I believe things should be, you are anchored in the messy situation of the unfortunate way things are (but should not be).
Different UI frameworks would be fine as long as they all ultimately followed the conventions established by the underlying OS rather than bypassing them.

Too late, they are already adding it in 2.6 - the key points being that it is using local processing (not cloud-based), it is being used for object selection and nothing generative, plus that it does require an extra download (the actual models) from within the software in order to use it.
To me, that is the right mix.  The current AI tech is appropriate for tasks like making selections, maybe for setting filter parameters (ex. auto-exposure adjustment or something of that nature), but not for generating content.
If they try to add generative AI to the program, that will be a bigger problem.

Just a thought I haven't fully fleshed out yet, but for obvious cases where an action exactly undoes the previous action, why not treat it as "undo" for history purposes, and where an action exactly matches the action that "Redo" would do, why not treat it as "redo" for history purposes?

I have WAY too many fonts to add them to a context menu.
This suggestion doesn't scale well.
Not sure why someone would be changing to arbitrary fonts often enough to make that worthwhile?
Adding styles to the context menu would probably be more reasonable.  If you set up your styles well then that should work even better than having fonts there.
 
Note also that you can already use the Character studio panel to access fonts and one thing you might try would be floating that panel and placing it near your working area, where you expect the mouse pointer to be.

Mask layers in Photo are raster data and will obviously occupy some space based on the dimensions of whatever is being masked.
However, you can in many cases use vector objects (such as shapes or curves) as substitutes for mask layers, which should be much lighter on the file size.

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.

Where is it going to pull inner bleed from?
If you do not have a "gap" between the pages there is nowhere to place content for the bleed, so the only place it can pull from is the other page.
The page on the left is likely pulling a copy of the leftmost edge of the page on the right, and the page on the right a copy of the rightmost content of the page on the left.
What else can it do if no content has been provided for it?
"Correct" bleed is not really feasible in a "normal" facing pages document.
 
Can't you just skip the first step that was listed?  You would need to adjust each facing pages master used in your document and add a new blank one to any spreads with no master currently assigned.
Note that adding a gap in an existing document will not stretch objects that are entirely on one page into the gap, and objects that span across pages will now have part of their width in the gap, which can impact your layout and content in such cases -you will need to validate that your document is as intended and make adjustments where they are needed.

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.

I believe the OP means to convert an embedded document into a group so that you can access its individual elements without needing to separately open it.  Similar to rasterizing the document, except leaving it as vector content.
 
I agree that this capability is currently missing.

This is hogwash.
As was discussed in a previous thread on the subject (this one is a duplicate), the TIFF file format standard calls for its files to be named with a .TIF extension on platforms that use file extensions to represent the file type, but many applications ignore this advice and use .TIFF instead.  
The .TIF and .TIFF extensions are both used for EXACTLY the same file format.
The TIFF standard offers a number of compression and storage formats which can be used interchangeably, regardless of file extension.  One application might save files with the .TIF extension and use one compression format by default (or as its only option), while another might use .TIFF and a different compression format, but they are both TIFF files.
Some of the compression formats are more suitable for one type of image (such as black and white scans of business forms) while others are more suitable for other types of images (such as photographs).
TIFF files can also be uncompressed.

Yep.  Let's just go back to XPM and be done with it.
 
PNG is quite different from the other formats you are listing, in that it is mathematically lossless, like TIFF, but with better compression for general images.  Consequently the newer lossy formats are worthless as substitutions for PNG.
While AVIF does evidently offer a "lossless" encoding mode, using a format such as PNG, which lacks a lossy mode, clarifies that images in that format can be trusted to be lossless.  If given a bunch of AVIF files you can't be sure without actually checking them.
The compression offered by PNG is easily good enough for many purposes.  We still use TIFF in my day job.

There are practical reasons for some of the newer formats, and AVIF is admittedly one of the least problematic due to its goal of remaining patent-free.
Internet bandwidth costs money when running a server.  So does storage.  These newer formats which reduce the size of the files are mainly for internet distribution, where bandwidth matters.  The smaller the file is, the less bandwidth it consumes, the cheaper it becomes to operate a site.
That said, I think it would be better if the deployment solutions being used for the sites would take some more substantial format (such as PNG) and produce whatever variants are wanted when the site is being staged for deployment, rather than relying on artists to provide a bunch of different distribution formats to account for different browsers being happy with different such formats.

When you created the document and used PNG files, the document became linked to PNG files.
When you deleted the files from the folder, the document was still linked to PNG files, so it is correctly showing them as "Missing" because it can no longer find the files it is linked to.
This is normal, correct, expected behavior.
It will automatically relink to the files if you put them back.
It will NOT automatically relink to files of a different type, as they are distinct from the files that it is looking for.
 
Bear in mind that the file extension, which identifies its type, is part of the file name.
Consequently, file.png and file.jpg are two completely different, unrelated files.  Having file.jpg in the folder means nothing to Publisher if it is not linked to file.jpg; if it is linked to file.png and file.png is not there, then the file it is linked to is missing.  Some other unlinked file being present, even if part of its name matches, is irrelevant, and such files are simply ignored.

In the interim, you may be able to achieve a similar effect using the mesh warp filter, though it will be more manual and imprecise to do so.  
You would need to add mesh points around the subject then move in the sides around it.
Dragging out some temporary guides from the rulers to help with alignment may be useful if attempting this.
As this works on a layer basis, you will probably need to crop the end result to match the canvas back to the scaled image.

On the Mac you can hold down the option key while dropping the master onto the page to add it instead of replacing.

On the Mac you can hold down the option key while dropping the master onto the page to add it instead of replacing.

How is this related to the beta?

How is this related to the beta?

Uncheck View -> Dock Tools
Alternatively, learn the keyboard shortcuts for the tools you most commonly work with and it won't matter where they are.
 
Agreed, it sounds like the OP was looking for Affinity Photo.  Designer is more like an Illustrator replacement, but not quite really that either.