fde101

Swatches are designed to maintain consistency of color throughout a document. Placing an *editable* hex color field on the Swatches panel runs contrary to its purpose and the very notion should be immediately dismissed as a bad idea. Also, hex values are only of interest to web designers and do not scale well: they only reflect 8-bit-per-component RGB and do not account for HDR, CMYK, etc. Swatches may represent spot colors, which by definition are not RGB, or even CMYK; even though they have RGB/CMYK representations for display and printing on devices that do not have true spot color support, displaying RGB values for them could be considered misleading. Similarly, displaying hex values for swatches representing CMYK colors can be similarly thought of as misleading. Including them on RGB and RGB-related color space color pickers in the Colors panel makes a lot of sense and should cover the needs of most web designers. The value of including them on the swatches panel, together with the potential for confusion it may cause, seems questionable. What might make more sense is to include a *label* (read-only display) explaining the selected color. This could show the hex color of the selected swatch if the swatch is an 8-bit RGB (or related) color swatch, but show the CMYK values of a CMYK swatch, the Pantone number of a Pantone swatch, etc. This would scale better to support the range of colors that a swatch might represent, without being misleading, and without raising questions like "If I change those values what happens to the swatch? Am I editing the swatch or am I disassociating the selected object from the swatch and giving it a different color?".

All being said, the way that it responds vs. the way it is visualized are definitely in contrast. If it is to work the way it does, it would make sense to reverse the shading, or failing that, to remove it and leave it as a plain ordinary slider. Note also that there are Lift, Gamma and Gain controls in traditional color grading toolsets such as Resolve, and the Gamma control in Resolve does work the opposite of what is described here - moving it to the right makes things brighter, to the left darker - so there is precedent in other software for making it work more logically and less mathematically. Most of the people using the software are more interested in the creative effect of the tool than in the math behind it.

Designer is NOT an SVG editor as Inkscape (for example) is. When you "open" the SVG in Designer it converts the supported part of the SVG file into its own native format, which does not support animation. You are not editing SVG any more - you are editing a Designer document which was populated by copying things out of the SVG. Anything that was in the file that Designer cannot translate would not have come across, so whether the "Save" option is permitted to overwrite the original file, or you explicitly export it in the menu (which is what Save would be doing anyway if they did enable it as a shortcut), the animation would already be gone.

Should this be moved to the bug report area?

Regular expressions, which many users are incorrectly calling "grep" after one particular UNIX command-line utility which allows text files to be searched using regular expressions (and which various applications similarly incorrectly use in the naming of similar features). You can search using regular expressions with the Find and Replace feature in Publisher; you just need to turn them on in the gear menu next to "Find". Being able to provide a list of regular expressions to flag as potential preflight issues would indeed be a nice addition.

Yes, this is true. This is a natural side-effect of the nature of open-source licenses: due to distributions generally being out in the open and available for free, there is no basis for royalty payments being made for patent-encumbered codecs (which should not really have been able to become patent-encumbered... but that is a topic for another thread of another forum). This of course would be mitigated if there was a mass adoption of open, patent-free codecs, but sadly the market seems to be stuck on codecs that are closed off instead. I blame that on the market at large.

Ok, you want to be technical... there are desktop environments which are written primarily to run on top of Linux which have reached the point where they can provide a superior user experience to the Windows environment. There are some good applications for them, but many users will require applications which are currently missing or not as well-developed as those available on other platforms. There are Windows apps that don't work or are unsupported on ARM versions of Windows. There are Mac apps that still haven't been updated to be 64-bit and thus don't work on Macs that are remotely current. Others that still are not native on Apple Silicon. Your point? Depends on the application.

