fde101

Serif is based in the UK; why would they have a 4th of July sale?
The timing last year was likely coincidental, and appears to have been an attempt to leverage users' response to changes Adobe made to their terms of service at the time which had even more of their users looking for an alternative product to switch to as the new terms were actually quite bad.
While there are sales from time to time they are usually one-time events.

Serif is based in the UK; why would they have a 4th of July sale?
The timing last year was likely coincidental, and appears to have been an attempt to leverage users' response to changes Adobe made to their terms of service at the time which had even more of their users looking for an alternative product to switch to as the new terms were actually quite bad.
While there are sales from time to time they are usually one-time events.

This is not correct.  Photo is still document-based, but simply lacks the tools to create artboards or pages past the first.  Photo creates single-page documents on its own, but if Designer is used to create artboards or Publisher is used to create a multi-page document, those documents are ultimately native Photo documents that it can still work with if they are opened in Photo.
Consider that Photo has a "New Document" window, a "Document" menu, etc.

Serif is based in the UK; why would they have a 4th of July sale?
The timing last year was likely coincidental, and appears to have been an attempt to leverage users' response to changes Adobe made to their terms of service at the time which had even more of their users looking for an alternative product to switch to as the new terms were actually quite bad.
While there are sales from time to time they are usually one-time events.

When you are requesting a feature, why are you using the digital equivalent of invisible ink?
I can't read that text unless I select it - the contrast is too poor with the dark gray text against the black background.
I'm guessing you might be forcing a custom color scheme of some sort in your browser and don't notice it, but the colors you are using make it unreadable for those of us with the normal forum settings.

There is a setting, both on the desktop version and on the iPad version, for whether the icons should be colored or mono.  On the desktop, the icons you mentioned honor that setting, but on the iPad, they seem stuck on mono whether the setting is for color or not.
Some users would have trouble with the icons being color because it can throw off color perception of the document itself and in a strict color-managed environment mono icons are definitely preferable, so it is critical to keep the option for the icons to be in mono, but for amateurs and other users who aren't as concerned with color accuracy (and to be clear, some professionals can certainly fall into this category as well depending on the nature of their projects), I agree it would not be bad to sync this behavior with that of the desktop versions.  It is not clear to me why they would give the option for color icons on the left toolbar on the iPad but not on the others.

There is a setting, both on the desktop version and on the iPad version, for whether the icons should be colored or mono.  On the desktop, the icons you mentioned honor that setting, but on the iPad, they seem stuck on mono whether the setting is for color or not.
Some users would have trouble with the icons being color because it can throw off color perception of the document itself and in a strict color-managed environment mono icons are definitely preferable, so it is critical to keep the option for the icons to be in mono, but for amateurs and other users who aren't as concerned with color accuracy (and to be clear, some professionals can certainly fall into this category as well depending on the nature of their projects), I agree it would not be bad to sync this behavior with that of the desktop versions.  It is not clear to me why they would give the option for color icons on the left toolbar on the iPad but not on the others.

As an output format, no.  CMYK is almost entirely print-oriented and printers simply don't have that kind of dynamic range or color precision, at least not at this time.
As a working format, however, there is a legitimate reason to consider it as it can help to reduce problems caused by round-off during calculations being performed during intermediate steps, as @Bound by Beans pointed out above.

There is a setting, both on the desktop version and on the iPad version, for whether the icons should be colored or mono.  On the desktop, the icons you mentioned honor that setting, but on the iPad, they seem stuck on mono whether the setting is for color or not.
Some users would have trouble with the icons being color because it can throw off color perception of the document itself and in a strict color-managed environment mono icons are definitely preferable, so it is critical to keep the option for the icons to be in mono, but for amateurs and other users who aren't as concerned with color accuracy (and to be clear, some professionals can certainly fall into this category as well depending on the nature of their projects), I agree it would not be bad to sync this behavior with that of the desktop versions.  It is not clear to me why they would give the option for color icons on the left toolbar on the iPad but not on the others.

If you follow through with your analogy and make it fit the way global layers would work, it would need to be the case that every hospital in the world had the same number of floors and laid out their floors in the same way and that if one hospital decided to repurpose one of their floors, then every hospital in the world would repurpose the corresponding floor in the same way at the same time.
Each hospital may have floors that are different shapes (master pages) and they may have different sets of rooms on any given floor (page content).
I'm not too sure that actually works.  😇

If you follow through with your analogy and make it fit the way global layers would work, it would need to be the case that every hospital in the world had the same number of floors and laid out their floors in the same way and that if one hospital decided to repurpose one of their floors, then every hospital in the world would repurpose the corresponding floor in the same way at the same time.
Each hospital may have floors that are different shapes (master pages) and they may have different sets of rooms on any given floor (page content).
I'm not too sure that actually works.  😇

Oddly enough IDML export, if correctly and fully mapped to IDML import and extended with all of the features of the Affinity apps, would actually be useful for the same reason it was originally created: people using older versions of the Affinity software receiving documents from people using newer versions.
If someone saves a document in 2.8 and sends it to someone running 2.7 they can't open it (hypothetical future product versions).  If IDML export were available, they could use the same trick that the format was originally created for, export the file as IDML, and the user with 2.7 could then import it.
This assumes that the Affinity apps can correctly interpret their own output, which is a more likely outcome than is the notion of Adobe products (or QuarkXPress) correctly interpreting all of the output of the Affinity products.

