fde101

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.

Save them together in a template. Use that template to create new documents. With the currently released version, that "template" would be a normal document that would be copied to create the new ones. More formal template support is currently in the betas for 1.8.

less if you watch for one of the sales that come up now and then...

In general I find that the Affinity apps label these correctly: Cancel when it is actually a dialog box and clicking the button will prevent the action from taking place, and Close when it is a properties window of some kind which can be used to modify some effect that has already been applied; closing that window will not prevent or undo some action. Resetting the keyboard shortcuts to the Affinity or Apple or whatever defaults is the activity which triggered this exchange. If the purpose of the action is to reset the shortcuts to the defaults then "Reset" (maybe should have been "Reset Shortcuts"?) would mean going forward with that specific action, while "Cancel" would mean not going forward with it. It's not just Apple pushing for button names to be verbs; several of the more common Linux desktop environments have the same thing in their guidelines, and a number of web site design sites are pushing for it also: https://developer.gnome.org/hig/stable/buttons.html.en https://hig.kde.org/style/writing/labels.html https://uxmovement.com/buttons/5-rules-for-choosing-the-right-words-on-button-labels/ https://www.uxbooth.com/articles/the-grammar-of-interactivity/

Ah, that's the confusion... many of you are still on the inferior platform. "Yes" or "No" would violate Apple's HIGs: https://developer.apple.com/design/human-interface-guidelines/macos/buttons/push-buttons/

The names of buttons in dialogs are always supposed to be verbs. "Yes" is not a verb. The buttons should be something like "Reset" and "Cancel".