fde101

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.

As would I, which makes me question why Publisher is being used in the first place if ePub is the primary target - it seems it would be useful mainly for printed works and for works which will exist both in print and in electronic format. For the specific situation of exporting to target a reflowable ePub, if all you need is the story and objects embedded within that text flow, just export the story instead of the entire document, as I suggested in my post you are replying to. However, the part you quoted is referencing Word documents, which someone was suggesting as a more generic target while arguing against prioritizing ePub at this time. In a more general sense, independently of the specific use case of a novel or other similar document, this is not a good format to serve as the target of exporting an entire Publisher document. An individual story, yes, but a full Publisher (or other Affinity app) document, no.

Word processing documents, such as Word files, have a sort of primary text flow - the document is structured around a single story. Publisher has no such concept. It is likely that any given Publisher document exported to a Word file would need to use text frames for every bit of text, which is not particularly friendly to the kinds of tools that might try to process those files for any practical purposes. Additionally, some of the layout and typography capabilities that Publisher has probably don't map well to features available in such document formats. Not sure that I agree that exporting a Publisher document as a whole to a Word or ODT file would be practical at this time. Markdown would be impossible. What would be possible, and should be considered, would be exporting individual *stories* (series of linked text frames) to such files... but that would not accomplish the same function that the requested ePub export is intended to support. For a "reusable" export format, that would be more likely to take the form of IDML.

I haven't seen any indication that Serif is actively working to make reflowable ePub exports work. They may only intend to support fixed-format at first, as there isn't really any support for flexible layouts in the application at all, and that would be a whole other can of worms to try to implement. We probably won't know that until the feature is in beta. Also, we only know they are working on this because of an accidental leak, and Serif as a policy does not discuss timing, so we don't know when this will finally show up in a beta version - it may or may not be at the end of this year.

They already have, several times. More to the point it contains the heat. People keep opening new threads for this anyway so having one to point them to (and close the other threads) helps to reduce the clutter and keep the (pointless) chatter in one place. Close this and people just keep opening new ones without a place to corral them to. Windows 10 stops getting security patches later this year, so bad idea to start setting up new instances of it now. It has run its course - if you need a Windows VM, better to start off with 11. If you can't do that for whatever reason, and need to run 10, then make sure it is cut off from the internet (but note that you won't be able to activate the Affinity universal license or to use the various sync features they offer if you do that).

Not quite - it is basically the same operating system underneath, but many of the core apps and UI features come with two flavors, one which is optimized for touch/tablet use, and one for a more traditional desktop paradigm. The two "modes" determine which ones are presented to the user. This is one area where Microsoft actually comes close to the right idea, but mainly due to the need for backward compatibility and the like, can't really implement it as pervasively as would be needed to really get the experience quite right. As it stands, each individual application needs to implement this separately (or be built on a framework of some sort which does it for them) in order for the experience to work across the board. When apps do not do this, you wind up with an incomplete implementation (such as they have) which is less than satisfactory. Were they starting over with a new platform, without the need for backward compatibility, the user interface system could have been engineered with the UI component layouts and the like provided by the system with enough flexibility that apps could provide information to the OS that it could handle the UI layouts on behalf of the application (essentially a system-wide UI framework with the "mode" adaptation integrated from the beginning) in order to help enforce a more consistent experience for the user. Not likely to happen in existing systems, ever, due to the way that backward compatibility would suffer.

Microsoft Access is amateur at best, far from being "high-end". Even when a database is shared between users there are significant performance issues related to that data sharing and various tasks needed when updating the underlying database cannot be performed "live" while users are interacting with it. Other options in its category, which are cross-platform, include FileMaker Pro and 4D, though sadly many parts of 4D appear to have gone subscription-only at this point, so not sure I would recommend that any longer. It is kind of telling that there really isn't a meaningful open source application in this arena. Just about everything worthwhile has had at least an attempt at an open source equivalent pop up and gain some level of traction, but while a few projects have been started for something like this, they have never really made it very far - in spite of far more complex applications (including more advanced databases) having done so. These "middle-ground" database applications have become somewhat niche in our current computing culture, which may be part of the reason there are so few to choose from at the moment. On the other hand, various "industrial strength" database systems are available in open source (ex. PostgreSQL) and are *very* cross-platform. The higher-end commercial database systems tend to be more UNIX/Linux-centric than Windows-centric (ex. Oracle is mostly optimized to run on Linux at this point; while there is a Windows version of the Oracle server it is not as efficient as the Linux and the remaining UNIX versions). There are a number of CAD and math applications readily available on macOS, both commercial and open-source. I'm not sure why you would imagine that just because *some* database, CAD and math applications are Windows-specific they all are. That is not true with creative or productivity apps, and it is not true with these either.

