Medical Officer Bones

Please 'like' this post to add your vote for .BMP support in Affinity -
 
Yes! I would love Affinity to add support for the .BMP format

In the meantime Krita adds Live Mesh Warp to its already excellent complement of live transformation tools (including perspective, warp, liquid, and cage transformations). The implementation is really very good. Perhaps the Affinity devs could have a look at its code for inspiration?
 

OpenToonz/Tahoma2d is highly effective and powerful 2d animation software. It is comparable to ToonBoom Advanced and in some regards ToonBoom Harmony. The built-in compositor is as strong as Harmony.
Tahoma2d is a version of OpenToonz with a simpler default GUI setup. Either one is free and open source. It is used in the Japanese animation industry, and even Clip Studio Paint EX includes a direct OpenToonz export option (Clip Studio is not meant for full animation production, while OpenToonz is a full animation studio).
As for Adobe Animate: I would avoid it. Flash used to be great, but Adobe's Animate development team has their priorities upside-down, if you ask me. The last production usable and ready version is still Flash CS6, while the later Animate version introduced bug after bug after performance regressions, and more bugs. The bone tools are useless. Every time a new animation feature is introduced, somehow the dev team botched it, and delivered only half-working tools.
That said, an old copy of Flash CS6 plus Flanimate (free character animation plugin for Flash/Animate) is a really good combo. Animate's current state is a crying shame, though.
Avoid Toonboom Essentials. ToonBoom Advanced and Harmony are the way to go if you decide to go with ToonBoom. Essentials is way too limited in my experience. Besides, OpenToonz wipes the floor with Essentials, and even measures up with Harmony in many regards - for free!
Also have a look at Krita, which has nice bitmap-based frame-by-frame animation.
It also depends on the type of 2d animation that you are looking for: traditional hand-drawn frame-by-frame? Puppet-based cut-out characters? That makes a world of a difference. Cut-out 2d character animation can be done brilliantly well in not-so obvious software such as Blender and After Effects with the free DUIK plugin, or the dedicated Moho Pro animation app.
And do not underestimate Character Animator 4 from Reallusion. It is getting better and better for this type of animation too.
To answer your question better, let us know what specific type of animation you are looking for.
 

A 1-bit image mode is not supported in Affinity Photo or Designer - or Publisher for that matter. The developers have stated that 1-bit support will never be implemented in Affinity:
There have been quite a few threads created about the lack of 1bit mode support in Affinity. Iffy work-arounds abound such as the threshold filter suggestion above, or adjusting the layer blend. None of these are great, unfortunately.
As always, if this is a requirement in your work, I would suggest PhotoLine, which not only supports a proper 1bit image mode like Photoshop, but goes beyond Photoshop in that it allows for layers while working on 1bit images.
It is also possible to export your vector line art/inks from Designer to PhotoLine and convert these to high resolution 1200ppi 1bit images. PhotoLine also allows for proper 1bit high resolution PDF export and can be used to combine cmyk/rgb artwork with high resolution 1bit imagery for this particular task too.

A 1-bit image mode is not supported in Affinity Photo or Designer - or Publisher for that matter. The developers have stated that 1-bit support will never be implemented in Affinity:
There have been quite a few threads created about the lack of 1bit mode support in Affinity. Iffy work-arounds abound such as the threshold filter suggestion above, or adjusting the layer blend. None of these are great, unfortunately.
As always, if this is a requirement in your work, I would suggest PhotoLine, which not only supports a proper 1bit image mode like Photoshop, but goes beyond Photoshop in that it allows for layers while working on 1bit images.
It is also possible to export your vector line art/inks from Designer to PhotoLine and convert these to high resolution 1200ppi 1bit images. PhotoLine also allows for proper 1bit high resolution PDF export and can be used to combine cmyk/rgb artwork with high resolution 1bit imagery for this particular task too.

A 1-bit image mode is not supported in Affinity Photo or Designer - or Publisher for that matter. The developers have stated that 1-bit support will never be implemented in Affinity:
There have been quite a few threads created about the lack of 1bit mode support in Affinity. Iffy work-arounds abound such as the threshold filter suggestion above, or adjusting the layer blend. None of these are great, unfortunately.
As always, if this is a requirement in your work, I would suggest PhotoLine, which not only supports a proper 1bit image mode like Photoshop, but goes beyond Photoshop in that it allows for layers while working on 1bit images.
It is also possible to export your vector line art/inks from Designer to PhotoLine and convert these to high resolution 1200ppi 1bit images. PhotoLine also allows for proper 1bit high resolution PDF export and can be used to combine cmyk/rgb artwork with high resolution 1bit imagery for this particular task too.

