fde101

It is actually "Unsupported characters used" but the column in your screenshot is too narrow so the "d" is being cut off. This is probably a function of screen size or scaling settings as I did not need to resize anything to see it on mine - the whole message was there when the window opened. If your column is already too narrow, this longer message would get off as well. Also, there is nothing any less "misleading" about this, all it does is add a suggestion on where to look for more details - this may be useful for navigation purposes but doesn't really change anything about what is being said in the Font Manager. Either way it is just telling you that there are characters in the text which don't exist in the font, which is more than the Font Manager is really intended to be used for anyway. Finding errors of this nature is really in the domain of the Preflight Panel. While I am not opposed to finding some reasonable way to improve this (maybe the message could instead be turned into a hyperlink that opens the preflight panel with the relevant characters referenced, assuming this particular test is even enabled in Preflight?), I don't agree that the current message is misleading. This has come up before. The suggested workaround for the moment is to use the Find and Replace panel and search for the font in which you are interested; as this already presents an interface for navigating multiple results, perhaps a "Find Usage" button (or similar) could be added to the Font Manager, which would simply open the Find and Replace panel and execute a query in it to find the selected font? EDIT: in thinking this through, perhaps the Find and Replace solution is also the way to get around the issue with the option potentially being turned off in Preflight? Perhaps Find and Replace could be extended with a filter for finding characters which do not exist in the font (the "Unsupported" characters as mentioned above). Then the above-suggested hyperlink would instead open Find and Replace and run a query on it for unsupported characters in the particular font the message is displayed for (by using the existing Formatting filter and the new Unsupported Characters filter together)... just a thought.

Technically "floppy" refers to the magnetically coated disc inside the outer shell of the disk, and even with 3.5" floppy disks, those are in fact floppy - it is the outer shell of the 3.5" disk which is hard. Of course, we've been completely ignoring 8" floppy disks throughout this thread which is now WAY off topic (not to mention the so-called "twiggy disks" - and probably no need to continue doing so either... )

Considering that the first versions of Windows shipped on 5.25" disks (360 KB each) which did not have that chamfer (and which actually were "floppy" In that they could wobble a bit if you held them by the label and waved them up and down in the air), a 3.5" disk icon is relatively modern. I wonder how many 360 KB disks it would take to distribute Windows 11... hmm, the 22H2 ISO for x64 is 5.56 GB in size, so somewhere around 16,195 disks? Not as many as I would have thought actually 🙂 3.5" disks had twice the capacity until they went to HD, so more like 8,098 3.5" DD disks, or 4,049 3.5" HD disks... of course all of this ignores formatting info and assumes the disks are completely full, etc.

The permission issue in question would likely be irrelevant to her. Someone doing simple photography work is not normally using linked images - that is more a concern for desktop publishing work.

Sure he can - and it is just as meaningless each time he does it: This request is not for Resolve Each distribution is effectively a different operating system in some ways, so requesting that an application work across multiple Linux distributions is effectively asking for multiple tightly related ports, though after the first one the rest will mostly boil down to build settings. Getting the application to work on one or two supported distributions which use similar packaging (ex. RedHat-based distributions such as RHEL, Fedora, CentOS are similar enough that this could likely be made to work) is more like one reasonable porting effort. Linux runs on many CPU architectures. An application that is commercially distributed in binary form is unlikely to be available for all of them - in many cases they aren't even built for ARM, which is very common by now. Limiting the application to one distribution is not all that different commercially (yes, it is technically) from limiting to a single CPU architecture. Either way you are excluding some portion of your potential user base - just like you are by not supporting Linux at all. So why focus on the distribution? Most people using Linux are already aware of these concerns. What Flatpak essentially does to applications is a variation of what Apple's sandbox does in the macOS world and what MSIX and its underpinnings do in the Windows world. The sandbox and the MSIX thing can cause just as many issues for various applications which are distributed that way, so if the "need" for Flatpak suggests that Linux is not ready for the commercial market, then the existence of the sandbox and MSIX should say the same thing about macOS and Windows. Flatpak has the added benefit of packaging more of the application's requirements with the application (much as the application package makes possible in the macOS world, just organized differently), which has the correlating disadvantage of taking up more space and increasing the download size. Pros and cons. One key difference is that because Linux distributions have had package repositories for a long time and many applications are simply installed from those repositories, there is a lot less motivation for most Linux developers to make their applications work well with Flatpak than there is for Mac developers to make them work well with Apple's sandbox. As to the Affinity applications, I do think there is one major reason why Flatpak would cause issues: namely, linked images. I'm not sure that Flatpak adequately addresses handling of that particular feature.

