fde101

It is one possible explanation for some of what you were seeing, but if that is the case and the app is not providing a mechanism for cleaning it up, that is a design flaw if it is not a bug.

Out of curiosity, is there some reason that shear was omitted from this?

Bear in mind that even minor version updates to the Affinity apps break file compatibility. If such an SDK were offered and a viewer app was built to support files from version 2.9 (picked at random), then as soon as 2.10 came out, you would need to choose between updating to 2.10 to take advantage of its improvements but losing support from the file viewer app until that app is updated with a newer SDK, or staying on Affinity 2.9, potentially losing compatibility with files from trading partners who *have* updated, until the viewer app is similarly updated. The one way around this is if the SDK uses components from the Affinity apps themselves, requiring them to be installed for the SDK to work - that would mean the viewer app could support displaying files from the Affinity apps only if at least one of the Affinity apps (of a compatible version) is installed on the system. If the communication between the SDK and the app is reasonably stable between versions, that could allow compatibility with the same files as the installed Affinity app(s).

This is what I see for "Subtitles/CC" on that video: If I view it on YouTube itself there is one additional message at the bottom that the setting only applies to this one video. That's it.

Looks to me like they are available in any language you want as long as it is French. Agreed, smart mode of the pen tool seems to do the same thing. The key differences seem to be that in Illustrator you double-click for a straight line while you control+click (Mac version) in the Affinity products, and in the Affinity products you hold down the command key (Mac) to move a node.

I'm going to have to disagree on this one. It is partly a matter of perspective. Blender does not conform to the user interface guidelines of practically anything - it is off in its own little world - so from that perspective, yes, it is a "foreign" piece of software no matter where you run it, with its own distinct learning curve and not quite fitting in with anything else. However, people did experiments in the past (before some of the sweeping improvements that have been made to the UI in more recent versions), and found that if they took someone experienced in Blender, and someone experienced in one of the commercial 3D apps, and had the Blender user and the other app user do the same thing (this was for modeling if I recall correctly), the Blender user could generally do it much faster. Blender's interface is not optimized for new users or to make it easier to learn (again, this has improved in the more recent versions, but it still is not the main focus). Rather, it is optimized for speed of working after you learn it. Someone who spends a lot of time working with Blender can become very fast in what they are doing - this is one of its primary benefits. Blender is an example of a true professional interface for people who heavily use the same app frequently. It is not a good UI for people who use it sporadically or for people who want to walk up and just start using it (again, this is improving with the current versions, but is still not the main focus). When you look at it from that perspective, Blender is a program that people try to conform to a different mold than the one it is primarily intended for, them come away from it disappointed that it is not what they expected. When you approach it for what it actually is, the interface is quite good. Of course, it is not completely perfect even within that category, as evidenced by the fact that they chose to base their scripting on the Python language. Sad.

If trying to flip a layer that covers the entire document area I'm also not sure how this would be useful, but consider a smaller layer which has some element which is visually aligned with something behind it at a specific vertical position. If you want to flip that upper layer but keep it aligned, you would want to anchor the flip at the position which should remain aligned. Another example might be a shore line where you want to reflect a building into water which is below the line. If you duplicate the content then flip it at the line this may sometimes give you a good starting point for positioning the reflection. One method of getting close to this is to resize around the transform point by dragging the appropriate top/bottom/side handle while holding down (command on the Mac); if you resize past the transform origin it will have the effect of flipping the layer, the catch being that you need to manually match the size to the original size and it may be slightly off. For a reflection this is probably not much of an issue as you would likely wind up resizing it anyway after the flip and with this technique you can do both in one step... for other use cases how much of an issue it is will vary. I agree that having it flip around the transform origin when the origin is enabled would be a good idea, and I believe this has been requested before at least once or twice.

Hi @CraftyRobin, welcome to the forums! In the interim, you could try using the pen tool and clicking once at each of two points to create a straight line; after switching to the move tool with that line still selected, the "R" (rotation) shown in the Transform panel should give you the angle of that line.

This behavior would break if the frames were on a master page. Try this: in a new document, put two text frames on a master page. Go to the document page and paste a large amount of text into each of the two frames. Auto-flow one of them. You wind up with X number of pages, each with text in the frame you auto-flowed, and on each page a blank frame that came from the master. Thankfully, the existing feature is smart enough to link the frames when you auto-flow the other one - it does not create new pages as long as you do it right away without putting content in the intervening frames (if you do, then auto-flow creates new pages at that point instead of reusing the existing ones, which is understandable but also undesirable). Making this a property opens the possibility of having the frames pre-connected when any auto-flow activity takes place, which has the benefit of reducing the likelihood of a user accidentally putting something in one of the intermediate frames and disrupting a later auto-flow at that point. It could also be pre-rigged and tested in a template.

