fde101

Is your document set up for RGB or CMYK? Check this in File -> Document Setup and look under the Color tab. If the document is set up as RGB then this may be an artifact of color management.

If you are using artboards, it always clips objects that are half-on half-off the artboard; there seems to be no way to turn that off - but objects which are completely off the artboard are visible. If you are not using artboards, including when you are using pages in Publisher, this behavior is controlled by the Clip to Canvas setting under View -> View Mode; if items off your page are invisible, turn that off if you want to see them. That option is available in all three apps, though it is disabled when artboards are in use.

... as a legacy format that they do not recommend using for new images. See the quote at the bottom of this Reddit thread: https://www.reddit.com/r/AdobeIllustrator/comments/axohrg/comment/ehuwz6h/

If such a feature were integrated into the application (which, again, I don't think is the most optimal choice here), wouldn't it make more sense when choosing such a font to copy it into the document or some related resource directory to use it locally after it is first selected?

Some font managers are designed to integrate with design software and automatically enable and disable fonts as programs or even documents are opened and closed, but this does not currently seem to be feasible with the Affinity products. Rather than saddling the products with the need to become their own font managers, I believe the developer time would be better spent on fixing whatever is preventing font manager integration from working. This can happen regardless as different operating systems have different sets of fonts included with them, and different web browsers use different default fonts. Even if you are using a "standard" font for your operating system, it may not be available for someone else who views your site. Accordingly, when you care about such things, it is a good idea to test your web pages using multiple computers (or virtual machines) running differing operating systems as well as on other relevant devices whenever it is feasible to do so.

On US keyboards it is the bracket keys [ ] as it is in most software of a similar nature. I know that other users have posted that these are not convenient or do not work on certain international keyboards, so YMMV.

The Affinity apps originally supported this in practically all of the entry controls for numeric values, but Serif intentionally disabled it at one point because people who were using the scroll wheel to... err... scroll... were accidentally changing values as the fields passed under the mouse pointer during that scrolling action. Back when they made that change there was a lot of discussion about this and many of us suggested alternative ways to handle this without losing that functionality entirely, but Serif opted for simply disabling that functionality instead.

The file formats are one in the same, so as @PaulEC suggested, you can simply open the Designer document in Publisher to access its text tools. File -> Edit in Publisher from within Designer, then File -> Edit in Designer from within Publisher, makes it fairly simple to pass the document back and forth between the apps, or if you only need the Designer persona, you can access that within Publisher itself.

I think the point I was mainly getting at was the generalization implied by this. You make it sound like this is something which impacts ALL artists and that the tool is useless for producing artwork because of it. This is not the case. Not all artists require the things you are requesting. That was never meant to imply that they are not things which impact your particular workflow or the more specific type of work that you do. Based on that, it does sound like you have a specific use case which requires this feature which not all software has (with the Affinity suite currently among those which do not have it). This does not mean that artists in general require this feature, but it does mean that for your particular way of working, you do. There is nothing wrong with that, and it is a perfectly reasonable request to be making, but I've seen far too many threads like this one in which people make blanket statements on behalf of a large group of users when they quite clearly apply to only a subset of that group, and that clear generalization of its impact to a larger user community than that actually affected is something that should probably be tempered a bit.

I wonder how often Michelangelo and Picasso used the HSV color space...

Seems like this would be a good addition to preflight.

Shouldn't this be in the bug report section of the forum? This section of the forum is intended for feature requests.

Probably not as much as you might be inclined to think. Trying to round-trip between different page layout applications is likely to cause headaches, even with common file formats, due to fundamental differences in how the different programs handle various cases. This has been discussed before. IDML is more useful for a one-time transfer of a document from one publishing system to another, or for processing through various external specialized utilities, and yes, IDML export would be VERY nice to have (as I myself also pointed out back when IDML import was first introduced - this thread is actually a duplicate, or possibly more? this has come up before...), but trying to use it in a collaborative workflow with differing applications is likely to be less than satisfactory. It would be nice to have the option to try, as well as being nice to have for other reasons, but please do keep your expectations in check as to how practical it would actually be to use it that way.

Some users have expressed that they are in work situations where they are so restricted in this area that if the tool supports it at all it is much harder for them to prove that they did not use these features, which they are strictly banned from using in their work situations - if they can show that they are using a program which does not have these features, or that these features are completely disabled in the software, it may mean the difference between whether or not they can use that software at all for their work. As I have said before, I believe the best approach to this is if those features will be introduced, they should be created as separate plugins to the software, so that those who want them and are allowed to make use of them can install the plugins, and those who are not allowed to have them or who do not want them can simply not install those plugins.

I suspect it is indeed a Windows-specific bug, as the Inpaint command is available when the pen tool is still selected under macOS.

Considering that Apple generally doesn't allow scripting for most types of apps on the app stores for the iPhone and iPad, it is unlikely that scripting support will be in the iPad version anyway (very likely limited to the desktop versions to avoid getting kicked out of the app store on the iPad), so these are obviously different branches of development. Regardless, one developer can easily have multiple skill sets, so how much overlap there may be between the development teams for these two aspects of the software is something impossible to guess at from the outside. Unless Serif comes out and tells us directly, we can't realistically determine that.

Hi @ElT, welcome to the forums! When combined with the Apple Pencil an iPad is a very convenient way to carry around a digital canvas for sketching and doing other forms of artwork anywhere the artist happens to be. I too am skeptical of Publisher being released on the iPad, but there are definitely use cases for the other apps, though in my opinion they are best used as a starting point for artists who are working with a pencil and starting a document which will later be polished and finished on a real computer after transferring the document. There are people who evidently do work more extensively on the iPad and even finish their projects there, though I am a bit less certain that is actually a good idea. As far as I can tell you can't really calibrate an iPad screen to professional standards when using it in a portable manner, for example. For some that may not matter as much, but for many it certainly does. There are, however, a variety of different users with a variety of different use cases and working situations, so while I may not really see this beyond the fact that an iPad makes for a very convenient and portable digital sketchbook and canvas, as well as a way to start working on a project while traveling or otherwise away from your main workplace and then finish it on a real computer later, that doesn't mean that there are not legitimate use cases for it out there.

It is not unacceptably bad, but it is much more complex than it needs to be. Others have long solved these things in much simpler and more convenient ways, and I have long thought it rather strange that Serif had opted to obfuscate the process of working with channels to the degree that they have. For example, just add an editability toggle to each channel in the list: if I want to manipulate the alpha, let me turn off the other color channels and leave just the alpha enabled for editing. Maybe an option-click on one of the toggles can exclusively select that one and de-select all others. Channels will never be layers - they are more like components of layers. If you have no layers, you have no channels; if you have no channels, you might still have layers. You can only paint on or interact with the intersection of a channel and a layer (or a set of such intersections). It is reasonable to ask that the channels be able to be manipulated in a manner which resembles the manner in which layers are manipulated, but channels will never be 100% substitutes for layers, or vice versa.

Some users would prefer that the existing AI features which were just added in 2.6 never would have been. Those which were added are not generative like the features being requested here; those are much more controversial right now than the AI selection tools that were recently added and are (hopefully) a long way off, as some users may not even be able to continue using the software if those ever get added to it.

Serif has indicated several times that they have no intention of adding animation support or 3D support to the Affinity suite anytime soon. You can't export animated GIFs because you can't create an animation in the software which could then be exported.

Why? The preview rendering in the background shouldn't prevent you from making adjustments in the foreground... as others have stated, you should be able to simply ignore the preview and make the changes you need to.

Curious that the first press of return or enter does indeed confirm the edit without confirming the dialog box. I would expect it to be the equivalent of clicking "OK" (an incorrectly labeled button in the Add Pages dialog - that should be renamed to "Add" or similar) or "Create" (a correctly named button in the "New Document" dialog), but instead the first one confirms the edit without proceeding with the action. Pressing the key again does the rest of what the first press should have done. If that is what you are referencing, then this should really be a bug report - it is not actually a feature request as suggested by where you have placed it on the forums.

Read the dialog more carefully: you asked it to add one page after page 4. "Number of pages" indicates how many pages you are adding. The box labeled "Page" is used to indicate where you want to add them.

VectorStyler throws away the shadow part completely when importing the original SVG posted here - there are imported entities for it which are selectable but they seem to have no visible effect. Inkscape is about the only thing I have that seems to handle that SVG "correctly" - it seems to use a few relatively obscure features that most vector tools are unlikely to handle in the intended manner and they are making a best effort attempt to map them to something they can handle. Neither VectorStyler nor Inkscape complain when importing the export from Designer, and even Designer shows that gray box when re-importing the exported SVG you provided, so they at least are consistent in how that one comes across. The export is obviously wrong here and should probably be reported as a bug, but I suspect the import is not a defect so much as the result of a best effort attempt to import the SVG in spite of its use of features which have no direct equivalent in Designer itself. As far as the "elements have been blocked" message, that appears to be a defect in whatever application you were later using to import the file. The data URL is not a major risk and at least on the surface appears to be within spec.

For my part I really wish companies that went subscription-only for locally executed software would lose their entire customer base and go out of business - Adobe, Renewed Vision, MoneyWell, etc. - as a warning to others not to follow this path. It makes sense for DropBox where they have legitimate non-trivial ongoing costs for you to use their offering - that is an actual service as opposed to a product - but not for productivity or creativity software that runs locally on your own computer.