walt.farrell

What commands?
What OS?

For others, or in case you're still missing the context:
 

I would then precise it in the name or description (even for other languages, as you did for English. In French, insécable=non-breaking and sécable=breaking) : 
em/en quad = breekbare em/en [+spatie if one wants] or Em/en spatie (breekbaar)
em/en space = onbreekbare em/en[+spatie] or Em/en spatie (onbreekbaar)
 
Since the difference is only the fact they are breakable or not, there was no point before computer composition to distinguish them: in older time, the decision to break or not was made by the typesetter operator.

Generally the resize step will do something, but will do it in a way you won't like. It would distort any image you apply it to that does not have the same aspect ratio as the image you used when recording the macro. And that probably is not what you want.
The usual recommendation for resizing images using macros is to use Filters > Distort > Equations which will not have that problem.
You can find more on doing that in the Resources section of the forums: https://forum.affinity.serif.com/index.php?/search/&q=macro resize&type=forums_topic&quick=1&nodes=11&search_and_or=and&sortby=relevancy
If your macro is truly doing nothing, I'm not sure what might be going on.
 

In the Data Merge Manager you can specify the separator you want to use:

 
But using LibreOffice Calc, I have no problem generating a CSV file whose fields contain the "," character, and which uses the ";" as the separator. And as mentioned above, any fields that contain a "," are automatically quoted. And the file works properly for Data Merge.
Samples (using Publisher 2.5.0.2402, but should open in Publisher 2.4):
data-merge-test.afpub Untitled 2.csv

From your description of them, though, em/en quad are not "non-breaking" like em/en space are, which would seem to give them a purpose: An em/en space if the surrounding characters are on the same line, but do not force them to be on the same line.
Or should their description be amended?

The applications are coded for specifications such as the OpenCL specifications, which are not provided by the OS but by an industry consortium.
The drivers and GPUs are also coded for those specifications.
Any of those (the application, or the drivers and/or GPUs) could be coded incorrectly. Sometimes it may be Affinity, but sometimes it is the drivers or GPUs that have the issue.
The Affinity applications will run without that requirement, as far as I know. And if the GPU/driver does not provide it, the settings will be disabled automatically by the application. The problem comes when the GPU/driver claims to provide OpenCL and Direct 3D level 12 support, but does not provide it completely or correctly or fully, then Affinity will enable it based on the GPU/driver's claims, and problems will result.
Both freezing and crashing can be due to errors in the GPU/drivers. It's not just display problems.
I have no idea what would be possible in this area, but it's an interesting idea.

Thanks @walt.farrell, I will study the link you have replied. All the other steps are working in my makro, except resizing. 

I don't think there's any way to invert a selection of layers directly.
With a single page PDF, you could Hide all the objects you currently have selected by Hiding one of them in the Layers panel. Then Select > Select All Layers, which will select everything that's not Hidden. Then Delete. Then select all the layers using the Layers panel, and unHide one of them.
 

But the chart includes both "em quad" and "em" and  "em spatië" is already used for "em".

In the Data Merge Manager you can specify the separator you want to use:

 
But using LibreOffice Calc, I have no problem generating a CSV file whose fields contain the "," character, and which uses the ";" as the separator. And as mentioned above, any fields that contain a "," are automatically quoted. And the file works properly for Data Merge.
Samples (using Publisher 2.5.0.2402, but should open in Publisher 2.4):
data-merge-test.afpub Untitled 2.csv

The descriptions are correct so you're right, there is one use case where you might use them.

You're right, now I see the conversion error too!

Thanks Walt (and RCR). Much appreciated.

I think my workflow is rather simple: I share a .dng (or other raw format) to affinity Photo on iPad to be able to process it in Affinity Photo. It gets opened in the Develop Persona etc.

When I save the file I choose to have it embedded in my .afphoto document. Seems quit straightforward to me.

I prefer to work in a wide gamut colour space, hence my choice for ROMM RGB.

Sometimes I want to go back to the Develop Persona while working on a file in order to change some basic settings. Not often, but it happens. That is why we can go back to this Persona, right?

I discovered this issue by accident, I was surprised by some colour differences between files from an older Adobe workflow and the ones I was seeing in Affinity. I noticed a difference in colour profile that I was not expecting etc.

Let me add something though:

When I changed the colour profile from sRGB to ROMM RGB I had some serious problems with the Selective Colour adjustments that I already made previously, I basically had to redo that.

I have a feeling that the default colour space setting is not stable in the iPad versions of the Affinity applications, they seem to change somehow back to the standard sRGB from time to time. I have no proof of that yet but I set a wide gamut colour profile as default but somehow they get changed back to a default sRGB, it seems. Not definite proof yet, though.


 