The layer stack UX design is indeed problematic, and it has less to do with the choice of a checkbox as an indicator for layer visibility, and more with the positioning of the checkbox to the far right of each layer row.
Placing the checkbox near the right causes a number of issues:
users tend to focus on the thumbnail and/or layer name to identify the layer they would want to select or work with. Because the visibility checkbox is located to the far right, it is impossible to tell in one glance whether one or more layers are visible: first the user checks the thumbnail or layer name to identify the layer, then the user's eyes must follow the layer row to the right to check if that layer is visible or not.
Our eyes can only focus on a very small area and see details. In this particular case it is biologically impossible to identify the contents of a layer via the thumbnail AND identify whether that layer is visible or not.
This is not an issue in other design software, because the visibility icon/indicator is always placed directly left to the thumbnail. Vice versa, it is also problematic when the user needs to identify which layer contents belongs to a hidden layer. First the eye must identify the empty tiny checkbox, then follow the layer row to the left.
This action is problematic not only because of the aforementioned issue, but also breaks a common rule that Western languages are written from left to right: to move from right to left with our eyes to identify information breaks that basic rule and causes cognitive friction. The above issue is exacerbated due to the tiny checkbox: the on/off state is not clear enough. It takes true cognitive effort to visually identify which layers are visible and which are hidden when a number are hidden and others are visible. Our brain is forced to jump right to left and left to right in the layer stack for each layer, and up and down, double-checking along the way - rather than a simple downward traveling eye movement, capturing both the content and the visibility state simultaneously. An additional issue is quickly identified when layers are locked and layer effects are assigned: those icons are also placed to the right of each layer stack row. There are multiple issues with this: for one, the meaning of the checkbox becomes ambiguous: is the layer FX active or inactive? Or the lock?
More problematic however is the cognitive noise that occurs: our brain is forced to differentiate between these various icons near the right, increasing cognitive friction.
One more issue is that the layer visibility checkbox is placed to the far right and the lock and fx icons to the left of that checkbox, creating an additional visual obstruction for the eye to travel to the left over the layer row to check which layer contents it belongs to. It all adds up to a rather high cognitive effort on the part of the user. From a function perspective the layer visibility and layer properties (lock, fx, blending, opacity, etc.) are distinct and separate. Placing both the layer visibility indicator in the same area as the layer properties only serves to create more cognitive friction and noise. The two should be kept separated. When layers are selected the checkbox colour is kept: a light gray. But the selection colour is a light background blue. In this context it becomes quite hard to visually differentiate between layers that are selected and identifying which are selected and which are not. Yet another hurdle to what should be a simple cognitive task. Placing the visibility indicator to the left introduces a visual cue that organizes the layers better when multiple embedded groups are present in the layer stack. It is well known that readers have trouble understanding a paragraph of text that is set to ragged right aligned (left to right languages): it vastly reduces readability.
It could be argued that without that stabilizing visibility icon column the users' eyes are forced to follow the indented groups - further reducing visible understanding of the layer stack. placing the checkboxes to the far right does not seem to be consistent seeing that checkboxes in the Effects panel are placed to the left - which is more readable, of course. And which then brings to the fore: for what rational reason did the developers decide that placing these checkboxes to the far right would be a good idea? Because they obviously felt that it is more natural to place these to the left of the effects entries. when the user widens the layer panel horizontally, placing the tiny checkboxes to the right begins to make even less sense. Fitt's law anyone? Why make life so hard for your users? Which brings up the last point: should checkboxes have been used in the first place to indicate layer visibility? A checkbox basic meaning is "(not) active", rather than "(in)visible". An argument could be made against the use of a checkbox to indicate visibility, again from the standpoint of consistency: the aforementioned Effects panel seems to use checkboxes within the context of "an effect is either active or not". The meaning of a checkbox to indicate layer visibility seems somewhat ambiguous then. In particular seeing that in most design software with a layer stack an eye icon is used, it seems preferable to yield to common sense and accepted UI practices and accept the prevalent conceptual model, i.e. the eye icon. All of which means this:

It is quite problematic to the user to figure out which layer is visible, and which is not. Even harder to understand which layer contents belongs to which visibility indicator. Our eyes are forced to jump all over the place.
Time someone other than yourself and ask them to identify which layers are visible and which are not.
Simply moving the checkboxes to the left and inverting the colour for selected layers resolves many of the above listed issues:

Now perform the same test with a bunch of users. Time them again.
I expect that the result will be thatit is FAR easier to complete this simple test with the second version. In my opinion the Affinity devs have never properly tested the user experience, and merely went by gut decisions, or whatever.
There exist a number of additional usability and functionality issues with Affinity Photo's layer stack;
customized blend options assigned to a layer are not indicated by a visual cue in the layer stack it is not possible to drag over the visibility indicators (check boxes) to hide or show the content of layer in one motion opacity value is not indicated only three settings for thumbnail size no option to alt-click visibility indicator to hide or show selected layer only (it is really different behaviour compared to the Solo mode) layer colour tagging: similar issues related to the fact that the visibility indicator is positioned to the far right. Colour tagging again is more useful and easier to identify when pushed closer to the actual content thumbnail. Moving the checkboxes to the left is "low hanging fruit". It simply improves usability and UX.

@CrashX
As you are new here you may not know that we do not allow or encourage this sort of posting. Specifically many many people are sensitive about this subject and almost nobody has not been personally touched by the events of the last 2 years, however the Serif Affinity forums are not the place to discuss any of that. Your post has been flagged by a number of users as inappropriate and I agree.
I have left it rather than moderated it as I appreciate you are being light-hearted about the word "masks", which are relevant to the thread, but in my opinion is in poor taste. Do not post this type of content in the future, and stick to posting about the use of Serif Affinity software. 
To other readers, please do not respond to anything other than the CanIUse bits, or I will have to hide all the posts including the one above.

In the meantime Krita adds Live Mesh Warp to its already excellent complement of live transformation tools (including perspective, warp, liquid, and cage transformations). The implementation is really very good. Perhaps the Affinity devs could have a look at its code for inspiration?
 

A properly conducted usability test should provide useful insights here.
From a functional perspective, speaking for myself and from observations of students while working in Photoshop, hiding and showing layers is an action performed many times more than locking a layer or opening the layer effects via that icon.
I stand by my hypothesis that moving the visibility function to the far left will allow a user a more convenient and efficient workflow. At the very least Affinity is (as far as I am aware) the only design app that positions the layer visibility function to the far right, which does seem to go against most designers' conceptual model that they created based on prior experiences with design software.
Notice that Capture One (example posted earlier in this thread) also sticks to this convention.
In UX design it is considered bad practice to break accepted conventions unless that new approach affords a clear advantage over the older method. In this particular case I struggle to see such benefits, and it is rather obvious what the disadvantages are.
From personal anecdotal experience, when I work in Affinity Photo I notice that I am slowed down by that right aligned checkbox. As for the exact reasons? Well, that is why a simple usability test would bring some clarification in this matter 🙂