Why not make "autoflow" a property (checkbox) of the text frames? Not only would that solve this problem but it could also connect separate frames from the same page which are also set to autoflow so that if you have parallel stories which are independent of each other but which both span a shared set of pages (ex. a parallel bible where there are two different bible translations side by side in columns but each spanning the same set of pages) then both sets could be connected with themselves (but not each other) automatically as pages are added.

Yeah, that can happen. Quoting from Wikipedia (https://en.wikipedia.org/wiki/ILBM):

You should be able to bulk convert them using the free ImageMagick utility. Alternatively, if you are on a Mac, GraphicConverter (can be found on the App Store or at https://www.lemkesoft.de/en/products/graphicconverter - about $40 for a new license) can do the same thing with a graphical interface (GraphicConverter has long been a "Swiss army knife" graphic file utility in the Mac world; ImageMagick is a command line utility which is cross-platform but which is probably best known in the UNIX/Linux world).

Seems that those options work in RGB space anyway meaning the photo would already be developed by the time they are applied, so the value of having them in the Develop persona as opposed to leaving them for the Photo persona (after development) seems like more of a convenience thing than anything that would actually improve the quality of the results. It makes sense that dedicated development tools would include that as it enables them to be used to complete many photos that don't require the more advanced editing possible in a destructive tool such as Affinity Photo, but in the case of the Develop persona, it is basically to customize the development of the RAW data before the image gets sent to the Photo persona where you would be working in RGB space, so the important tools to have in the Develop persona are the ones that can provide quality benefits during development, and the ones that can impact judgement of the controls that would impact quality of development. I'm not quite sure that this really falls into that category for its normal usage.

Yes, in the Scope panel which is hidden by default. That said, I have two major issues with the Scope panel which make it next to useless for most real-world applications: You can only see one scope at a time. For example, I can't have both the RGB Parade and the Vectorscope (the most powerful combination of the available scopes) visible at once. The only pseudo-scope you can have on with one of the others is the relatively worthless Histogram which is in a panel of its own and visible by default in the Photo persona. It can't be resized. You can make the panel wider, but the actual scope within the panel has a fixed size and simply centers itself. You can't make it taller so you are stuck with one tiny scope at a time. Compare to Resolve where I might show a two-up or four-up view of scopes and move them to a separate monitor which is only showing scopes so that I can actually see the details. The scopes in Photo are too small to tap their full potential. The fact that they show the histogram by default and not the far more useful scopes is kind of sad, but that at least can be worked around. Being limited to one scope at a time is inconvenient. Not being able to resize the scopes is crippling.

Yeah, they made a big deal of being able to open and edit the files and "convert AI files into other formats when needed" - nowhere do I see any indication that it can actually save back to AI format after editing them: https://www.pixelmator.com/blog/2023/12/20/pixelmator-pro-now-supports-ai-and-eps-files-from-adobe-illustrator/ I have the version where this was added and here are the options I see for exporting a document: Here are the options when saving a document: I don't have any AI files to play with but I too am skeptical that whatever you are editing from an AI file is actually being saved in AI format. Are you sure it is not saving your modified AI file in its own native format?

Hi @Eric Designer 2023, welcome to the forums! In general it is best to limit a thread here to one feature, and to at least try to search the forums for existing threads making the same request before starting a new one. These things are specified in the guidelines for posting to this area of the forum. Many of the things you are asking for have already been discussed in the past and there are existing threads on these topics; a few highlights and comments: We have basically been told that Serif does hope to implement this at some point, but they are not content with the solutions they currently could use, so it may be some time before this appears as they want to develop something better for when it does come out. Unlikely to happen due to the proprietary/undocumented nature of these formats. Serif has been adverse to adding any 3D features to the Affinity apps and this has often been lumped in with those (correctly or not). There are multiple threads where people are begging for this; indications are that it will come eventually. This has also been requested multiple times; I don't remember Serif specifically commenting on how likely this is to happen, but given the plethora of 3rd-party tools which are inexpensively available (in some cases free) which can easily generate these and export them in a form that can be used within the Affinity apps, I would imagine it to have a relatively low priority compared to various other features which have been requested which would not be so easily done outside the apps. I vaguely remember seeing that even PSD text objects are not fully supported because they are not as well-understood (possibly proprietary/undocumented) as other types of layers? I would imagine that to be true of the effects also... Some PhotoShop plugins are supported. An SDK for native ones is already under development (see the "Scripting" thread pinned at the top of the forum, in which both a scripting API and a native SDK for compiled add-ons are being discussed together). INDD is proprietary and undocumented and its internal format is known to change between releases, so support for that is extremely unlikely. IDML is currently supported for import only. Note that this is also true of QuarkXPress: it can import IDML, not INDD, and likewise does not currently support exporting IDML. I can't imagine them implementing XLS support at this point. I could see XLSX but tables in general need a lot of work in Publisher and there are probably bigger fish to fry than XLSX import support (ex. a table in Publisher cannot currently span multiple pages). Limited imposition functionality is currently integrated into the Print dialog, but is curiously not available for "proper" professional PDF export (which has been pointed out and complained about many times in other threads). Extending existing imposition features to the Export dialog for PDF would be more than welcome and I too would love to see that happen. A few other options could likely be added within reason, but more complete imposition functionality is likely better in the domain of a dedicated application designed for the purpose. A preflight inspector for already-exported PDF files is likely best handled using a separate dedicated application. There are already pre-export preflight features available in Publisher, but they are not included in the other two applications, and I would not expect that to change in the near future as it was obviously a conscious decision on the part of Serif to limit them to that one application. Note however that Photo and Designer files can easily be opened in Publisher to perform any needed preflight work.

I would be slightly hesitant to duplicate the file from the finder while it is open in the application due to the way the Affinity apps appear to use the files, but even assuming that is safe (would be curious to get a comment from Serif on that one), this is apparently two keystrokes too many to satisfy the OP. I rarely if ever do this so I don't particularly care myself, was just pointing out this is likely possible to work out that way for those who really feel that this impacts their workflow.

In the interim, there is probably some way to automate that series of steps using a macro utility like Keyboard Maestro (on the Mac)...

I believe he may be looking for a specific option to flip an artboard. There is not an artboard-specific option for this; you can flip (or for that matter rotate) an artboard the same way as with any other layer.

Hi @Mosabqadan, welcome to the forums! This limitation is not specific to the iPad versions of the apps - right-to-left and vertical text is not supported on the desktop versions either and this has come up in numerous other threads already over the past few years.

Yep, already in the Designer toolbar by default and can be added to the Photo one.

No gorilla tool either. Sad.

Haven't used it heavily enough to have noticed the kind of instability you are asking about, but the user interface is certainly far less optimal for a touchscreen than was the v1 series on iPad. They reduced some of the gap in terms of features between the tablet and desktop versions (sadly have not closed it as a few key things are still missing) but at the cost of usability. You don't use an iPad for a professional working environment - that is what Macs are for - you use an iPad for convenience and portability. The v2 updates lost some of both, as in my opinion, the interface is much less convenient unless you have the larger screen space of an iPad Pro (which I do not) or connect external hardware (keyboard, mouse, whatever) to work around the interface flaws... There are some benefits from what they did, but on a whole it is a net loss for many users.

No. UNIX was originally an operating system released by AT&T's Bell Labs. Various forks of the UNIX code became the various UNIX platforms (Solaris, AIX, HP-UX, SCO, etc.) which continue on long past the death of the original UNIX (a few versions of which you can download for free now and run on PDP-11 emulators if interested). In order to promote portability of applications among these and other systems the Portable Operating System Interface standard (POSIX) was developed, which various operating systems (including UNIX, Linux and even Windows at one time) have offered compatibility with, either as their core interface for their own native applications or as an alternative API to allow "portable" code to run on an otherwise proprietary system. UNIX later became a "standard" that companies could be certified to use as a label for their platforms, with several of the traditional UNIX vendors paying the fees and meeting the requirements for certification (as macOS currently does). These standards, like POSIX, relate to the programming interfaces and the command line environment and largely ignore any graphical desktop interface which may or may not be sitting on top. Tanenbaum developed a microkernel operating system called MINIX which is largely designed for POSIX compatibility but which uses a microkernel architecture, which he has argued in defense of at various times. I tend to agree that microkernels have major benefits over the more traditional monolithic kernels that most operating system platforms continue to use, but the same could be said in the other direction as well, with monolithic kernels having a different set of advantages. Several of the benefits of a microkernel make this architecture superior as a teaching tool (when studying the source code) and MINIX was designed for exactly that: to be something that students could study and learn from. Linux was a personal project Torvalds started as an experiment / learning opportunity of his own, but he opted to develop it as a monolithic kernel rather than a microkernel, which Tanenbaum (who Torvalds had been a student of) evidently took exception to and started those "debates" in an apparent attempt to steer his student back to what he saw as a preferable design (and was probably right). Linux, like MINIX, was never based on UNIX source code, but follows many of the design principles and has a high degree of POSIX compatibility, in spite of having a very different underlying architecture from that of MINIX. Note that the whole microkernel vs. monolithic kernel debate is largely tangental to the UNIX vs. Linux vs. macOS vs. whatever debate - it has nothing to do with whether or not something is "UNIX" or "Linux" or for that matter implements some version of the POSIX standards.

The problem here is that Tanenbaum's primary argument is against a monolithic kernel design, an argument which applies equally to UNIX, as many UNIX systems are even more monolithic than the Linux kernel, which at least supports a form of modularity with its kernel modules. A possible exception is macOS, which does use something closer to a microkernel, though not a true one. The remainder seems to be more historic in nature, as it relates to things which have long since not been true. Point being, by your apparent interpretation of Tanenbaum's arguments, UNIX in general is even worse than modern Linux, with the catch being that most of the "debate" was related to things that are no longer true or are no longer relevant, as both Linux and the hardware landscape have changed significantly since that time.