fde101

I copied and pasted your example into Nisus Writer Pro as well as Pages on my Mac, and they both do exactly the same thing you are describing.

Just to point it out, I usually see these things defined, for example, as removing from the cursor position to the end of the word under or after the cursor. Punctuation marks are not really part of a word, so the software probably doesn't recognize the presence of the word until you hit the alphabetic characters. That would be the word after the cursor, thus it would delete through the end of that word. I have seen various programs interpret these situations differently, but this does at least have a certain logic to it.

Under macOS it is command rather than control, and Command+Space is the system shortcut key for activating the system-wide Spotlight search feature, meaning pressing the keys in that order is something that the Affinity apps cannot intercept. Not sure if something similar might be going on preventing this on the Windows side, but at least on the Mac version, the equivalent of this is not really feasible.

It can be. If someone can show that they are using software which is not encumbered by the burden of integrated AI, and that they are not using plugins which add it, that will make it easier for them to certify that AI technologies were not used on a project they were doing for some company that forbids its use. Granted that is not something that most of us need to be concerned about, but it *is* something that *some* people need to be concerned about, and the fact that so many tools are integrating AI is likely making it harder for them to keep up with current versions of whatever they are using. Mostly because of that, I tend to agree that a native SDK is more important for Serif to focus on right now. Rather than integrating a lot of AI stuff at the core of the software, it is better to leave that for plugins, so that those who want the AI stuff can buy and install the plugins they want, and those who do not want it can still have a system that is free of it.

Animation support is probably a moot point as the Affinity apps don't support that anyway (not with GIF either), and currently they don't save metadata in some of the formats they export even when those formats do support metadata. Saving GPS data is often a risk with images that will be shared, depending on the nature of the image and why it is being shared, so be careful with that one. HDR support is probably the one major benefit on offer here.

There is a bit of a hack of a workaround. If you use Edit -> Copy Merged it will create a new layer with the content of the pixel selection. You can then double-click the thumbnail of the new layer to zoom to that layer's bounds (which at this point matches the selection), and delete the layer when finished with it. A bit of a run-around, I agree that adding "Zoom To Selection" would be a good idea.

I don't have any problems with it in the app itself either, so not sure what else to tell you on that one. Or a button on the adjustment layer itself to do an auto setting there, but yes, whichever way they approach it that would certainly be nice.

Auto Levels is a button on the main toolbar, but for whatever reason it is applied destructively (the selected layer is rasterized if needed) instead of being applied as an adjustment layer. Personally, I can see that blue just fine, including in the screenshot above. Do you have good lighting and is your monitor calibrated?

Ugh, that is really cheesy. Even from the outside looking in, I kind of figured it was something like that. I don't think Ventura Publisher qualifies as "obscure", more like "uncommon" though also limited by a poor choice of what platform to support, particularly in a time when it was even less common to use that platform for that purpose than it should still be now.

There is actually an FAQ entry about this:

This assumes the OP purchased directly from Serif. If the purchase was made from one of the various app stores, then the refund policies are those of the store in question.

Just switch to black salt. That way it will match the pepper and you can keep them together.

The red white and blue colors are directly associated with the US flag and are common in US holidays related to either the military or the nation as a whole (Independence Day, Memorial Day, Veterans Day, etc.), and the dashed lines bringing up the notion of stripes with the little white shapes resembling stars definitely give that kind of implication to a US audience (myself included). To those outside of the US who are not accustomed to the traditional US holiday decor, stepping back from it a bit, I can similarly understand how this would not imply anything of the kind. None of the shapes are actually stripes nor are any of them actually stars. I would imagine that being aware of the US holidays, Serif might have leveraged the color scheme and made some potentially intentional implications to help it fit in with the existing US holidays which happened to be going on at that same time, but at the same time, didn't really include anything that explicitly tied the sale to that holiday or made it scream "US" to a non-US audience. Of course, unless Serif themselves comment on the matter, it is all conjecture on our parts either way.

Serif is based in the UK; why would they have a 4th of July sale? The timing last year was likely coincidental, and appears to have been an attempt to leverage users' response to changes Adobe made to their terms of service at the time which had even more of their users looking for an alternative product to switch to as the new terms were actually quite bad. While there are sales from time to time they are usually one-time events.

This is not correct. Photo is still document-based, but simply lacks the tools to create artboards or pages past the first. Photo creates single-page documents on its own, but if Designer is used to create artboards or Publisher is used to create a multi-page document, those documents are ultimately native Photo documents that it can still work with if they are opened in Photo. Consider that Photo has a "New Document" window, a "Document" menu, etc.

There is a setting, both on the desktop version and on the iPad version, for whether the icons should be colored or mono. On the desktop, the icons you mentioned honor that setting, but on the iPad, they seem stuck on mono whether the setting is for color or not. Some users would have trouble with the icons being color because it can throw off color perception of the document itself and in a strict color-managed environment mono icons are definitely preferable, so it is critical to keep the option for the icons to be in mono, but for amateurs and other users who aren't as concerned with color accuracy (and to be clear, some professionals can certainly fall into this category as well depending on the nature of their projects), I agree it would not be bad to sync this behavior with that of the desktop versions. It is not clear to me why they would give the option for color icons on the left toolbar on the iPad but not on the others.