The layer stack UX design is indeed problematic, and it has less to do with the choice of a checkbox as an indicator for layer visibility, and more with the positioning of the checkbox to the far right of each layer row.
Placing the checkbox near the right causes a number of issues:
users tend to focus on the thumbnail and/or layer name to identify the layer they would want to select or work with. Because the visibility checkbox is located to the far right, it is impossible to tell in one glance whether one or more layers are visible: first the user checks the thumbnail or layer name to identify the layer, then the user's eyes must follow the layer row to the right to check if that layer is visible or not.
Our eyes can only focus on a very small area and see details. In this particular case it is biologically impossible to identify the contents of a layer via the thumbnail AND identify whether that layer is visible or not.
This is not an issue in other design software, because the visibility icon/indicator is always placed directly left to the thumbnail. Vice versa, it is also problematic when the user needs to identify which layer contents belongs to a hidden layer. First the eye must identify the empty tiny checkbox, then follow the layer row to the left.
This action is problematic not only because of the aforementioned issue, but also breaks a common rule that Western languages are written from left to right: to move from right to left with our eyes to identify information breaks that basic rule and causes cognitive friction. The above issue is exacerbated due to the tiny checkbox: the on/off state is not clear enough. It takes true cognitive effort to visually identify which layers are visible and which are hidden when a number are hidden and others are visible. Our brain is forced to jump right to left and left to right in the layer stack for each layer, and up and down, double-checking along the way - rather than a simple downward traveling eye movement, capturing both the content and the visibility state simultaneously. An additional issue is quickly identified when layers are locked and layer effects are assigned: those icons are also placed to the right of each layer stack row. There are multiple issues with this: for one, the meaning of the checkbox becomes ambiguous: is the layer FX active or inactive? Or the lock?
More problematic however is the cognitive noise that occurs: our brain is forced to differentiate between these various icons near the right, increasing cognitive friction.
One more issue is that the layer visibility checkbox is placed to the far right and the lock and fx icons to the left of that checkbox, creating an additional visual obstruction for the eye to travel to the left over the layer row to check which layer contents it belongs to. It all adds up to a rather high cognitive effort on the part of the user. From a function perspective the layer visibility and layer properties (lock, fx, blending, opacity, etc.) are distinct and separate. Placing both the layer visibility indicator in the same area as the layer properties only serves to create more cognitive friction and noise. The two should be kept separated. When layers are selected the checkbox colour is kept: a light gray. But the selection colour is a light background blue. In this context it becomes quite hard to visually differentiate between layers that are selected and identifying which are selected and which are not. Yet another hurdle to what should be a simple cognitive task. Placing the visibility indicator to the left introduces a visual cue that organizes the layers better when multiple embedded groups are present in the layer stack. It is well known that readers have trouble understanding a paragraph of text that is set to ragged right aligned (left to right languages): it vastly reduces readability.
It could be argued that without that stabilizing visibility icon column the users' eyes are forced to follow the indented groups - further reducing visible understanding of the layer stack. placing the checkboxes to the far right does not seem to be consistent seeing that checkboxes in the Effects panel are placed to the left - which is more readable, of course. And which then brings to the fore: for what rational reason did the developers decide that placing these checkboxes to the far right would be a good idea? Because they obviously felt that it is more natural to place these to the left of the effects entries. when the user widens the layer panel horizontally, placing the tiny checkboxes to the right begins to make even less sense. Fitt's law anyone? Why make life so hard for your users? Which brings up the last point: should checkboxes have been used in the first place to indicate layer visibility? A checkbox basic meaning is "(not) active", rather than "(in)visible". An argument could be made against the use of a checkbox to indicate visibility, again from the standpoint of consistency: the aforementioned Effects panel seems to use checkboxes within the context of "an effect is either active or not". The meaning of a checkbox to indicate layer visibility seems somewhat ambiguous then. In particular seeing that in most design software with a layer stack an eye icon is used, it seems preferable to yield to common sense and accepted UI practices and accept the prevalent conceptual model, i.e. the eye icon. All of which means this:

It is quite problematic to the user to figure out which layer is visible, and which is not. Even harder to understand which layer contents belongs to which visibility indicator. Our eyes are forced to jump all over the place.
Time someone other than yourself and ask them to identify which layers are visible and which are not.
Simply moving the checkboxes to the left and inverting the colour for selected layers resolves many of the above listed issues:

Now perform the same test with a bunch of users. Time them again.
I expect that the result will be thatit is FAR easier to complete this simple test with the second version. In my opinion the Affinity devs have never properly tested the user experience, and merely went by gut decisions, or whatever.
There exist a number of additional usability and functionality issues with Affinity Photo's layer stack;
customized blend options assigned to a layer are not indicated by a visual cue in the layer stack it is not possible to drag over the visibility indicators (check boxes) to hide or show the content of layer in one motion opacity value is not indicated only three settings for thumbnail size no option to alt-click visibility indicator to hide or show selected layer only (it is really different behaviour compared to the Solo mode) layer colour tagging: similar issues related to the fact that the visibility indicator is positioned to the far right. Colour tagging again is more useful and easier to identify when pushed closer to the actual content thumbnail. Moving the checkboxes to the left is "low hanging fruit". It simply improves usability and UX.

If you feel your moderated post has lost it's meaning you, like all members, have the facility to hide it.
To all readers: Anyone thinking of posting contributions who is bothered about (or in order to get) "reactions" from others, should be posting on twitter, not this forum.

