fde101

This has been discussed on several other threads; it already works on the Mac, either on a trackpad or on a Wacom tablet. Indications are that the Serif team is planning on bringing similar capabilities to the inferior platform at some point, but that it is generally harder to do on that platform which is why it is taking longer to get that in place. I would assume that when they get the rest of it implemented for Windows they will probably do so for touch screens also, but that is just my guess.

This piece of the puzzle sounds like it might belong in a bug report rather than a feature request?

This can be done with complex dedicated software, which is most likely how the print company would be handling it.

I believe this should be a feature request (to have Publisher recognize and discard the undesired text from the clipboard) rather than a bug report.

The original ASCII standard dates back to a time when some computers had a 7-bit byte size; it wasn't as "standardized" as the 8-bit bytes (octets) that are now ubiquitous. This gave a range of 128 code points that could be used to contain the character set. With a desire to have one code point map to one character, an entire set of basic characters was squeezed into these 128 positions. With most computers eventually using 8-bit bytes (the mainframes that ran MULITCS used 9-bit bytes, but those aren't really around any more either), there were another 128 code points available. People in different regions of the world would use different mappings for these "extra" 128 positions (128 - 255, or hexadecimal 0x80 - 0xFF), which became known as "code pages", while the first 128 (0 - 127, or hexadecimal 0x00 - 0x7F) would stick with the basic ASCII set for compatibility. One of the most common code pages was the "Latin 1" set. One of the problems with this arrangement was that with different people in different countries using different code sets, the same code would map to different characters for different people, so transferring files around the globe would be a bit of a mess. To help resolve this (and other problems with that arrangement), the Unicode standard needed a lot more code points. To maintain compatibility, the "Basic Latin" block of code points at 0x0000-0x007F maps exactly to the original ASCII character set. This means that the basic characters (such as the +, -, * and / characters) are in that block, and the second block is mapped to the characters from the "Latin-1" code set, again for compatibility with one of the more common arrangements. Additional characters become code blocks beyond those first two. Because of the history of how these code blocks were developed, they probably are not the most logical delineation for a user-facing glyph browser.

Ho @resultsphotography, welcome to the forums! You are in the "Photo Beta on Mac" section of the forum. For the Windows version betas, you should be looking here: https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/

Recreate the document? Once the document is saved in the beta it won't open in the (older) released version any longer.

I don't think I have ever seen anything that compares how effectively iPadOS uses the iPad hardware with how effectively Android uses its hardware. I would guess as well that iPadOS would be less demanding largely due to the fact that it is not encumbered by Java technology the way that Android is, but that would simply be a guess. I have seen a similar level of stability issues between the two platforms, but that is for my own use cases on the specific devices I own. Do you have any research data showing the difference in stability between the platforms? iPad has better 3D graphics support than android did up until recently. With the addition of Vulkan to recent Android versions I would expect that from an architectural perspective between the platforms they are likely on par now, but as Android hardware varies so wildly the quality of drivers will come into play, plus as has been pointed out, iPad does have the superior hardware at this point. For 2D graphics I would guess they are closer to matching, but it would be a guess on my part. As to being more "safe" and the relative lack of piracy, that is a trade-off: the closed ecosystem of the app store on the Apple platforms makes it easier to control things to the point that fewer risks are taken, but the downside is that they reject a number of categories of applications that are readily available on Android, making it worthwhile for some of us to maintain both platforms as we can do some things on each that can't be done on the other (at least not easily). This includes things such as some types of network diagnostic tools that will run on Android platforms but which require a level of network access that Apple won't permit under iOS/iPadOS. In this context perhaps, but this is not always generically true. Some software (including operating system software) can be provably superior when compared to others for specific use cases depending on how their algorithms handle various conditions. As a simplified example, consider memory allocation. When an operating system has X amount of memory and needs to distribute it across multiple processes (applications), there are a number of approaches that could be taken. If a process comes in and says "I need X amount of memory" then the OS needs to find a block of memory to hand to the process. Depending on how the data structures are organized by the operating system, the amount of time it takes to find that block of memory may or may not be predictable, may or may not have an upper bound on it, etc. It is also possible that the OS might need to allocate more than the amount of memory requested in order to keep the process of allocating the memory efficient, depending on its goals. For example, one algorithm might return the exact amount of memory requested if it is available but take an unpredictable amount of time to obtain it, say ranging from 1 ms to 30 ms but normally taking 3 ms or less. Another might return the amount of memory requested rounded up to the nearest 1 KB but do it in 5 ms every time. If you are creating a word processor, the "average" performance of 3 ms or less combined with the fact that the first algorithm does not waste as much memory would probably make it a more practical choice. If you are creating a medical device that patients rely on to keep them alive and it needs to perform some task every 40 ms precisely without fail, the unpredictable amount of time to allocate memory in that same first algorithm could result in someone's death. Again, this is admittedly a simplified and not particularly relevant example, but these types of trade-offs are all over the place when it comes to the design of a complex piece of software such as an operating system. Sure taste can come into play to some degree, but there are times when a particular piece of software (operating system or otherwise) is simply not suitable for a particular task, or perhaps is only available to run on hardware which is not suitable for a particular task, and there are times when the choice of algorithms and the set of facilities exposed by a piece of software are simply better matched to solving a particular problem.