I don't believe Windows ever ran on VAX. The VAX architecture is an old DEC minicomputer architecture which had a limited run (in the form of "micro VAX") of microprocessor systems. Back in the 70s the VAX architecture was developed alongside an operating system called VMS, which still exists in active development today (by a different company) and is now called OpenVMS. The VMS operating system descended from existing production operating systems and was well-architected for its intended purposes. Someone who had once worked on the VMS platform and was very familiar with its architecture was later hired by Microsoft and became the chief architect of Windows NT. Consequently the NT architecture was highly influenced by the VMS architecture, though VMS was never a predominantly GUI-driven system, and in order to improve graphics performance, the NT architecture originally cut some corners that created some security and stability issues that had never existed in the VMS world. While those specific errors in the architecture were addressed in more recent versions, NT architecture has always developed somewhat independently of the VMS architecture, though with clear, strong influences in each direction over time. A big improvement over the DOS underpinnings of earlier Windows versions, but the only connection I am aware of it having to VAX is that VMS originally ran on VAX (like macOS, it has switched CPU architectures over time to remain current - first to Alpha, then to Itanium, and more recently to amd64). A more detailed article for any interested (granted the article is a bit dated, but we are talking history here to begin with...): https://www.itprotoday.com/compute-engines/windows-nt-and-vms-rest-story

True, but it didn't start with them. This is the way that product worked when they bought the rights to it, and they had already been users of the product (in that format) before they took ownership of it. In that context Linux was effectively playing the role of an embedded system. A number of actual current embedded systems are based on Linux - it is used as the underlying OS in a lot of Korg music workstations for example (such as the Kronos series) and some high-end lighting control consoles run on it as well. People don't interact with such products at a level that leads them to consciously think that they are working with Linux, but they technically are. Linux has quite a significant footprint in the embedded market space: https://en.wikipedia.org/wiki/Linux_on_embedded_systems This is not really because Windows has improved (it has, if slightly) so much as because Apple has done some really stupid things lately and users are getting frustrated with it. The idiotic orange dot they insist on putting on every connected display when a microphone is in use causes a serious impact in a lot of live applications (and for those of us who have digital audio workstations and other similar software open just about constantly it provides absolutely none of the security benefit they claim it is for), the base-level Apple Silicon chips only support a maximum of two displays, and they pointlessly (and needlessly) dropped support for eGPU with Apple Silicon systems. While it is questionable how much of a generic benefit eGPU would provide for computational reasons (it would in some cases but not in many of the cases where people might be inclined to think it would), the ability to efficiently expand the number of supported displays on those base-level systems would open a lot of doors - and there is no technical reason the existing support for this could not have come across when they switched architectures. For most users macOS is still vastly superior to Windows, granted it comes at a higher buy-in price, but these mis-steps are not helping. Linux is the next best choice for general computing of what is currently on the market; I would not trust Windows for anything that I really cared about. Linux is clearly preferable to both macOS and Windows for most server functions at this point, and has become superior to Windows for most desktop computing purposes, though many of the available applications still have some catching up to do. While macOS doesn't really exist in the embedded space, Windows does, and some use it (for what reason I am clueless), but Linux is again obviously much stronger there. Their loss, as in many cases they are the ones that stand to benefit from it the most.

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.

How would that work? Do you just mean to export an individual story? From a DTP perspective HTML is essentially an eBook/ePub format, which has already been requested in other threads, such as: Alternatively HTML could be a simple rich text format for exporting an individual story, which would be a different feature request from what people are usually asking for. Either way, this is not the correct place for this - the thread this was posted in is about scripting. If you are looking for the ePub style export of HTML, you should add your support in an existing thread for that. If you are looking for a story export, there may be an existing thread requesting that but I am not turning one up in my initial attempt at searching. If you meant something else by a text format export, I have no idea what that would be, but I would suggest searching for an existing thread and creating one if you can't find it, giving a bit more detailed of an explanation of exactly what you want from it.

Multiple candidates have been pointed out already on several threads which have been opened here in the past - Capture One, On1 Photo RAW, etc.