If you follow through with your analogy and make it fit the way global layers would work, it would need to be the case that every hospital in the world had the same number of floors and laid out their floors in the same way and that if one hospital decided to repurpose one of their floors, then every hospital in the world would repurpose the corresponding floor in the same way at the same time. Each hospital may have floors that are different shapes (master pages) and they may have different sets of rooms on any given floor (page content). I'm not too sure that actually works. 😇

If the frames are both on the master page, can't you just hide the undesired one on the master? Additionally, if there is more than one frame per language, couldn't you color tag them and use those to hide the frames via the States panel?

can be handled using the 3rd-party data mechanism of the IDML format. Adobe documented a method for plugins to include their own data in the IDML file, and specifically indicated that if the data is for a plugin that is not installed when the file is read by InDesign, it would simply be dropped / ignored when importing the file. If the Affinity apps stored their unique data (that which is not represented by the IDML format already) in the form of plugin data for a plugin which does not actually exist, they could recognize that data and use it to recreate the unique Affinity stuff when importing the file, but InDesign would simply ignore it. That way a single exported IDML file would offer the flexibility to be imported by any version of the Affinity software that supports IDML import (anything older than what recognizes the "plugin" data would simply ignore it, while versions new enough to recognize those properties could recreate the original Affinity document to the extent that the properties are recognized by that version), by InDesign or QuarkXPress (which would ignore the Affinity-specific properties as being data for an unrecognized plugin), as well as being used by 3rd-party utilities for processing the text where needed - killing three birds with one stone.

Oddly enough IDML export, if correctly and fully mapped to IDML import and extended with all of the features of the Affinity apps, would actually be useful for the same reason it was originally created: people using older versions of the Affinity software receiving documents from people using newer versions. If someone saves a document in 2.8 and sends it to someone running 2.7 they can't open it (hypothetical future product versions). If IDML export were available, they could use the same trick that the format was originally created for, export the file as IDML, and the user with 2.7 could then import it. This assumes that the Affinity apps can correctly interpret their own output, which is a more likely outcome than is the notion of Adobe products (or QuarkXPress) correctly interpreting all of the output of the Affinity products.

I don't think I would trust to read that far into the marketing blurb. Canva is more of an amateur graphics company, as hinted at by the fact that they want to empower "the world to design" rather than giving "designers the world" - their focus is not really on professional designers but rather on people who are not professionals but still want to design in spite of that; the "professional" workflows enabled by IDML, even with the acquisition of Serif, are probably not too high on their radar. The IDML format was originally created for moving documents from one version of InDesign to another (evidently Adobe couldn't quite get cross-version compatibility of their native format right so they created a separate format as a workaround), and it is something of a hack that other applications started working with the format. IDML as an interchange format outside of the Adobe ecosystem is not really a good solution for design interchange, it is simply the one that we have that maintains a larger portion of the original properties - a more stable format is PDF, but you obviously lose a lot when you use it, due to the nature of what PDF was designed for. Both formats originated with Adobe and they were not exactly trying to improve life for their competitors; even with IDML import things should not be expected to translate completely into a different application, and the same would be true in the other direction.

How is that even remotely relevant?

If you saved the document in 2.6 you probably won't be able to open it in 2.5.

JavaScript is a mess. It isn't fully aligned with anything. Different people have built on it over time in so many differing ways that there is very little coherency to the language. The need to maintain backward compatibility means that even when people have tried to "clean up" the language and enhance it in various ways, they ended up creating mutually incompatible versions of the language which are all "official" in some capacity and thus one bit of JavaScript code might not play nice with another even though any given runtime environment would still need to support both.

No it isn't. Python would not exist without machine language. ... may have been well-intentioned but was ultimately a bad one. Which may also be well-intentioned but can be misleading if done the wrong way, as this was. Indentation is visually helpful, but it is not enough on its own. Even in a "reduced" state there can still be a large amount of code for a given project, and if you have many levels of indentation then suddenly drop back several levels, such that the code is several screenfuls down, it can be difficult to follow where things line up. Having an "end" marker of some sort to count can make that a lot easier. ... as am I. I hate it. Yet another reason to view AI with skepticism. We didn't really need another one, but it doesn't hurt. Technically not always. Many implementations actually do "just-in-time" compilation and translate large parts of JavaScript into machine language to execute natively on the processor. There are Python implementations that do essentially the same thing. There are also Python compilers that perform static compilation and translate Python into machine language, just like most native languages would be. Apple's Swift language has a "repl" implementation (try "swift repl" at the command line on a Mac with the development tools installed) which compiles and executes Swift code in "real-time" as you enter it. There are ways to use Swift as a scripting language, in spite of the fact that it is compiled behind the scenes - the Swift compiler is quite... swift. Swift is not a great language either, but at least it delimits blocks somehow (sadly following primarily in the footsteps of C with its hopelessly cryptic syntax), and thus is at least preferable to Python.