The layer stack UX design is indeed problematic, and it has less to do with the choice of a checkbox as an indicator for layer visibility, and more with the positioning of the checkbox to the far right of each layer row.
Placing the checkbox near the right causes a number of issues:
users tend to focus on the thumbnail and/or layer name to identify the layer they would want to select or work with. Because the visibility checkbox is located to the far right, it is impossible to tell in one glance whether one or more layers are visible: first the user checks the thumbnail or layer name to identify the layer, then the user's eyes must follow the layer row to the right to check if that layer is visible or not.
Our eyes can only focus on a very small area and see details. In this particular case it is biologically impossible to identify the contents of a layer via the thumbnail AND identify whether that layer is visible or not.
This is not an issue in other design software, because the visibility icon/indicator is always placed directly left to the thumbnail. Vice versa, it is also problematic when the user needs to identify which layer contents belongs to a hidden layer. First the eye must identify the empty tiny checkbox, then follow the layer row to the left.
This action is problematic not only because of the aforementioned issue, but also breaks a common rule that Western languages are written from left to right: to move from right to left with our eyes to identify information breaks that basic rule and causes cognitive friction. The above issue is exacerbated due to the tiny checkbox: the on/off state is not clear enough. It takes true cognitive effort to visually identify which layers are visible and which are hidden when a number are hidden and others are visible. Our brain is forced to jump right to left and left to right in the layer stack for each layer, and up and down, double-checking along the way - rather than a simple downward traveling eye movement, capturing both the content and the visibility state simultaneously. An additional issue is quickly identified when layers are locked and layer effects are assigned: those icons are also placed to the right of each layer stack row. There are multiple issues with this: for one, the meaning of the checkbox becomes ambiguous: is the layer FX active or inactive? Or the lock?
More problematic however is the cognitive noise that occurs: our brain is forced to differentiate between these various icons near the right, increasing cognitive friction.
One more issue is that the layer visibility checkbox is placed to the far right and the lock and fx icons to the left of that checkbox, creating an additional visual obstruction for the eye to travel to the left over the layer row to check which layer contents it belongs to. It all adds up to a rather high cognitive effort on the part of the user. From a function perspective the layer visibility and layer properties (lock, fx, blending, opacity, etc.) are distinct and separate. Placing both the layer visibility indicator in the same area as the layer properties only serves to create more cognitive friction and noise. The two should be kept separated. When layers are selected the checkbox colour is kept: a light gray. But the selection colour is a light background blue. In this context it becomes quite hard to visually differentiate between layers that are selected and identifying which are selected and which are not. Yet another hurdle to what should be a simple cognitive task. Placing the visibility indicator to the left introduces a visual cue that organizes the layers better when multiple embedded groups are present in the layer stack. It is well known that readers have trouble understanding a paragraph of text that is set to ragged right aligned (left to right languages): it vastly reduces readability.
It could be argued that without that stabilizing visibility icon column the users' eyes are forced to follow the indented groups - further reducing visible understanding of the layer stack. placing the checkboxes to the far right does not seem to be consistent seeing that checkboxes in the Effects panel are placed to the left - which is more readable, of course. And which then brings to the fore: for what rational reason did the developers decide that placing these checkboxes to the far right would be a good idea? Because they obviously felt that it is more natural to place these to the left of the effects entries. when the user widens the layer panel horizontally, placing the tiny checkboxes to the right begins to make even less sense. Fitt's law anyone? Why make life so hard for your users? Which brings up the last point: should checkboxes have been used in the first place to indicate layer visibility? A checkbox basic meaning is "(not) active", rather than "(in)visible". An argument could be made against the use of a checkbox to indicate visibility, again from the standpoint of consistency: the aforementioned Effects panel seems to use checkboxes within the context of "an effect is either active or not". The meaning of a checkbox to indicate layer visibility seems somewhat ambiguous then. In particular seeing that in most design software with a layer stack an eye icon is used, it seems preferable to yield to common sense and accepted UI practices and accept the prevalent conceptual model, i.e. the eye icon. All of which means this:

It is quite problematic to the user to figure out which layer is visible, and which is not. Even harder to understand which layer contents belongs to which visibility indicator. Our eyes are forced to jump all over the place.
Time someone other than yourself and ask them to identify which layers are visible and which are not.
Simply moving the checkboxes to the left and inverting the colour for selected layers resolves many of the above listed issues:

