Guillermo Espertino

Social media templates in Affinity designer have a 144 dpi setting by default, which causes that exports from the export persona at 1x size end up at half the expected pixel size.
For instance, a square post o 1080x1080 px is exported as 540x540px.
This is clearly a bug, since it's to be expected that a document defined in pixels is exported as pixels as well, and sizes in pixels should be honored.
I understand that the resolution value is important for HiDPI displays to show the proper "screen size", but a pixel is still a pixel and the default export behavior should be 1:1. Exporting doubled or tripled resolution for HiDPI displays should be managed by an option that doesn't interfere with normal exports.

No, it's not a matter of standards. The resolution of a raster image for the web is a meaningless value, as nobody uses physical sizes for screens.
You don't design a facebook cover to be 15 cm. wide. You use the pixels size defined by the platform.
When the units in a template are pixels, the normal expectation is to get an image of the same amount of pixels on export, not something else.
Apart from that, there are no standards for monitor resolution. It would be ridiculous.
Just think about this: If you have a Full HD 23" monitor, does it have the same resolution than Full HD 24, 26, 27 or 32 inch monitors?
What about Apple? The 14 and 16 inch macbooks pro have the same resolution with different sizes (254 ppi) but the 13 inch macbook with retina has 277 ppi.

Could a slug area option be added as it could be a quite useful feature to have?

The issue "App freezes when shift+click twice in a blank space with Art text or frame selected. " (REF: AFB-6977) has been fixed by the developers in internal build &quot2.2.0.1925&quot.
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

Hi - pleased to say we have now added OCIO v2 support in the latest beta (2.2). We'd really appreciate if you wanted to try it in the beta (sign up to beta program here), but if not this means it won't be too long before it's made available in the release version.
 

This is a known bug that is currently logged with our developers it should be fixed in a future update.

The issue "PDF bleed differs when exporting using the Books panel" (REF: AFB-7715) has been fixed by the developers in internal build &quot2.2.0.1857&quot.
This fix should soon be available as a customer beta and is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Serif Info Bot to notify us.

We are pleased to announce Affinity Designer 2, Affinity Photo 2 and Affinity Publisher 2 are now all updated to version 2.1.1 (for all existing customers on all platforms).
Here are links to the release notes
Affinity Designer 2.1.1 for Windows               ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Designer 2.1.1 for macOS                  ( Mac App Store and Affinity Store ) Affinity Designer 2.1.1 for iOS                        ( Apple iPad Store )
  Affinity Photo 2.1.1 for Windows                    ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Photo 2.1.1 for macOS                       ( Mac App Store and Affinity Store )  Affinity Photo 2.1.1 for iOS                             ( Apple iPad Store ) 
  Affinity Publisher 2.1.1 for Windows              ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Publisher 2.1.1 for macOS                 ( Mac App Store and Affinity Store ) Affinity Publisher 2.1.1 for iOS                       ( Apple iPad Store )  Please follow this thread here to get notified when any new releases are made.

I love the variables that I can use in the export settings for each slice. However, I miss a variable that holds the name of the document.
Whe I export slices of images from multiple documents, this would be very helpful for leter finding the source document when I recognize I a mistake when looking at one of the exported slices.

I would like to be able to display the active document filename in the main Affinity Designer window title property (it shows "Affinity Designer" by default).
Why? Well, to be able to get the time spent on a particular document using tracking software. I'm using Manic Time which extracts the application / document name from the active window title . This is useful when you want to know when and how long you've spent time on particular document, when doing client work. By default in Affinity Designer the document name is not displayed in the main window title, but on the "docked" windows but unfortunately not visible.

Another approach not requiring third party tracking software would be to add document time tracking within Affinity Designer, similar to Microsoft Word where statistics for the document can be displayed using the Info button where the Total Editing Time can be displayed.
Workaround - using floating window
I found that it is possible to display document name when using floating window document), then the floating window can be tracked. But It's a bit messy to resize the window, screen real estate is not used that efficiently, and also it's easy to "dock" the window by mistake (which hides the document name again). 
An idea to add an option for displaying document name in the settings like this:
General / Display active document name in main window title

Hi @Guillermo Espertino
Your comment has been split into its own separate post here

Do you seriously think it is reasonable that a simple task as exporting an image for the web coming from a 1080x1080 pixels template requires a seasoned designer with 30 years of experience in computer graphics to check the documentation in order to understand how it is supposed to works?
I can see it's a design decision and that the output is consistent with that decision. I'm saying it's awful user experience as it collides with the meaning of "pixel". Resolution doesn't belong to a raster workflow with pixels as units. The current design fails to address that.
Vectors have to be rasterized to be exported as bitmaps, I know, but when users pick a template set to pixels or create an image with pixels as units for screen delivery, they expect pixels.
I'm going to leave this thread alone and stop repeating myself, but please Serif, revisit this design and consider some options that don't mess with pixels and resolution when screen units are used. I'm sure there are ways to do it without breaking the valid use cases (i.e.: export for physical media).