For some types of projects they are. For others they are useless. All depends on what you are working on. There is a saying floating around the 'net that "if the only tool in your toolbox is a hammer, every project looks like a nail." I have Affinity Publisher, QuarkXPress and Swift Publisher right next to each other in my dock. Each has advantages over the others. Different tools for different projects.

If the black box is an object on the page or artboard, make sure both it and the artboard it is on (if any) have integer dimensions (position and size). If either of them has a fractional dimension that could be the cause of this - it is a commonly reported occurrence and has been discussed in various other threads here on the forums where you can find more information if that is what is going on.

Already being discussed in the "Scripting" thread - plugin and scripting support are being actively developed together and will be coming eventually but are not ready to be released yet:

This actually helps to underscore what is probably the reason that those distortions don't happen with the warp groups in Designer. The live mesh warp filter always produces raster results. With the warp groups in Designer you can Convert to Curves, which means the end results can be exported and remain vector in nature - something that can't be universally done with gradients and bitmaps.

Why would it need to? LaTeX is not just for equations; you can create entire documents with it.

In terms of version numbers? It is neither good nor bad. Just different.

Sadly, yes. The fact that Microsoft is still in business is evidence enough of that. They do, thankfully. I wish. The way that versioning is handled is not related to the quality practices of those involved. The version could just as easily be the revision number of a release snapshot from a version control system, and if the practices regarding development and testing are solid, the quality could still be very high. A company could use the same versioning scheme you propose, and release software of poor quality. Not bad, just different. There is a substantial difference between bad and different. Different can be good sometimes, as well as other times, just being... different.

This is not either/or, and it is not as simple as you try to make it out to be. The realities of software development are more complex than any of us would like. I agree that Serif is not handling this very well and that there is a significant amount of room for improvement, but I disagree with your classification of their practices as "abusive". You are taking it too far. I have no idea what it means in England, but here in the USA it generally means that the version is intended by the company to be used for production purposes. How buggy the software may be or how serious the bugs are is completely irrelevant to this classification. What you listed is the way that most companies handle versions, but it is hardly set in stone, with many pieces of software varying from this common usage, not just Serif. Apple for years used the second number to indicate a major release of macOS (10.1, 10.2, 10.5, etc. were major, not minor releases), as did PostgreSQL for quite some time. Both of them later changed strategies and now increment the first number for a major release. Serif's methodology is a sort of hybrid of this, with the second number being incremented for the equivalent of a major release (whatever they may choose to call it), and the first when you need to pay for the product again. This has been true of every second-number-incremented version since I have been using any of the Affinity products. 2.5 documents cannot be opened in 2.4, etc. Anyone who has been following the products for any amount of time should expect that by now.

As I understand it, in Japan it is common for people to say (the Japanese equivalent of) "blue" when they actually mean "green" - traffic lights turn green just like they do in other countries but in Japan the people would say they turned "blue". It is a rather curious part of that culture which may not make sense to anyone else. Windows is still not macOS, and is thus inferior, but does that mean that people using it are being "abused" by Microsoft? They are using an inferior product for sure, but that doesn't qualify as abuse. There are numerous reports of issues with this 24H2 release of Windows 11, some people going as far as reformatting their drives to try to get back to an older version because of all the problems it is causing - it is evidently a bad release, yet Microsoft continues to push it to people's computers. Is that abuse? I don't believe it is remotely accurate to say that the release versions of the Affinity applications are abusive. Nevertheless, Serif could definitely stand to make some serious improvements to their development and release practices. The list of known defects with a beta are far too long when they switch to release candidate status, much less put out an actual release. The goal should be zero known bugs (newly introduced or otherwise) at the time of any release.

I would actually suggest you simply learn to create those documents in LaTeX directly rather than bother with a DTP application. It has a learning curve sure, but if you regularly create documents like that, it would be worth it in the long run. That said, integrated equation support in Publisher would certainly be nice to have as well - I just don't think I would use it if I had to prepare a document like the example given there; I would more likely create it in LaTeX, as I did when I had such documents to prepare back in my college days (if memory serves I believe it was actually a requirement to use LaTeX for such documents when I was there, but it was a good one, at least for the math/computer science department).