I don't think that's quite right, at least for Windows.
On Windows, the GPU and its drivers indicate their capabilities, and if they claim that they support the correct levels of processing and OpenCL, then Affinity Photo trusts that they are telling the truth and allows you to enable Hardware Acceleration.
Issues can arise when the GPU or drivers lie about having the proper support, or they have implemented the support incorrectly. (Or, I suppose, if Affinity Photo is using it incorrectly, but I'll ignore that as we have seen definite cases where it is the drivers that have the issues.)
I'm not sure to what extent that would be possible. If the error is one related to the on-screen display, such a test would require that the application be able to contain a copy of the expected screen display given a particular starting point and sequence of applications, and that it then be able to perform those operations and then retrieve, from the GPU, the current screen display to make a comparison. If that that retrieval is possible, then what you propose sounds like an interesting idea. 

I may not have understood what you want correctly but if you have selected the objects you want to keep, you can copy them to the clipboard & use File > New from clipboard, you will get a new document with just those objects in it on a canvas just large enough to enclose them all. Then if desired/necessary you could resize the canvas & export that to a new PDF.

With all the layers you want to keep selected, right-click one of the selected layers and select Lock

Select > Select All Layers will then just select the unlocked layers

I can't test it at the moment, because my PC is off, but if you have the layers selected, you want to keep, you should be able to group them and move the group to the top or bottom of the layers stack. After that, it should be easy to select the rest and delete it. After that you can ungroup the layers, if needed and wanted.

It is not possible to invert the selection of layers but you can use 'Select Same > Tag Colour'.
Select all objects via CTRL+A In the layers panel right click and assign a tag colour to all of them Then select just the few objects you want to keep and assign them in the layers panel a different tag colour Finally select one of the objects you want to delete (with the firstly assigned tag colour) and use menu 'Select Same > Tag Colour'. Then hit delete That should solve your task.
d.

In addition to installing the new content again, on the desktop applications there's a Beta section of the application Settings where you can re-import the retail content into an updated beta installation:

No, every one.
In V1 you always had to go to the download page, manually download, and run the installer/updater.
In V2:
with MSIX, you are prompted to Install or skip for now. Install automatically downloads the installer/updater, runs it, and restarts the application. with EXE/MSI, it's just like V1: you are prompted to Download or skip for now. Download takes you to the website where you must manually choose the correct version of the update program (MSIX, which is very prominent, or EXE which is more hidden), download it, and run it. So that sounds like you were using the MSIX version, which makes it strange that you lost your settings. Except that perhaps you're confused by the beta having different settings than the retail version has. The first time you ever ran a V2 beta, it would have offered to copy settings from the retail version. But only that first time. Any changes you made to your retail application settings after that would not be copied into the beta. (You can copy most of them from retail to beta using the Settings dialog in the beta, which has a Beta section that will allow you to copy the retail settings again.)
The MSIX versions keep their information in %USERPROFILE%\.affinity and you could backup various files or directories from there, and restore them later if you needed. The EXE versions use %AppData%\Affinity for the retail version, but something different for the beta from an experiment I just did. I need to do some more research on that before saying more.
 

Looking at your description again, yes, I think you were using the EXE/MSI version before. Which would mean you made a conscious decision to switch from the default MSIX to the EXE/MSI at some point. The EXE/MSI version has always required you to manually download the installer, and manually run it, even back in V1.
But when you go to the Download page for V2 during the update process, you need to be careful to choose the EXE version again, as the MSIX version is more prominently shown.
If you were using the EXE version before, you may well want to uninstall the MSIX version you just installed, redownload, and reinstall the EXE version. Then you'll have the advantages of the EXE that you perceived before, and your old settings back.

It worked!! @walt.farrell thank you 100 times. By using Edit > Defaults > Revert and then saving the document, the defaults are reverted and my sanity is restored. There does seem to be some kind of weird bug if you have an empty Artboard selected when you Revert... it turns grey. Not sure if this is just rendering or something more sinister.
If I ever figure out how this gets in this background color situation in the first place, I'll let everyone know.

Opening it in Publisher, and switching to the Text Frame panel, I can see that there's a Black background color set.
How it got there will probably remain a mystery, unless you have a file where it worked and then started happening, and you can check the History to see what happened. And if you have a sample like that, Saving with History might be useful.
You can resolve for future uses of Artistic or Frame Text by selecting one of those tools, and then using Edit > Defaults > Revert, possibly followed by Edit > Defaults > Save.