fde101

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.

Improved request: add a generic y=f(x) graph plotter to shapes

Photoshop conforms all layers to a common raster DPI - the pixels are always aligned with each other, which means that the pixel selection can simply snap to the pixel grid and you always have entire pixels selected. The Affinity document format is a vector document format more like that of Illustrator, not a raster format like the one used in Photoshop. While there is a document DPI which is used as a default to set up a pixel grid for newly created pixel layers, for export previews, etc., when you scale a pixel layer it does not force that layer to conform to the document resolution as does Photoshop, as doing this re-rasterizes the layer and can cause a loss of quality. Instead, the DPI of different layers can differ. Because of that the pixel selection may select whole pixels of one layer and at the same time partial pixels of another layer - the different layers are not always aligned with each other. This is a situation which does not exist in Photoshop because of the different nature of the way the documents are structured, and thus something that Serif needs to account for which Adobe does not. Adobe is not "doing it" at all - they don't have this complication to begin with so they don't need to come up with ways to handle it. Also, the Affinity products are not Adobe clones - and this is a good thing. "Do it the way X is doing it," "do it because X is doing it," etc. are and should be poor methods of motivating or making recommendations to a software developer. If you are one and think it through you should hopefully come to realize that (note that I am a software engineer myself).

Yep, this was the first thing I thought of when reading this. ICO is fundamentally different from the other formats currently supported, so this would be an entirely different export model than anything currently in place. Not an insurmountable issue, but not a trivial one either. EDIT: to point it out, PNG and GIF are also universally recognized by browsers as favicon formats, and SVG is accepted by everything except Safari (though Safari evidently supports mono SVG icons, a curious restriction). I personally would rather see web sites switch to SVG as it allows vector icons.

The naive response to this concern might be to force pixel selections to pixel boundaries since they are operating at a pixel level anyway, but that doesn't quite account for the full set of situations when working within the Affinity document model. The problem is that a pixel or image layer might be positioned on a non-pixel boundary and might be scaled with a non-integer ratio to the document resolution (all this takes is using the move tool to resize a pixel layer - watch the context toolbar: the DPI changes for that layer). The question then becomes, which pixel boundary should the selection snap to? If you snap to the document resolution, you may not be aligned to the pixels of a selection you are working with, and vice versa. This does, as you point out, complicate matters when trying to figure out what to do at the boundaries of these selections. What may seem like an obvious decision to one person, might be a poor choice and cause problems for another.

... is a form of generative AI which has potential legal ramifications when applied at that level and many companies (such as the one I work for) have essentially banned their employees from using it - for many good reasons. It is a bad idea from the get-go given the current state of the technology: for one thing, the code it generates is derived from pieces of existing code written by other people which may be under copyright and thus open them up to lawsuits; for another, the way the code is generated does not give confidence of correctness and is likely to contain flaws which may take long enough to track down and fix (or even just to review a complex bit of produced code to gain confidence in using it) that it may have been faster to simply write the code from scratch to begin with. Those flaws may be from the AI having trained on bits of code which were already flawed upon input, or from the manner in which the AI itself stitched together different bits of code to try to reach some other end result.

In cases where a feature exists in one of the Affinity products (which are all built on the same engine and share a great deal of code from the look of things) and is omitted from another, these are rarely oversights and are in nearly all cases intentional decisions by the developers to help differentiate the products. Accordingly, no matter how much "attention" you draw to the request, as the developers made an intentional decision to omit the feature from one of the products, it is even less likely that a request like this will be granted, than one for a feature that does not exist in any of the products at all. The assumption that a relatively small number of users constantly drawing an attention to a request like this will increase the likelihood of it being implemented is probably misguided to begin with.

This setting is taken from the preset or template you use to create the document. Press Ready presets prefer linked and use a CMYK color model, others prefer embedded and use an RGB color model. If you need a different combination, you can create your own preset or template to use when creating new documents and configure them however you want them to work.

You can create empty ones with the desired properties and save them as assets, then drag them out of the asset panel. If you need them in matching positions across multiple pages you can also place them on master pages with the properties in place and ready to go.

Correct, and with the iPad versions it is not. Using Publisher or performing certain types of tasks in Designer or Photo is quite reasonable with touch, so it may quite well serve many users without needing an Apple Pencil or other stylus. Fine drawing using a finger is going to be a pain regardless of platform, however, so a stylus is a near-essential with a tablet depending on exactly what kind of creative activity you are trying to do. If people are asking for an Android version based on cost, I suspect they would probably be disappointed with its performance on any tablet they are likely to try running it on were it ever actually released. Android tablets which have performance even remotely close to that of an iPad generally cost as much as the iPad or more.

Yes, but the iPad versions of the products have UIs which are optimized for touch on small screens. The Windows version, like the Mac version, does not.

Serif said early on that they were initially focused on publishing primarily for print, rather than for electronic formats. Support for ePub would therefore have been out of scope with respect to that initial focus.

Many of the people asking for this are using Microsoft Surface "computers", the smaller models of which only have 13" displays. Some of those users probably don't have a stylus. You have a decent size screen on yours, and that can make a difference in how accessible a non-touch interface is when accessed using touch. A stylus with its more precise positioning can also make a big difference.