Now perform the same test with a bunch of users. Time them again.
I expect that the result will be thatit is FAR easier to complete this simple test with the second version. In my opinion the Affinity devs have never properly tested the user experience, and merely went by gut decisions, or whatever.
There exist a number of additional usability and functionality issues with Affinity Photo's layer stack;
customized blend options assigned to a layer are not indicated by a visual cue in the layer stack it is not possible to drag over the visibility indicators (check boxes) to hide or show the content of layer in one motion opacity value is not indicated only three settings for thumbnail size no option to alt-click visibility indicator to hide or show selected layer only (it is really different behaviour compared to the Solo mode) layer colour tagging: similar issues related to the fact that the visibility indicator is positioned to the far right. Colour tagging again is more useful and easier to identify when pushed closer to the actual content thumbnail. Moving the checkboxes to the left is "low hanging fruit". It simply improves usability and UX.

Love WebP and PNG for game development. I use WebP mainly for lossy images which also require alpha transparency to vastly reduce the file size footprint.
And in my opinion not supporting WebP is a bit silly. High traffic websites are converting more and more to the use of WebP instead of jpg, for the simple reason of reducing traffic bandwidth. WebP is out there, it is used, and it ought to be supported by an image editor.

The latest version of Photoshop now supports WebP export.
I would like Affinity Photo and Affinity Designer to respond as soon as possible.
WebP is supported on all Evergreen browsers, including Safari.

