fde101

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.

...wasting everyone's time and contributing to the frustration of the community when Serif completely ignores it, as they have essentially implied a few times would be their likely response to such a thing.
 
Resolve has run on Linux for a long time, even prior to BMD's limited support for it, as the dedicated hardware consoles used to be part of a turnkey system that was the *only* way to obtain Resolve (at very high price points), with software-only download versions for computers coming much later than that.  BMD has invested more heavily, from what I can tell, in providing macOS support than in providing Linux support, but they have made the previously turnkey-only Linux version of Resolve more widely available as a software-only download version, so they are keeping it up to some degree, though their distribution support is somewhat limited.
 
How so?  Adobe's software isn't available on Linux either.  If someone prioritizes the choice of using Linux over the applications, then they aren't using Adobe, so this can't be considered an alternative to Adobe.  If someone prioritizes the software over the operating system, and they are currently using Adobe software, then they aren't using Linux (at least not for that purpose), so they would not be in that "market".
 
They have already done this and determined that it is not yet there.
 
Even a beta version would require most of the development time that would go into a release version, so using one to "test the market" would be spending probably 90% of the effort that would be required to develop the final versions, meaning that they would already be committed to seeing it through, thus it would need to come after they would "test the market".
 
Agreed, and I would suggest this one be closed, as Serif has already done with several others which have recently been created.

When you are requesting a feature, why are you using the digital equivalent of invisible ink?
I can't read that text unless I select it - the contrast is too poor with the dark gray text against the black background.
I'm guessing you might be forcing a custom color scheme of some sort in your browser and don't notice it, but the colors you are using make it unreadable for those of us with the normal forum settings.

Hi @fde101
Can confirm this is unexpected behaviour and an issue logged internally, I've bumped the existing issue with your report.

I can't find any reference to this change in the list of changes that was provided for the 2.6 beta.
Did I miss it, or was it missed when producing the list?
It would probably have been tested a bit more carefully by the beta testers if they had been aware that a change had been made, but as it does not appear to have been listed, it is not the kind of thing that many users would have immediately caught on to and identified the problems with it.

Yes, but it was phrased about the bug relating to pixel selections, but all selections are now snapped
 
 

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.