Realistically, yes, it would be, but the majority of users are likely more casual and will write off scripting as something they will never use. The ability to use plugins for the products will interest a larger number of people than the scripting feature, but that will not drive sales of a new version until those plugins are available, so neither of these things will likely be enough, on their own, to convince Serif's marketing department to start advertising a new major release which they expect to charge people for. Realistically, these should have been engineered into the core of the products from the beginning and should have been a 1.0 feature, so they are coming late and pushing them to a 3.0 release if they are ready by 2.x would be a bit much.

I believe this has been requested before, and quite recently.

Hi @JABP, welcome to the forums! I believe this suggestion has come up before, probably in one of the numerous threads requesting the implementation of global layers in Publisher (a feature which is also still missing from the product, though some of the more common use cases for them have been covered by the "States" feature). This is orthogonal to that request, however, and so is useful to break out into its own thread, particularly as you have presented a use case here which could potentially be of value in Photo and perhaps Designer as well (probably even more so than in Publisher), and which may be useful to have not only within the stack of layers, but perhaps even within a group or a Layer layer, as a mask placed in a group with other layers will only impact the layers below it within the group (so "pinning" a layer to the top of its containing group has the potential to be a useful consideration).

Thing is they had them at one time and intentionally removed them; this is a duplicate thread:

Can't speak to the tool, but depending on the situation, you may be able to achieve a similar effect by adding a mask to the object and applying a gradient to the mask. It's not too many more steps. Even in Designer, the transparency tool is only present in the Designer persona and not in the Pixel persona, which I would take as a hint that Serif thinks of it as a vector tool rather than a raster tool, and Photo is focused primarily on raster image work.

If you check out some of the tutorial courses available for how to do professional work in Blender, they almost always incorporate 2D graphics software at some level. Many of them are focused on open source tools and use things like Pencil2D, while some give demos in Photoshop, but the point is that people do frequently use Blender in combination with other creative software. Bingo. They want those so-called "facts" to change, which is why they keep asking. It is hard for someone working at a professional level to work on a platform when there are no professional tools on that platform for their field. Many people clearly want to switch to Linux for this work but the applications aren't really there yet. They want the applications to be there so they can make the switch. Of course people aren't using Linux for it right now - that is obvious. They want to switch to Linux and are waiting for the tools to become available so that they can. This is exactly the point I was making about a "chicken and egg" problem. People who create the tools may be looking for an existing market, but people who would create the market are waiting for the tools. You keep harping on about the lack of market share, but the market share is often driven by the availability of the tools required to work in that market. Right now Linux has a small market share in the creative field, most likely as a result of the lack of the availability of quality tools for that market. The current market share of Linux is 100% irrelevant. The real question would need to be the potential market share in the creative field if a sufficient set of the required tools were made available for people to be able to make that switch. There are multiple good web browsers and collaboration tools readily available on the platform. Blender provides a great tool for a significant subset of 3D work, and Resolve is obviously a great start for video work. What should be the easier category, 2D still work, is curiously the most lacking of the basic toolset right now. Photo in particular would have the additional market segment of web developers to consider, as there are many web developers who are Linux-based. For my part, as previously stated, I will mostly stick with my Mac for now for creative work - but there are many who want to change from whatever they are currently using, and I would probably use a Linux version of Photo from time to time if one were available (though not as frequently as using it under macOS, at least at present).

