fde101

Is this a feature request (you want Serif to continue breaking things with every update), or is it a misplaced bug report in the wrong place on the forums?

Agree, 96 = 4 * 24, 72 = 3 * 24, so need 12 * 24 = 288 to make this work.

I believe the file format was designed to allow the file to be updated in place rather than replaced as a performance optimization. Rather than writing everything each time you save, the application only needs to rewrite parts of the file that have changed. If that is an accurate assessment, then a feature such as the one you describe would defeat that optimization and slow down the save process by forcing the application to write the entire file every time it gets saved, as Photo does now when doing PSD round-trips with DAM/raw processors such as Capture One, which takes quite noticeably longer than saving a native Affinity document does after the initial save. This is not to say that it couldn't be done, or that it shouldn't be considered, but it is a factor to bear in mind that would likely be impacted by enabling a feature like this.

Not sure that I agree on that one, but regardless, there is usually more space to make a set of sliders wider than taller, and a longer slider allows for more precision. That said, a slider will never offer the same level of precision for a wide range of values that you can obtain with controls that allow for direct or relative entry as they are always constrained by the pixel resolution sitting underneath them (most GUIs do not allow for sub-pixel mouse tracking so if the slider is 150 pixels in length, for example, the slider can only input 150 distinct values). EDIT: if you were able to dedicate a display to the controls, you might have a case for a more mixer-like interface with a bunch of vertical sliders spread across the screen and controlling various parameters. In practice many of us are on single screens and the time taken to move the mouse from one screen to another (to make a selection on the image then go across to manipulate the values) would probably slow things down, and using that type of interface on a screen shared with the image would result in too little horizontal space for the image itself. A touchscreen could eliminate the mouse movement issue, and one interesting possibility might be an iPad-based remote app (or Android tablet for that matter) to control the parameters of the image displayed on the computer, but for the interface on the computer itself, I'm not sure if a statistically significant percentage of users would find that type of interface to be a net gain.

It actually stores and uses non-integer values behind the scenes, but rounds them for display. Some values allow the rounding to be adjusted in Preferences/Settings, but I don't see one for percentage values (which would be nice to have added). I believe that may have been requested before.

The Arm64EC thing is kind of interesting, but it is basically a transitional tool for developers to use to gradually provide native ARM64 ports as part of the development process, it is not how the "emulation" Windows provides work. My comment was more that I don't think Serif is doing this at all - I don't think they are explicitly transitioning their apps to ARM for Windows (yet?) - so they are likely fully "emulated" at this point (in whatever sense Windows "emulates" x64 under ARM64 systems).

UI font size should really be controlled by the operating system rather than the application, but there actually is a "Large" option under the User Interface section of Preferences/Settings (at least on macOS; from what I have seen on the forums the Windows version is missing a few of the UI options that the macOS version offers).

No, it isn't. It is not a bad additional option, but named tags would be preferable to color tags, particularly since there are already colors for layer layers which may lead to confusion between the layer colors and the color tags. Named tags are not subject to color blindness or to having subtle shades making them difficult to differentiate. Consider: If you were not familiar with the program, would you know what the layer color was, and what the color tag was, based on seeing something like this in the layers panel? If you could customize the color tags, users may eventually start doing things like what I did here with the layer colors (which are the ones to the left of the thumbnails for anyone who does not know): You can only get so many colors in before you start resorting to things like that - not an issue with tags that have names instead. The one downside of named tags is that they would be too big to reasonably fit in the layers panel, so you maybe would just need a generic tag icon to show that there are tags, and provide the names of those tags in a tooltip or similar.

I believe that is via dynamic translation though, not with a native ARM build?

It has come up on the forums a few times that they are using one of the native Microsoft frameworks for their Windows version. This has been cited as the reason they have not released an ARM build for Windows, because the framework was (at the time) 32-bit only on ARM, and the Affinity apps are 64-bit only. WRONG. If FFmpeg is compiled to use these codecs it is illegal to use in the USA (and several other countries) unless patent licenses have been obtained. The codecs themselves are covered by necessary patents - not just the implementations of those codecs.

Not true if you have a pixel selection and there are no layers selected (though offhand I think the option should be disabled in that case - maybe making it even more confusing to users who are not aware of which selection it refers to?) You could do something like "Selected Layer(s)" or "Layer Selection", possibly "Vector Selection" if you would rather go that route, but I agree that some way of more clearly denoting that this is not the pixel selection should be considered.

Sounds like we are on the same page here. One of the biggest issues that I would encounter right now with a switch to Linux as my primary platform is the way that patented media codecs tend to be handled by the available applications. As I am in the USA where software patents are (sadly) enforced, I can't legally make use of applications which support codecs like the ubiquitous x264/x265 but have not obtained the required patent licenses. Many open source applications either include support for these codecs without having obtained the licenses, making them virtually impossible for users in the USA to use legally, or make them optional so that you can grab them if you are in a country where the patents are not enforced or don't mind taking the risk of using them illegally. There are few if any options that would work across the majority of relevant applications on the platform to enable *legal* support for those codecs, and I need to maintain that support (both read and write) for the foreseeable future. This means that my choices in applications would be substantially more limited than for most.