My guess is that the "big ticket" items are in play by now though we may see a few smaller things sneak in before it is final... but that is just a guess. If nothing else I suspect they may still add a few more tests to the preflight panel and support for conversion of a few additional things from IDML.

Craft room and its ilk have been discontinued. I have a Gypsy I used with my old Cricut that basically died on me before I replaced it with a Maker. Design Space is overall better to work with than the old solutions, though I'm not fond of any of these relying so heavily on the outside world - if Cricut ever discontinues Design Space the way they discontinued Craft Room then there is no fallback for the machine to continue being usable. That to me is a Design Flaw.

Not at this time. There has been some discussion about the addition of a plugin API as well as scripting support, but there have been no indications of if or when this will actually be introduced, though from some of the replies that have been posted, the developers do seem to be open to the idea in general. I am not as familiar with how the Silhouette works, as I have a Cricut, but with Cricut Design Space it is possible to import an SVG. Users (including myself) have experienced issues with the SVG files produced by AD and a workaround seems to be to export a PDF from AD, import that PDF into Inkscape, then export the SVG from Inkscape to load into Design Space. I have found that this generally works. Does the Silhouette software support SVG import? That might be your work-around for the time being if it does.

While this may be applicable to some of the features I listed, consider that those features required a lot of work on the part of the application programmers way back then. The features being requested on this thread relate to manipulation of core features of the application's document model, which Serif is unlikely to be getting from an API or framework. Much like those other features I listed (which were likely "revolutionary" at the times they were introduced) would have been at the time, the requests in this thread are things that require effort on the part of the team developing the application and thus I don't think it is really a bad example (though I will admit I overplayed it a bit).

This is a duplicate thread. It has been requested before and Serif has already indicated this is not likely to happen in the near future.

If Serif wanted Publisher to happen it would have been released years ago. Oh, wait... You are talking about a relatively small company with a small development team whose products are used by many people who are constantly requesting all kinds of features and there simply isn't time to do all of them at once, so they need to prioritize. Just because it hasn't happened yet doesn't mean it never will. Your priorities are just that - yours - they may not match those of other users, or of the developers. A polygon tool was added to CorelDRAW after it had been around for over 6 years. Adobe Illustrator was around for 6 years before it supported layers. About 2.5 years later they started supporting gradients, then after another four years they added support for transparency (more than 12 years after the product was first released in order to get transparency support!). It took Adobe over 7 years to support table styles in InDesign after it was first released (Affinity Publisher had these basically from day one). QuarkXPress was around for 9+ years before they started supporting bézier curves. Compared to what the now "major players" offered when they first came out, the Affinity apps are off to a running start.