We are pleased to announce Affinity Designer 2, Affinity Photo 2 and Affinity Publisher 2 are now all updated to version 2.1.0 (for all existing customers on all platforms).
Here are links to the release notes
Affinity Designer 2.1.0 for Windows               ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Designer 2.1.0 for macOS                  ( Mac App Store and Affinity Store ) Affinity Designer 2.1.0 for iOS                        ( Apple iPad Store )
  Affinity Photo 2.1.0 for Windows                    ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Photo 2.1.0 for macOS                       ( Mac App Store and Affinity Store )  Affinity Photo 2.1.0 for iOS                             ( Apple iPad Store ) 
  Affinity Publisher 2.1.0 for Windows              ( Microsoft Store and Affinity Store [as sandboxed MSIX and unsandboxed MSI/EXE] ) Affinity Publisher 2.1.0 for macOS                 ( Mac App Store and Affinity Store ) Affinity Publisher 2.1.0 for iOS                       ( Apple iPad Store )  Please follow this thread here to get notified when any new releases are made.

Thank you for the report, I've logged this with the developers to investigate further.

Being able to export palettes to ASE or other formats would be a tremendous help for me. I need to use my palettes in other software too...

Thanks, I've duplicated the problem and have attached a simpler test document. FYI you can edit your previous post and delete the attachment from it if you're concerned about others having access to your document.
Chapter.afpubBook.afbooktest.pdf
Notes for Serif: This test document has a single chapter with 2 pages and 1 image. It's not important to have the missing image, the preview is sufficient for a test. Just export the book with printers marks on and you'll see the problem on the right edge. But exporting the chapter won't trigger the issue. Also, if you delete the blank page 2 and then export the book the problem won't occur.

At any rate, it's a conceptual mistake to change the pixel size because of the resolution on a image targetted for screens. Want to tag the image with the resolution for applications that use physical sizes? Fine. But if I want to create a 1080*1080 PIXELS image, I want 1080 pixels, resolution aside.

No, it's not a matter of standards. The resolution of a raster image for the web is a meaningless value, as nobody uses physical sizes for screens.
You don't design a facebook cover to be 15 cm. wide. You use the pixels size defined by the platform.
When the units in a template are pixels, the normal expectation is to get an image of the same amount of pixels on export, not something else.
Apart from that, there are no standards for monitor resolution. It would be ridiculous.
Just think about this: If you have a Full HD 23" monitor, does it have the same resolution than Full HD 24, 26, 27 or 32 inch monitors?
What about Apple? The 14 and 16 inch macbooks pro have the same resolution with different sizes (254 ppi) but the 13 inch macbook with retina has 277 ppi.

Back in the mesolithic era 72 Pixels Per Inch was the Macintosh monitor resolution and 96 Pixels Per Inch was the PC monitor resolution. Monitor technology improved and Apple decided to double its screen resolution as did the Windows system.
This is the problem with Standards, everyone has at least one. We just have to live with it.

It is a design decision made by Serif / Affinity as product owner. 

to proof this with exactly all possible 8 bit colours:
 
image 1: all 16,7 million colours:

Image 2 pre-multiplied values with 1% leads to posterization with 3 steps (after restoring alpha to 100%):

Image 3 whereas alpha of 1% makes colors almost invisible - but the scope panel shows all is still present:

Image 4: adjusting the alpha channel to 100% gets back all colours without loss or posterisation:

all8bitcolors premultiply alpha.afphoto

@Guillermo Espertino: By now, you should be doing your own experiments to ascertain or discredit my (and others) claim that Affinity is not storing premultiplied RGB values in pixels and is instead only setting RGB to zero where alpha is zero while storing straight RGB values when alpha is any other value.
If you are struggling to do so, I can try to help.
 
 

All can be done, mostly non-destructively, or an alternative approach is possible.
the principle is to decomposition an RGBA layer into RGB (alpha filled) and greyscale layer, or even further into 4 greyscale layers.
I assume that you don’t want to use alpha in any classical way as alpha channel, but always as extra channel (while editing in Photo).
This can be done easily with channels adjustment. to get a regular RGB rendering, use blend mode „add“, and channels panel to color the separate layers.
so basically layer structure:
group alpha. Blend mode normal. Must be switched visible / invisible when you want to see it. group red. Blend mode add. Channel mixer with R=100, G=0, B=0 group green. Blend mode add. Channel mixer 0 / 100 / 0 group blue. Blend mode normal (bottom layer). Channel mixer 0 / 0 / 100. you can then edit all pixel layers including copy & paste. 

all you need is 2 macros:
one to crate this structure after opening a tga file one to create a mask layer from alpha group before exporting.

We have this logged thanks for the reports

This one is easy to reproduce:
On a new document, create 2 or more text objects, switch to the select tool and shift+click on all the text elements to select them. With the text elements already selected, shift+click on the canvas.
The application will switch to the text edit tool and freeze.
When the file is as simple as the example above, the application is operational again after several seconds, but with complex files it stays frozen (or at least the time it takes to become operational again is longer than I was willing to wait)
At any rate, it doesn't seem to be the right behavior of the select tool to switch to text edit after shift+clicking on the canvas (which seems to be the behavior when there's only one text object selected before shift+clicking on the canvas).