A nice feature to be sure, but named tags which are independent of the layer name would be preferable. Consider a language tag named "EN" for English. You don't want to pick up a "gardEN" image as being language-specific. There is too much potential for misreads unless you set off your chosen keywords with some kind of delimiter, which adds even more to the length of the name in a panel where users have already complained about the indentation of layers leading to truncation where the name does not fit within the width of the panel.

To a point perhaps - but there are problems with pursuing that as an end to itself. There are inherent differences between platforms which need to be catered to in order for an application to work well on that platform. Doing the minimal work to get something "working" on multiple platforms often means using toolkits that aim to abstract away the differences between the platforms so that an application can "just work" with minimal effort. This is a problem because they tend to aim for a least common denominator and often fail to leverage the benefits of using the different platforms, plus the user interface is never correct for all of them - just look at apps like Blender (which is the same on every platform because it essentially invents its own platform and runs it on top of the others, making it effectively wrong on every platform), FL Studio (which looks and acts like a Windoze app when running under macOS, even going so far as to implement something like an MDI-style interface - ick - which even most native Windoze apps have long since discontinued the use of), etc... In other words, using cross-platform development toolkits which make it feasible to maintain the application as working across a diverse range of platforms usually degrades the quality of the application on most if not all of the platforms in question. Even when using custom cross-platform frameworks created for a specific application, it is common to either aim for a least common denominator, or to make some additional platform "look like" the first one that the program was developed for - this is almost never a good plan. Consider how often it is pointed out that a desperately requested feature which the Affinity suite does NOT have already exists in GIMP, Inkscape, etc., but users steer away from using those apps because the overall quality of the interface seems better to them when they are using the Affinity apps. With the Affinity suite, Serif has built the UI separately using native toolkits on each platform, which gets much closer to being correct on each platform, and they still managed to mess some stuff up (like the missing proxy icons in the title bar that could be used to move the document from its window under macOS). Adding another platform and doing it well, even as well as the Affinity suite does, would mean adding yet another toolkit to the mix - a meaningful portion of the application would need to be rewritten yet again. This would either mean hiring more developers to handle the native port under Linux, or taking up time that could otherwise be invested in feature improvements. After such a port was done, there would be an ongoing need to maintain the software on an additional platform for every new feature they introduce. They would also need to train their support team to handle the added platform, and possibly hire additional support agents. The ongoing cost to them to do this well is higher than I think most people here are prepared to acknowledge. I for one would much rather use an application which is native to the platform I am using and follows its conventions correctly while providing the features that I want, than a more feature-heavy application which uses a cross-platform toolkit and sticks out like a sore thumb, failing to integrate well with and conform to the look and feel of the rest of the environment. I would also prefer that development time be invested in improving the functionality and stability of said application, than in maintaining it across platforms I don't use or particularly care about. If Serif has the resources to hire new developers to maintain a separate Linux version of the apps without impacting development on the existing platforms, great - more power to them. I wouldn't care as much either if they replaced the Windows version with a Linux version, so that they are still maintaining the same number of platforms, and choosing the better platforms to continue supporting. Otherwise a more practical approach would be to make what changes are needed to the Windows version so that it at least functions under Wine. Even if Serif does not want to support it under Linux, getting it to work in Wine would probably be a smaller effort that would enable Linux users to work with it on an "at your own risk - fix your own problems" basis. I don't see that happening - at least not intentionally - in the near future, but it is probably the one approach they could take without substantially increasing their costs.

It would be better to allow the user to define their own *named* tags, arbitrary in number and without the inherent limitations of color tags (limited number of them before they become difficult to tell apart even if an arbitrary number of them supported; even harder to tell apart for those with color blindness, etc.)

In that last screenshot, the "left indent" is 2mm and the "first line indent" is 5mm; the "left indent" applies to all lines of the paragraph (in this case the header is the paragraph) while the "first line indent" is added to the first line of the paragraph only. The first header on the second page is the only one I see with multiple lines. The first line appears to be flush with the first line of the other headers presumably using this style, which is what I would expect from those settings; the remaining lines have a reduced indentation due to the fact that the "first line indent" is not being added to them. If you want all lines of the paragraph (header) to be flush with each other, you should set the "left indent" to 7mm and the "first line indent" to zero.

This is true for practically all software, including open source software - the license (open source or not) allows you to make use of code (source or binary) that belongs to someone else. This is not to say that there are not other reasons to avoid various commercial licenses, but this matter of "ownership" is not one of them, since you will face that unless you write 100% of the code yourself, or buy the company or (often the case) the set of companies that own the [pieces of the] product you want to use. Microsoft likely does not own 100% of what ships with Windows - for example, they too are paying to license fonts from others, to be able to include them with the operating system. Apple does the same thing.