I remember Carrara back in the 90s - even at that time it was a bit of an outlier. It had potential, but it just couldn't compete very well.
It is extremely outdated for 3d software. Serif would have to rewrite the core of Carrara altogether to allow it to compete and that is never going to be lucrative: Blender's usability has jumped ahead by leagues in the latest versions, and is now quite easy to get into for a beginner. And obviously Blender is light years ahead of Carrara in terms of functionality.
Carrara belongs in the archives of old defunct 3d software, unfortunately.
I am amazed that Daz is still selling it for $285! But it seems they actually merely selling their 3d assets and Carrara happens to be part of that deal. It's not even compatible anymore with Mac Os. Serif would be sinking cash in a very VERY deep money pit.
It would be preferable for Serif to acquire LightWave instead (but that's going to have a really tough time competing with Blender as well...).

Yes, this is one of those cases where anti-aliasing wreaks havoc with the result, and Affinity Photo does not have an option to automatically render all objects to the pixel grid automatically. Yes, there's Force Pixel Alignment, but a 1 pixel line will have to be placed exactly at 0.5 - which is a bit ridiculous to ask of the user.
Other design apps solve this with a simple document wide or even layer-specific pixel snapping that changes the rendered result on the fly. Not so in Photo, unfortunately. One of the many reasons why I think Affinity Photo is rather unsuitable for precise pixel work and pixel art. Another reason being the lack of a simple document-wide option to turn off anti-aliasing. And the Coverage Map work-around is a half-baked one.
[ On a side note, I found that it is often the simple basic things which require all sorts of convoluted hacks and work-arounds in Photo. That is why I mainly use it for HDR merging, stacking, and sometimes panoramas, and then export the result to continue work in other image editors. Of course, this is my personal experience, and a bit of a shame. Basic workflow foundations in Photo are quite shaky. ]

In the meantime Krita adds Live Mesh Warp to its already excellent complement of live transformation tools (including perspective, warp, liquid, and cage transformations). The implementation is really very good. Perhaps the Affinity devs could have a look at its code for inspiration?
 

Converting 1200ppi 1bit images to vector is just not a feasible workflow in stressful production scenarios. Aside from the problem that for very detailed line work it produces very heavy and difficult to process vector files, for more detailed inked art work it just can't resolve the details sufficiently.
Take comic printing as an example: it is entirely impractical to convert hundreds of pages of line art... And having to check each page for problems.
And, as @MikeW pointed out earlier, as long as imported high resolution 1bit artwork isn't even retained in the PDF output, the whole point is moot.
The preferred solution is for [1] Affinity Photo to natively support 1bit images at any resolution, and allow these to be edited that way. [2] Publisher and Designer should be able to process them, and output to a PDF. Colorizing should be possible in Designer and Publisher.
The developers have already stated that [1] will never be implemented. (I suspect this might be related to them wanting to avoid a complete re-haul of the core processing engine.)  Instead, they have seemingly decided to output 1bit images only. Which leaves [2] - and this must be added before Publisher can be fully integrated in many regular prepress conditions and workflows.
[2] is absolutely essential for prepress work. Simple as that. No workarounds, no excuses. That said, I am pretty certain the devs are aware of this, and will implement support for this at some point. It should be given top priority after the latest 1.9 release.
I agree with @loukash: be software agnostic. If Affinity or other software will not provide what is required to pull off a job without turning upside down and twisting left and right, then switch to other software that can. I still use InDesign for FXL ebook work, because Affinity Publisher lacks this option.
Similarly, any 1bit high resolution artwork editing I do in PhotoLine, which is the only image editor that I know of that allows for native 1bit editing AND use layers! Nothing else on the market, including Adobe Photoshop, handles 1bit images that well. Being able to edit layered 1bit images is pretty darn awesome when an important part of my workflow revolves around manipulating 1bit high resolution imagery. 😎
Same for indexed pixel art jobs: Affinity Photo, Photoshop, PhotoLine, and just about any other general image editor out there cannot handle 8-bit  (or less) indexed fixed colour palettes with full layer support. Either it is not supported at all (Photo and PhotoLine) or the editing is severely hampered (Photoshop only allows for a single layer in indexed colour mode).
Which means I use alternative dedicated pixel art software (ProMotion NG, but there are other options).
Anyway, what I am trying to say: the job at hand should, in the end, dictate what tool fits best to handle that job. Endless work-arounds may be helpful in the odd unexpected bind, but are useless and time-consuming if used in a common day-to-day pipeline and workflow. Then it's time to find an alternative solution to fill the gap.

@LDB Completely agree. I would actually argue that Photo is entirely unsuitable for use in a professional comic colouring and publishing workflow. The gradient tool is utterly unusable for colouring work, but there are other problems, such as the lack of an overfill option to speed up flats and holds.
Since you seem to be in a discovery phase to replace Photoshop for your comic colouring work: have you had a look at Krita and/or ClipStudio? Both have a dedicated set of tools to simplify comic colouring work. Krita in particular offers a very efficient Colorize Mask workflow to create flats quickly and efficiently - with automatic gap close hinting and cleanup. And automatic colour swatch tracking of the colours used for flats! No more manual selections for everything: add a stroke to indicate the flat, and done. It may take Krita some time to calculate the flats, but still way faster compared to manually creating selections and filling those.
https://docs.krita.org/en/reference_manual/tools/colorize_mask.html?highlight=colorize
 

@LDB Completely agree. I would actually argue that Photo is entirely unsuitable for use in a professional comic colouring and publishing workflow. The gradient tool is utterly unusable for colouring work, but there are other problems, such as the lack of an overfill option to speed up flats and holds.
Since you seem to be in a discovery phase to replace Photoshop for your comic colouring work: have you had a look at Krita and/or ClipStudio? Both have a dedicated set of tools to simplify comic colouring work. Krita in particular offers a very efficient Colorize Mask workflow to create flats quickly and efficiently - with automatic gap close hinting and cleanup. And automatic colour swatch tracking of the colours used for flats! No more manual selections for everything: add a stroke to indicate the flat, and done. It may take Krita some time to calculate the flats, but still way faster compared to manually creating selections and filling those.
https://docs.krita.org/en/reference_manual/tools/colorize_mask.html?highlight=colorize
 

Oh dear. Evidently this answers my question about gradients.
This is a very, very badly needed tool. As a comic book artist who primarily works with flats, a dead-simple, one-click, 2 second destructive raster gradient tool that works like a brush rather than a vector object is a MUST. It is absolutely essential to my workflow, I will use this tool dozens of times during a 30-minute coloring illustration job, maybe a hundred times on a full comic book page, and if I have to struggle with the tool for even 10 seconds each time I need to use it, this easily doubles the amount of work and is an utter deal-breaker. Saving my presets as a style is a non-answer, I need to be able to change colors, angles, and transparency on the fly.
I cannot purchase this program unless and until this tool is added. Affinity is useless to me as a professional without it.

Just realized a simple vector rectangle overlaid and set to Lighten blend mode will do the trick non-destructively as well.