fde101

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.

Fair point. macOS is indeed a UNIX platform under the hood, and a certified one at that, but the graphical user environment it presents is sufficiently different from that presented by other UNIX platforms that for users who would be using it in the capacities described here, it would not be as natural of a jump as Linux would be. I would argue that it would be an improvement, but many apps are written against the X11 environment and would be harder to port and have come across in a way that makes them as straightforward to work with, etc. Most traditional UNIX workstation environments had graphical interfaces based around some flavor of MOTIF, which is also available on Linux. Newer ones are actually using GNOME or environments derived from GNOME, which went the other way (was popular on Linux first). This includes, for example, OpenIndiana, which is built on an updated version of the OpenSolaris kernel from back when the bulk of it was released as open-source. Not certified, but real UNIX nevertheless. Solaris had transitioned to GNOME as its desktop environment prior to that as well. How so? Personally I find it to be about the same in most respects. Each UNIX platform is different from the others, and Linux is different in largely the same ways.

In its current form, this does not solve the problem presented. For this to be relevant there would need to be a button on the toolbar (for example) and (ideally) some shortcut to disable moving the object, and instead causing it to transform based on the handle closest to the mouse position when you dragged over the object in a place where it currently moves it. An option to freely transform the bounding box without transforming the object it represents would be interesting, but I'm not sure how that is relevant here either. Agreed. Holding down a letter which is assigned to a tool (in this case the Shape Builder tool) temporarily switches to that tool. In order for this to work they would need to be independent tools which is not how the Affinity products tend to roll - they generally gravitate toward fewer tools with each being able to do more.

Those that primarily do VFX and 3D work, yes: That shouldn't be too surprising though as many of them would be moving from other UNIX platforms (IRIX from SGI was at one time a major player in this field) rather than moving from Windows. Linux is a much more natural shift from UNIX platforms than Windows or macOS would be. Many more are likely using Linux for servers. Most workstations in non-VFX post houses are more likely to still be either macOS or Windows. As has been pointed out, the apps simply aren't there yet - some are, but not enough of those which are currently in heavy use.

In all fairness, that thread is called "Scripting" so someone new to the forums could easily miss the fact that it also discusses that a future plugin API is under development. @sveinbjorn, welcome to the forums!

???

This might qualify as a bug report, however, in which case it is in the wrong place.

Agreed, if implemented that would provide a better (and much more flexible) solution for this particular problem than would a new shape tool.

Swatches are designed to maintain consistency of color throughout a document. Placing an *editable* hex color field on the Swatches panel runs contrary to its purpose and the very notion should be immediately dismissed as a bad idea. Also, hex values are only of interest to web designers and do not scale well: they only reflect 8-bit-per-component RGB and do not account for HDR, CMYK, etc. Swatches may represent spot colors, which by definition are not RGB, or even CMYK; even though they have RGB/CMYK representations for display and printing on devices that do not have true spot color support, displaying RGB values for them could be considered misleading. Similarly, displaying hex values for swatches representing CMYK colors can be similarly thought of as misleading. Including them on RGB and RGB-related color space color pickers in the Colors panel makes a lot of sense and should cover the needs of most web designers. The value of including them on the swatches panel, together with the potential for confusion it may cause, seems questionable. What might make more sense is to include a *label* (read-only display) explaining the selected color. This could show the hex color of the selected swatch if the swatch is an 8-bit RGB (or related) color swatch, but show the CMYK values of a CMYK swatch, the Pantone number of a Pantone swatch, etc. This would scale better to support the range of colors that a swatch might represent, without being misleading, and without raising questions like "If I change those values what happens to the swatch? Am I editing the swatch or am I disassociating the selected object from the swatch and giving it a different color?".

All being said, the way that it responds vs. the way it is visualized are definitely in contrast. If it is to work the way it does, it would make sense to reverse the shading, or failing that, to remove it and leave it as a plain ordinary slider. Note also that there are Lift, Gamma and Gain controls in traditional color grading toolsets such as Resolve, and the Gamma control in Resolve does work the opposite of what is described here - moving it to the right makes things brighter, to the left darker - so there is precedent in other software for making it work more logically and less mathematically. Most of the people using the software are more interested in the creative effect of the tool than in the math behind it.

Designer is NOT an SVG editor as Inkscape (for example) is. When you "open" the SVG in Designer it converts the supported part of the SVG file into its own native format, which does not support animation. You are not editing SVG any more - you are editing a Designer document which was populated by copying things out of the SVG. Anything that was in the file that Designer cannot translate would not have come across, so whether the "Save" option is permitted to overwrite the original file, or you explicitly export it in the menu (which is what Save would be doing anyway if they did enable it as a shortcut), the animation would already be gone.

Should this be moved to the bug report area?