can be handled using the 3rd-party data mechanism of the IDML format.
Adobe documented a method for plugins to include their own data in the IDML file, and specifically indicated that if the data is for a plugin that is not installed when the file is read by InDesign, it would simply be dropped / ignored when importing the file.
If the Affinity apps stored their unique data (that which is not represented by the IDML format already) in the form of plugin data for a plugin which does not actually exist, they could recognize that data and use it to recreate the unique Affinity stuff when importing the file, but InDesign would simply ignore it.
That way a single exported IDML file would offer the flexibility to be imported by any version of the Affinity software that supports IDML import (anything older than what recognizes the "plugin" data would simply ignore it, while versions new enough to recognize those properties could recreate the original Affinity document to the extent that the properties are recognized by that version), by InDesign or QuarkXPress (which would ignore the Affinity-specific properties as being data for an unrecognized plugin), as well as being used by 3rd-party utilities for processing the text where needed - killing three birds with one stone.

can be handled using the 3rd-party data mechanism of the IDML format.
Adobe documented a method for plugins to include their own data in the IDML file, and specifically indicated that if the data is for a plugin that is not installed when the file is read by InDesign, it would simply be dropped / ignored when importing the file.
If the Affinity apps stored their unique data (that which is not represented by the IDML format already) in the form of plugin data for a plugin which does not actually exist, they could recognize that data and use it to recreate the unique Affinity stuff when importing the file, but InDesign would simply ignore it.
That way a single exported IDML file would offer the flexibility to be imported by any version of the Affinity software that supports IDML import (anything older than what recognizes the "plugin" data would simply ignore it, while versions new enough to recognize those properties could recreate the original Affinity document to the extent that the properties are recognized by that version), by InDesign or QuarkXPress (which would ignore the Affinity-specific properties as being data for an unrecognized plugin), as well as being used by 3rd-party utilities for processing the text where needed - killing three birds with one stone.

I don't think I would trust to read that far into the marketing blurb.
Canva is more of an amateur graphics company, as hinted at by the fact that they want to empower "the world to design" rather than giving "designers the world" - their focus is not really on professional designers but rather on people who are not professionals but still want to design in spite of that; the "professional" workflows enabled by IDML, even with the acquisition of Serif, are probably not too high on their radar.
 
The IDML format was originally created for moving documents from one version of InDesign to another (evidently Adobe couldn't quite get cross-version compatibility of their native format right so they created a separate format as a workaround), and it is something of a hack that other applications started working with the format.
IDML as an interchange format outside of the Adobe ecosystem is not really a good solution for design interchange, it is simply the one that we have that maintains a larger portion of the original properties - a more stable format is PDF, but you obviously lose a lot when you use it, due to the nature of what PDF was designed for.
Both formats originated with Adobe and they were not exactly trying to improve life for their competitors; even with IDML import things should not be expected to translate completely into a different application, and the same would be true in the other direction.

Yes, for sure.

Those commands do not actually rotate the image in the document, they only rotate the view on the screen.  When exported or printed the image will have the same orientation as where it started.

Those commands do not actually rotate the image in the document, they only rotate the view on the screen.  When exported or printed the image will have the same orientation as where it started.

As a workaround to a bug.  Long-term the solution to that is for the bug to be fixed rather than worked around.
The solution @PaoloT was hinting at (which is really for a different scenario) would also cover this if needed, if it were available, but as a workaround rather than a fix.
Thanks for pointing that out.

@Red Al, there have been numerous threads discussing these things in the past, so you might want to search for those to see what has already been discussed about this.
 
Publisher documents are the same as Photo and Designer documents; the color support is shared by all three apps because they can directly read and modify each others' documents.  It would not be practical when working on a photo to use global colors for everything, so in order for the documents to work well in Photo, Publisher needs to support non-global colors as well.
 
You already can - using the "Make Global" command in the context menu.  It needs to be in a document palette, however, as only document palettes may contain global colors; also, if the color was already used in the document, this will not "link" the existing use of the color to the palette entry, as it was not a global color when it was used in the document.
 
This is wrong.  Again, only document palettes may have global colors.  Modifying a color on an application or system palette will have no effect on the colors which already exist in other documents (or even in the current one).  This concern is a non-issue.

And rob the OP of the opportunity to practice using the search feature and thus be more familiar with it for next time?
 
Whatever... take your pick (though three of these are also redundant):
 
 
 
 
 
 
 

Yeah, scaling the glyphs definitely sounds like a misfeature to me also.

Many, many things are still printed; to name a few:
People still buy books, including printed ones. Labels for packaging. Menus for restaurants  Handouts/fliers for various events Maps for use in the wilderness / camping / hiking, etc., where power might not be available or reliable  
Additionally, digital media still needs to be designed before someone can experience it.

Many, many things are still printed; to name a few:
People still buy books, including printed ones. Labels for packaging. Menus for restaurants  Handouts/fliers for various events Maps for use in the wilderness / camping / hiking, etc., where power might not be available or reliable  
Additionally, digital media still needs to be designed before someone can experience it.

Welcome to the Serif Affinity Forums, @Anfa Hanif.
There are already (too) many threads about RTL support and image tracing, so it would be best to add your voice to one of those. Also, it’s a bad idea to raise two topics in the same thread, since it means that other users have to disentangle two unrelated discussions.