I'm not the one who brought this up - just pointing out that you should be consistent. There are more supported versions of Linux than of either Windows or macOS, too. Also, many of those Linux distributions were never really "supported" to begin with, so not sure they should even count in this discussion. For whatever it's worth, I am mostly a Mac guy. I use Linux as well, but most of my creative work is done on my Mac. I can definitely see the advantages Linux has to offer for certain use cases and market segments, but I'm not really losing anything myself by not having this available under Linux. In reality I don't think market share is valid as a primary factor in making decisions about what platforms to support. Everything starts with a market share of zero. If applications are not available the market share will never grow particularly large, so if all decisions were made based on market share, there would be a chicken and egg problem of getting any new platform off the ground. I recognize that a commercial company will not always see things this way, but I would prefer to choose what platforms to support based on their practical or technical merit rather than their existing market share. In that sense, I don't see this as a win/lose situation at all, and trying to turn it into one is not particularly useful. There are both pros and cons for Linux support in this regard: an example of a pro being that there are definitely situations in which the increased ease of maintaining an offline Linux network would be of benefit to some users and supporting those users with quality applications would be a great gesture and gives it a measure of practical benefit; however, the abstraction of graphical support in the Linux environment and the rather ad-hoc way that different distributions handle library version compatibility, path locations, etc., make it a more difficult platform to optimize such applications for, reducing the perception of its technical merit for the purpose.

Most versions of Windows (ex. 1.0, 3.1, 2000, ...) and macOS (ex. 7.5.5, 8, 10.1, ...) are also obsolete and unsupported. Not sure how the march of time is in any way specific to Linux or why it would call for special emphasis. I have to wonder sometimes where these numbers come from. If this is based on the typical metrics of browsers hitting web sites, consider that many users in VFX and various other industries relevant to creative software may be in a situation where for security reasons the computers are not allowed to connect to the internet. In this case there could be hundreds or even thousands of Linux desktops that never get reported, skewing the numbers. I'm not saying these percentages are wrong - what I'm saying is that I don't trust that we know them to be even remotely accurate in any relevant way. Linux is particularly ideal in these situations because a proper Linux system does not need to "phone home" for activation the way that Microsoft tries to cram down people's throats (granted there is an alternative, but does someone really want to call in each desktop in a large group working offline in order to get an activation code for each one?); while macOS is similarly advantaged in terms of activation, updating an offline Mac can admittedly be more challenging because of some of Apple's choices in how the updates are distributed. Consequently I don't think we have an accurate picture of the potential size of the market that might be interested in decent creative software should it be kept usable without requiring an online presence, and a Linux version could lend itself well to that goal.

Not sure what one has to do with the other? In previous threads on this topic Serif generally replied with technical and practical, not financial, reasons why they were choosing not to do this. Having additional financial backing from a parent company doesn't seem relevant to the discussion.

On one hand, the XML spec itself recommends the inclusion of the DOCTYPE, so I think the fact that the Affinity apps include it is technically correct, whether you like it or not. The file stands alone, as @walt.farrell suggested, so embedding the image into HTML code later on is largely irrelevant to the task of exporting it from the software. Coming at it from the other direction, as the XML spec does make the DOCTYPE optional, if its removal would cause an application to reject or misinterpret the SVG file, that application would not be conformant with the XML spec, and this would be a bug (or design flaw) in the application opening the file (for requiring the DOCTYPE), not in the Affinity apps (for not including it). You are assuming that Serif is writing the XML code directly, but this is highly unlikely; they are probably using a library to write the XML code, and the library may be adding the DOCTYPE automatically. If that is the case and if the library does not provide an option to omit it, Serif would need to switch to a different XML library, or write their own, which would not be the "very easy" change you are suggesting. Some libraries do provide an option for that, and Serif may be able to add an instruction to tell the library to omit it. Other libraries may not provide that as an option. Saying "no longer" suggests they were required at one time, and leaving them out may impact older software which reads the files, so if this change were made it would need to be an option in order to maintain compatibility. As leaving them in place has "no effect", Serif may be simplifying its interface and reducing potential confusion over users wondering what version they need to use by simply including them in the file regardless.