Hi @desperatepotato, welcome to the forums! This has been requested numerous times already and there are many duplicate threads on this subject. It would be best to pick up this discussion on an existing thread for this feature rather than continuing this one as it breaks up the discussion and makes it harder to follow. Here is one example of such a thread:

I am using one called iQR on my Mac, which is rather nice. Came from the App Store. Note that this thread technically violates the guidelines for this part of the forum in two ways: it has two requests in one thread, and both of them are duplicates. Is there a specific capability you are looking for that cannot be achieved simply by placing the text/image/shape as an object on your master page, reducing the opacity to taste, and moving it to the back? If so, I would suggest adding that to an existing thread requesting that feature, rather than continuing yet another duplicate which only serves to spread out the conversation even further; here is one I found quickly where it is requested for Affinity Photo; expanding on that with what specifically you want to have happen and the request to include it in Publisher would be more appropriate than the duplicated thread:

The TGA support is just about useless for its intended purpose anyway. The main reason people kept begging to get it supported and the main case that was made for it was for unpremultiplied alpha. The problem is that the Affinity software behaves as if the image is premultiplied internally, so the color data is already lost when the alpha channel contains a zero, and there is no way to get it back for export - thus no matter whether the exported image is premultiplied or otherwise, there is no way to treat the alpha channel as an independent layer and preserve the image data in the other three. This just about wipes out the value that is typically cited for using TGA. Suggest just using PNG or other superior format unless and until this is fixed, but if the Affinity raster engine is indeed premultiplied internally, fixing this may be a fairly significant effort, so I wouldn't hold my breath.

Yes, this has come up multiple times in the past and Serif has consistently indicated they are not pursuing any kind of video editing, 3D functionality or animation capabilities for the Affinity suite at this time. Resolve is great for a lot of reasons, but it does have a learning curve. If you happen to be on a Mac and have difficulty with learning to use Resolve, another good option would be Final Cut Pro (or possibly the free iMovie for more entry-level needs). There are lots of other options out there as well, at various price points and with varied capabilities, on various platforms - HitFilm, Lightworks, LumaFusion, etc. Blender has some built-in video editing capabilities as well and is also free, but it is not optimized for that task and also has a bit of a learning curve.

The essence of what you are requesting is a Linux version compiled for ARM, which is a highly duplicated request, so you really should have posted this in an existing thread on the subject rather than creating a new one. Serif has already indicated a few times that a Linux version is unlikely to happen in the near future, though many have requested it. If they did decide to support a Linux version, adding one compiled for ARM would likely be relatively trivial. Porting to Linux, not so much. However, there is a third piece to this. Last I checked, PI OS was still 32-bit even though the newer PI hardware is fully capable of 64-bit. Serif is unlikely to release a version of their products compiled for 32-bit. If I have missed something and PI OS has switched to 64-bit, this is not an issue. If they are still 32-bit, you would almost certainly need to use an alternative Linux version that runs on the PI to host the Affinity products, even if they did decide to port to Linux and build for ARM.

There actually is a setting for UI Font Size in the Interfaces section of Preferences / Settings - it is either Default or Large though, not really in-between sizes. There appears to be in part an issue with the rather stupid way they integrated the menus into the title bar under Windoze. The font is likely being scaled based on the height of the title bar (its container) and the title bar is simply too small to give you readable text. The font Photoshop is using in its title bar appears to be the same point size, or extremely nearly so. This is a non-issue on the Mac where there is a dedicated menu bar which will be the same size for everything. Text for the menu items appears to be about the same size as well (taking a floating on-screen ruler to the screenshot), maybe some fraction of a point smaller in the Affinity apps, but Photoshop spaces the items a bit further apart which may be helping clarity somewhat by making the menus less crowded. The text in the preferences window is also about the same size between the Affinity apps and Photoshop (again maybe some fraction of a point smaller in the Affinity apps), but the typeface used in the Photoshop interface is a bit heavier in weight and the contrast between the text and the background is a bit better, making it appear a bit more clear. If anything the choice of a more readable typeface combined with better contrast in the UI is called for rather than larger text sizes.