Correct. I believe @JimSlade was referring to the fact that "something" has offered that feature for a long time now - likely in reference to TeX, as even QuarkXPress lacks this option. While the existence of TeX means that the option is not exclusive to Adobe, there are relatively few products which currently offer it, even in the world of page layout software. I would like to have the option available also, but I am not holding my breath, and there are other things that the Affinity apps lack which I personally would consider to be of a higher priority.

Windows had a POSIX environment at one time but that is long gone. I would agree that Linux is generally inferior to many true UNIX platforms in some ways (superior in others depending on the specific UNIIX platform being compared to), but I strongly disagree with your assessment that it is not superior to Windows. A few examples for just about any use case: Windows is a Microsoft product. That alone is enough to make it inferior in my book. Current versions of Windows 11 make it nearly impossible to set up a new personal computer without associating the computer with a Microsoft account, tying you to their cloud services, even if you have no intention of ever using them. About the only way to get around it is to use various tricks to make sure the computer never sees the internet until after you are able to set up a local account - and even then you may need the "magic words" to include during installation... This is a serious problem and they seem to be doubling down on it, making it harder and harder to set up a standalone environment which is not connected to their cloud services. System requirements for new Windows versions tend to rise faster than system requirements for new Linux versions, requiring hardware to be replaced more often than might otherwise be necessary in order to remain current. For desktop use: The lower desktop market percentage of Linux means that it is less heavily targeted by the authors of malware, reducing the chance of being directly impacted by bad actors who are operating at scale. Windows includes an "AI assistant" named after a game character who went insane and wiped out the populations of entire planets. The security of current implementations of such "AI assistants" is highly questionable in general, regardless of the naming connotations. This "assistant" is enabled by default, along with other highly questionable features which probably shouldn't be provided at all, much less be turned on by default. For server or embedded use (not all of which is in life-sustaining or life-threatening equipment): Linux can run quite reasonably on a server without wasting the resources needed to maintain a graphical interface. For server use (and for basic embedded use, not all cases of which are in life-sustaining or life-threatening equipment) this allows it to make more efficient use of available resources. The free nature of Linux makes it more practical to use it in virtualized and clustered environments where many licenses are needed and cost is a factor as if service agreements/contracts are not required it is not necessary to track or pay for licensing; a Linux setup can simply be duplicated and used at scale. This is also important for embedded use cases as the licensing costs of commercial products may otherwise factor into the eventual price of the product.

QuarkXPress comes in at a significantly higher price point than the entire Affinity suite, and they do not seem to fully support variable fonts yet either (though they have said it is on the roadmap for several years now).

Yes it is, and I did in fact intend it that way. That fact is not truly relevant to the point being made, however, nor does it mean that I think Linux or any other current platform is the future I would actually want. In my opinion there is no current operating system on any hardware which is truly worthwhile or good. Some are better fit for their purpose than others, but with all the things we have learned and basic principles of security and good engineering practices that have developed, ALL of the current operating systems I have encountered fall short. If we really want something worthwhile, we will need to start from scratch, break source and binary compatibility with all current software, and use sound architecture and design to create something better. Capability-based approaches to security, naturally isolated applications without the overhead of current "sandboxing" techniques which add pointless overhead and complexity in order to mimic classic runtime environments to minimize application changes, a consistent graphical interface which is more cleanly separated from application logic and design so that the system can maintain and even morph the UI consistently at a global level without application code changes, separation of password management from application logic so that applications can security authenticate with remote servers without ever having access to the user's credentials that are being supplied (reducing the trust footprint necessary at the application level) - I am convinced that these things can be done well if they are done from a clean slate, and that is what we really need right now in the computer industry, however much it might stretch people with established workflows and ways of thinking. The current approaches simply are not sustainable in the long term.

The option+click to pick the key object should really be listed in the help bar across the bottom of the window too.

The price itself is not as important as the pricing model. CC is a subscription-only offering, and for me, that means it is a dead product. Even if it were a penny a month it would be too much. If the Affinity suite cost three times as much as it does it would still be an offering to consider as it is perpetually licensed.

That is a UI convention but I don't believe it is a valid reason for the guides to have been designed like this; they could simply have come up with an alternative method of deleting them, such as dragging them all the way back to the ruler. A more likely reason is that multiple artboards are spread out in a large area and may not match each other in dimension or be aligned in their placement. If guides were visible outside the artboard they would cross over other artboards, meaning you could either give a potentially misleading perspective on where the guides were relative to the other artboards if the guides remain local to the artboard (it could be distracting if they cross over objects slightly off and the user keeps wanting to go and fix them only for the guides to change as soon as something on the other artboard is selected), or if the guides were made global, then they would not necessarily align to all of the artboards in any meaningful way - put various different sizes of artboards on the same canvas, and the guides would only make sense for a few of them at most.

If your artboards are all the same size, you might consider creating a multi-page document in Publisher instead and putting the guides on a common master page, so they can be shared between pages.