I agree that the behavior of the application surrounding the Develop persona is significantly less than optimal. From that standpoint, importing any image (RAW or not) gives you a "changed" working copy, because the file has been translated into an Affinity document. I don't think the file modified flag should be set for that reason alone, nor for this one. I suspect this was an oversight.

Unfortunately, Apple's Time Machine can only go backwards. They haven't solved the forward-in-time aspect of it yet (backing things up before they are created).

You will almost certainly be waiting permanently for this one. IDML is in the works, but INDD is unlikely to ever happen.

This makes the assumption that the software has accurate data related to the capabilities of the display, which may not always be the case. It would probably only be relevant when the display is calibrated by a device that encodes the display's capabilities in some format that is accessible to the application. Things could be further complicated in situations where the display is mirrored onto multiple monitors and they have differing profiles (such as using Sidecar between an iPad and a Mac). Covering all of these cases may make this more complicated than it is worth as many users struggle as it is to understand the color management options which are already available in the application and this could lead to far greater confusion... The idea is good in principle, but I'm not quite sure we are there yet with the underlying support from the technology that would make it reasonable to consider providing this within an application.

https://en.wikipedia.org/wiki/HSL_and_HSV True... and that is very likely to happen any time photos are imported into a CMYK document as well. That is probably a good idea... though it might actually be a better fit for Publisher by being added to the Preflight panel. Possibly, though HSL colors are not always 100% unique - it could also be that two different sets of numbers mapped to the same underlying RGB color value (as explained at the link above, HSL is built on RGB). I believe that is basically how QuarkXPress works? That is always a worthy goal, but note also that there was recently another thread where people were basically requesting the opposite. They wanted the CMYK values of swatches to remain unchanged when pasting something into a document with a different color space - they were more concerned about the numbers than the actual color for some reason related to corporate standards of clients or some such. I can see that with the K value (for blacks) if there is a desire to conserve more expensive color ink when writing out body text, and while I personally still think it would typically be better to educate those clients, there are obviously multiple factors to be considered.

Good, fast, cheap - pick two. You won't get the third.

While each of those programs offers a few things that are currently missing in Designer, they are also a bit lacking on core functionality themselves. As far as I can tell, neither one of them currently supports spot colors, for example, nor do they appear to offer the ability to export PDFs compliant with standards required by professional print houses, and those are both critical features for some users. Vectorstyler does seem particularly impressive for a first version, but I've been playing around with the beta a bit and have already found and reported a number of bugs that didn't take long to find... the person who I was in contact with was very responsive and they have already fixed most of them, but if I could find them as quickly as I did that tells me that a stable release is probably not just around the corner. I don't think Amadine is anywhere close to being serious competition for Designer, and while Vectorstyler may be for some subset of the AD user base, we still don't know what pricing will be like or how long it will take to stabilize and polish it to be release-ready. Even then there are other large subsets of the AD user base who would find about as much missing from Vectorstyler as others are complaining is missing from AD... just a different mix of things. So no, I don't quite think this is enough motivation to give the Affinity team a serious push. At the same time, I don't think they needed one anyway - they are most likely just waiting until they can implement these features the right way. With their existing support for spot colors, raster manipulation capabilities, three applications using a common file format, and so on... Serif has a much more solid foundation to build on, but that also likely complicates some of these features compared to those other programs.

In most "modern" macOS applications they are saving automatically, even continuously in the background. The entire concept of "save" is kind of blurred.

I personally think all governments should be gravitating toward open source platforms and away from proprietary software and applications wherever feasible. It eliminates several categories of risks and they are the ones who can least afford those risks. That doesn't mean the entire market of the country will follow suit.

InDesign has been able to do that for some time now, as can Scribus. QuarkXPress allows you to have multiple layouts defined within a single document (which QXP calls a Project), and each can have a different page size, but all of the pages within any one layout are the same size.

@TKM, welcome to the forums! To be clear, Serif did not "delete" these toolbar icons. They were never actually available in the Affinity series products to begin with - they were never added. I suspect that most of us don't want them. They simply waste screen space better spent on tools more relevant to the work itself.