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).

indeed, please fix that

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.

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.

QXP 2024 can now export to .idml
Viva Designer can import/open .indd files, and keeps up with changes to the format. The more complicated a design, there will be issues, but it will open.
Neither, like APub, deal with all .idml properties in a 1:1 faithful way with InDesign. Some do better with a particular .idml file than the others and vica versa.

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.

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.

Flip button in Toolbar? 
https://affinity.help/designer2/English.lproj/pages/ObjectControl/transform.html

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.

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

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

???

You mean this?

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

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?".

Hi @Joe Swann and welcome to the forums.
It's best to suggest features here as you've done but to report bugs separately in the bugs forum. I think it helps Serif with their workflow. I'll re-post the bug report now as I've seen it too and have been meaning to figure this one out. I replicated it just now and created a test document for it. Cheers.

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.

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.

You completely miss the point.
What is the licence for a Linux Distribution?

Blender is a great example of a program doing a terrible thing.
It is ignoring all OS conventions and rolling its own user interface, making it inconsistent with EVERY operating system it runs on.
 
The only legitimate reason it could possibly provide for that is to ensure neutral grays for more accurate color judgement.  That is the only reason that I would give it credit for, as most operating systems are lacking in providing for this requirement.  I consider that a flaw of the operating systems which should be addressed so that applications with critical color judgement requirements can inform the OS as part of an application manifest or an API call and the OS would provide an appropriate neutral gray appearance which is otherwise consistent with the rest of the environment.
 
Other reasoning I have encountered is generally misguided.  In particular, many developers cite a desire to keep the application consistent between operating systems.  The problem is that a user of a computer is likely to use multiple applications, and it is more important that they be consistent with each other than that they consistent across operating systems - someone sitting at one computer and trying to use four different applications will find things that work four different ways and trying to juggle them while switching back and forth is not a good thing.
 
Don't get me wrong, I have blender installed all over the place and use it from time to time myself - it is a great program in terms of the functionality it offers - but the situation with the user interface is something that should not be emulated, except by video games and other immersive environments.
 
The use of configurable panels to lay out controls appropriately for the task is definitely a good thing.  This is one area where Apple is making a misguided recommendation to avoid this.  It makes some degree of sense for consumer-level applications to limit options to some degree, as more casual users may easily get lost wondering where something disappeared to when the visibility and positions of panels are easily changed, but for many professional applications they are largely a requirement.
This does not provide an excuse for the controls placed on those panels to defy OS conventions, including scaling.  Other than the neutral gray issue, there is nothing that would prevent normal OS-provided controls from working in place of the highly custom ones Blender provides.
 
It would be better to design the app in such a way that this is not necessary, but if it is going to provide a global scaling feature, that is certainly the least problematic way to do it.
 
Yes, that is how things are.  It is NOT how things should be.  I think we are arguing two sides of a coin: I am indicating how I believe things should be, you are anchored in the messy situation of the unfortunate way things are (but should not be).
Different UI frameworks would be fine as long as they all ultimately followed the conventions established by the underlying OS rather than bypassing them.

Welcome to the forums!
Can't speak for Serif, but consider that this would be one more thing on top of what they are doing already and probably would have a negative effect on their ability to continue to develop the products they already have on the market, so it probably can't be justified given that there is a lot more competition in that space and users are already complaining left and right about features that are missing in the products Serif has released already.  Serif is a small company and their developers are already spread thin with the products they are currently maintaining.

The Apple LaserWriter was the first laser printer on the market to offer PostScript support, making general market DTP applications feasible for the first time.  Prior to that laser printers all had proprietary page description languages and worked with fairly expensive systems, making such tools impractical.

The problem is that Photo works with one document at a time, so your contact sheet would always have a single image on it.
Generating a contact sheet that spans multiple photos goes against the nature of the program.
I still think it would be a better fit for the DAM solution than for the existing software.
 
If any of the current Affinity products should get this feature it should be Publisher, though in a modified form - I could see being able to select a bunch of objects (photos or whatever) on a page and use an "Arrange as a Grid" command or similar, and possibly an option to display a source filename below or over top of each placed image.  If the grid arrangement specified too few columns/rows to hold the selected images, they could spill onto the next page...

Hi @desperatepotato, welcome to the forums!
This has been requested numerous times already and there are many duplicate threads on this subject.  It would be best to pick up this discussion on an existing thread for this feature rather than continuing this one as it breaks up the discussion and makes it harder to follow.
 
Here is one example of such a thread:
 

One of my problems is that I can have a great number of snapping candidates all over my work space. Therefore when zoomed in dragging a guide to snap to a chosen node or handle doesn't always work accurately as the guide may be snapping to an off-screen candidate. Constantly either turning snapping ON or OFF or unchecking different snapping features is a real pain!
Therefore a feature that lets you snap only to objects in screen view will save zooming-in in order to get an accurate position of a guide. Also what would make a huge difference is to stop handles and nodes from disappearing when moving a guide!