Two things to consider: Some fonts are licensed in such a way that embedding them (or converting them to outlines to work around not being able to embed them) is not permitted. Converting a font to outlines disables hinting and may impact the quality of the produced image at low resolutions and small point sizes. Neither of these points invalidate the proposed feature in general, but they do need to be considered whenever considering the implementation of a feature of this nature.

No, you should change your entire system for your entire system. That way everything is consistent, if the apps are responding the way they should be to the scale. If an app provides an option to adjust its overall scale independently of the OS setting, it is in effect giving the user the ability to make things inconsistent, and that by its nature is a misfeature. Providing an option to adjust (for example) toolbar size relative to the OS scale makes sense and would be reasonable, but to scale the overall interface differently from the OS setting is a bad idea. Apps which provide that option rather than following the OS setting, or which do not follow the OS setting correctly, need to be fixed. The only possible exception would be something that provides an immersive experience, like a video game, which presents an interface unique to that experience which is by its very nature separated from the rest of the system. In this case the whole point of the application is to let the user become lost in an imaginary world, and it makes sense that the interactions would be tied to that world instead of the real one. For applications that are grounded in reality, however, it is more important to be consistent with other applications which are similarly grounded in reality. This includes productivity and creativity apps such as those from Serif.

Apple is more security-conscious than are many of those financial institutions and they have you logging in using an email address. Not that they are particularly security-minded, but so does Microsoft I think? Whether it is a simple username or an email address makes little difference in this context as any site or service worth its salt these days is going to encrypt it in transit alongside the password, and the forums do not display the email address for others to see, so the chance of the email address leaking is really no different than the chance of some arbitrary username leaking. Behind the scenes they would generally be stored in the same table in some database either way if they were separate, so if a hacker got ahold of one by hacking the back-end, they would probably have the other too. The notion of a separate username somehow protecting your email address from spam is a false security at best. A more legitimate case for not using an email address as a username seems to come from the potential for the email address to change, and the possibility of someone else being assigned that email address after you stop using it. If you are using some email address to log into a site, and your email address changes while you are not actively using that site, then when you try to go back to that site and forget your password, if someone else has taken over the email address, the confirmation for the password change would go to them. In and of itself this is bad, and the same problem exists even if you are using a different username than the email address - the password change confirmation would still go to the registered (now incorrect) email address, probably even listing the username so that whoever receives it then gets a big hint on how to take over your account. It becomes a slightly bigger problem when someone tries to register for a new account using their new email address which happens to be your old one. If they try to register using that email address but the username doesn't match, you might think that would prevent them from taking over the account as they are unlikely to try the same username you picked and it will never match up, but most systems which allow alternative usernames will accept either the username OR the email address for authentication, and those which do not, will often still have a way to "recover" your forgotten username by emailing to the registered address - so if someone gets a message that the email address is already taken when they try to register, they can still recover the username and password and take over the account. In the end, this too leads to a separate username providing false security for most sites.

For the 1.x versions they had four areas: one for questions common to the products and one for each individual product. The problem is that people would post the same thing separately for each product, and duplicate threads would still be created within each product, so instead of 2-3 redundant threads all asking for the same thing, there would be... a lot more than that. Of course, combining them like this does create a different set of problems, as you pointed out, so in the end it is something of a toss-up.

Hi @Blendan, welcome to the forums. This has come up several times in the past:

It doesn't need to be though as its first character can be formatted using the drop caps feature, as I explained above. Ideally the list would be set up in a paragraph style (one for each of "figure", "image", etc.) so that the whole thing can be automated to that extent.

Create a character style All Caps which is derived from No Style. Choose All caps on its Capitals page. In the paragraph style where your numbering is set up, keep the word "figure" all lowercase in the numbering style definition, then on the Drop Caps page, enable drop caps, set both the height in lines and the characters to 1, and choose All Caps as the style.