Medical Officer Bones

True, it looks clunky, but at least it is functional and is very understandable. Affinity Photo's layer stack doesn't really look much better, though. And is not as readable. Compare the layer stack below, and I think that's pretty clunky looking as well as completely unreadable. I have no idea what is going on in that list. I certainly hope v1.7 will introduce a thumbnail size setting.
But you are correct that adding all layer parameters in the layer stack creates its own set of issues. So what do we go for? Form over function, or function over form? Or a good balance between the two? Myself I would prefer these things to be optional in a layer stack preference tab. It really depends on the complexity of the project.
Perhaps a bit more like Krita's layer stack (the newest beta release has a seamless thumbnail size slider) where the user is able to quickly hover over layers and an overlay is displayed (see the right screenshot)? It almost looks like a hybrid between Affinity Photo and PhotoLine.
Designing a good looking and easy to use/understand layer stack is quite a user experience design task. Perhaps a completely new and novel approach is required.

@hifred I believe Sparkle saves single project files, and the now defunct Adobe Muse shares that same approach. As you mentioned, Xara saves the pages as one file too.
The question you would have to ask yourself is whether this is a good approach or not. Html, CSS, Javascript: these are all open human readable files, and the entire point of the web is open technologies. When relying on a closed file format like Xara, Muse, or Sparkle you become entirely (or mostly) dependent on that software to manage the site, and all three write rather abysmal code that cannot be handed over to a programmer in good conscience: they would have to start all over, because it is entirely human unreadable.
I suppose it is fine when dealing with simple sites with a simple structure, one-pagers, or flashy portfolio sites. But if the design must be integrated with a content management system (CMS) and/or database driven content with a server back-end, or even be converted to a mobile app... Well, let's just close with this: it is a Very Bad Idea to rely on pure visual web page building tools that 1) are unable to work directly with (existing) html files, 2) rely on a proprietary file format, and 2) output code that is only machine readable and a mess.
Tools such as Muse, WebPlus, and Xara all work with a separate design layer which must be converted to web code. This is hard to maintain (by the developers), hard to keep the design layer updated with the latest web technologies (which often change on a yearly basis or more often), and that custom design layer cannot hope to emulate an actual web browser output, so the so-called WYSIWYG view is only an approximation of the real thing (can't test javascript right in the view, for example).
No wonder Adobe and Serif had to throw in the towel with Muse and WebPlus: the web goes too fast to keep up with such a proprietary tool with an abstracted design layer. It's unmaintainable in the long run. Muse had become an obese dragon of an application.
Not to mention the hardships related to designing and testing responsive layouts in these kind of tools. And I am not even mentioning the trouble and frustration related to one-file file corruption issues, and thereby losing the entire site. That is to say, a versioning/file backup feature should be either integrated and/or it should be compatible with the tools you use for web site creation. A single-file approach for web development is (sorry) just a really bad idea, and adds one more unnecessary layer between the output and yourself. That is not how web pages work. and it is a severely limiting workflow anyway.
These tools cannot be integrated well in a team environment at all. So, unless simple static web work is what you do, and you are not involved in a team (you're working on your own), and you don't mind running the risks of depending on a proprietary design app and file format, then one of these tools might fit the bill.
Anyway, long explanation to tell you that I think, that unless you are making very simple static sites, it is better to stay well away from such tools, and only choose tools that work directly with the html, css, js, less, sass, etc. files themselves. You should be able to open an existing web page or site in these tools, and be able to edit the code in a visual environment which is based on an actual web browser view.
And this workflow is compatible with a team, as well as a file versioning workflow (like Git(hub)). Pinegrow keeps an automatic local file history, and all changes are recorded.
For me that means Xara, Muse, Sparkle, online solution like WebFlow and the like, and WebPlus are always going to limit you in some way. Wappler is better, but doesn't allow for CSS frameworks outside the ones they support directly, and that leaves Pinegrow for me and my frontend development work. But it is possible to combine both Wappler and Pinegrow in your workflow, because in the end they both work directly with the actual web files. And in a good human readable way, so anyone with a bit of html and css skill will be able to open the code in a code editor and make changes. I can open a Wappler website directly in Pinegrow, and continue to edit it. Can't do that in Muse, Sparkle, WebPlus, Xara, etc.
In short, even if Pinegrow would met its demise in the future, those Pinegrow-built sites are fully editable with other open tools. Compare that to Muse or WebPlus users.
 
 

@hifred I believe Sparkle saves single project files, and the now defunct Adobe Muse shares that same approach. As you mentioned, Xara saves the pages as one file too.
The question you would have to ask yourself is whether this is a good approach or not. Html, CSS, Javascript: these are all open human readable files, and the entire point of the web is open technologies. When relying on a closed file format like Xara, Muse, or Sparkle you become entirely (or mostly) dependent on that software to manage the site, and all three write rather abysmal code that cannot be handed over to a programmer in good conscience: they would have to start all over, because it is entirely human unreadable.
I suppose it is fine when dealing with simple sites with a simple structure, one-pagers, or flashy portfolio sites. But if the design must be integrated with a content management system (CMS) and/or database driven content with a server back-end, or even be converted to a mobile app... Well, let's just close with this: it is a Very Bad Idea to rely on pure visual web page building tools that 1) are unable to work directly with (existing) html files, 2) rely on a proprietary file format, and 2) output code that is only machine readable and a mess.
Tools such as Muse, WebPlus, and Xara all work with a separate design layer which must be converted to web code. This is hard to maintain (by the developers), hard to keep the design layer updated with the latest web technologies (which often change on a yearly basis or more often), and that custom design layer cannot hope to emulate an actual web browser output, so the so-called WYSIWYG view is only an approximation of the real thing (can't test javascript right in the view, for example).
No wonder Adobe and Serif had to throw in the towel with Muse and WebPlus: the web goes too fast to keep up with such a proprietary tool with an abstracted design layer. It's unmaintainable in the long run. Muse had become an obese dragon of an application.
Not to mention the hardships related to designing and testing responsive layouts in these kind of tools. And I am not even mentioning the trouble and frustration related to one-file file corruption issues, and thereby losing the entire site. That is to say, a versioning/file backup feature should be either integrated and/or it should be compatible with the tools you use for web site creation. A single-file approach for web development is (sorry) just a really bad idea, and adds one more unnecessary layer between the output and yourself. That is not how web pages work. and it is a severely limiting workflow anyway.
These tools cannot be integrated well in a team environment at all. So, unless simple static web work is what you do, and you are not involved in a team (you're working on your own), and you don't mind running the risks of depending on a proprietary design app and file format, then one of these tools might fit the bill.
Anyway, long explanation to tell you that I think, that unless you are making very simple static sites, it is better to stay well away from such tools, and only choose tools that work directly with the html, css, js, less, sass, etc. files themselves. You should be able to open an existing web page or site in these tools, and be able to edit the code in a visual environment which is based on an actual web browser view.
And this workflow is compatible with a team, as well as a file versioning workflow (like Git(hub)). Pinegrow keeps an automatic local file history, and all changes are recorded.
For me that means Xara, Muse, Sparkle, online solution like WebFlow and the like, and WebPlus are always going to limit you in some way. Wappler is better, but doesn't allow for CSS frameworks outside the ones they support directly, and that leaves Pinegrow for me and my frontend development work. But it is possible to combine both Wappler and Pinegrow in your workflow, because in the end they both work directly with the actual web files. And in a good human readable way, so anyone with a bit of html and css skill will be able to open the code in a code editor and make changes. I can open a Wappler website directly in Pinegrow, and continue to edit it. Can't do that in Muse, Sparkle, WebPlus, Xara, etc.
In short, even if Pinegrow would met its demise in the future, those Pinegrow-built sites are fully editable with other open tools. Compare that to Muse or WebPlus users.
 
 

@hifred
Here is an example screenshot. One could argue that it looks a bit clunky and different, but aside from that, once you get used to the icons, it works really, really well. Everything that's going on that is important to know about is directly exposed: image blend modes are indicated, opacity percentages, the layer type, the adjustment layer type is indicated with an icon, curve adjustments are shown as a thumbnail (love this myself!), which layers are editable, select-able, and or locked, whether an advanced layer blend is applied (fourth layer small icon), which layers have transparency locked, which groups are drawn isolated (asterisk)... and of course layer effects (here indicated with an 'S').
Instead of having to click on each layer to inspect what is going on under the hood, here we just glance over the layer stack, and understand what is happening in this file. I find other image editors' layer panels to be very awkward and inefficient to work with compared - even the "industry standard" Photoshop layer panel (aside from the missing drag option).
For those who are wondering about the checkboxes: these serve as a visual indicator for multiple layers selected, but also as a way to use the mouse only to select multiple layers: something that would require a modifier shortcut key on most other image editors. It's quite handy when working with the Wacom tablet.
What is missing compared to Photoshop: it is not possible to drag-select layer visibility, unfortunately.  For the rest I prefer this layer panel over Photoshop and other image editors/painting tools. (on a side note: PhotoLine's painting tools are however not in the same league as Affinity Photo, let alone compared to the ones in Krita.)
What is also nice is that Corel users can adjust layer navigation options to use the cursor keys to navigate the layer panel. I like the configuration options related to the use of the layer panel as well. And the fact that the user can zoom in and out of thumbnails on the fly by holding down the ctrl and scroll wheel.

 

Most of those are related to the lack of database/server connectivity. Pinegrow does have a similar project manager as Wappler, although Wappler can use FTP to connect with your webhost folder.
I did try out Wappler, and the GUI is still very VERY behind compared to Pinegrow. For example, in Pinegrow the same page or different pages can be viewed for various devices simultaneously, side by side. The interface in Wappler is almost completely static, and panels cannot be moved around. The styling controls in Pinegrow are far more user friendly and better exposed for CSS than the ones in Wappler.
It is one thing to compare and cherry pick base features between applications, but an altogether different thing to actually experience how these are implemented, and how the overall workflow and GUI respect the user's preferences. Pinegrow is light years ahead of Wappler in terms of configuration. And supports a live connection with Atom and MS Visual Studio Code for code editing. And many more things related to front-end development which are unavailable in Wappler.
The main difference between the two is that Wappler can connect to live data in a database, which Pinegrow cannot. However, Pinegrow does support direct WordPress theming in the WP edition, which allows for quick WP theming, and via WordPress data does become live. Wappler does not support WordPress. Via WordPress a tremendous library of free and commercial plugins for just about any requirement opens up. While Wappler allows the user to create their own custom database functionality, in comparison the WP ecosystem delivers just about any database functionality you would ever need. And WordPress delivers a user-friendly back-end interface out of the box, while in Wappler you would have to develop it yourself (and you'd never be able to match it on your own).
Pinegrow's WP edition supports custom data bindings through the Advanced Custom Fields WordPress plugin (which then pretty much delivers what Wappler delivers). But getting this far with the WP edition requires a good understanding of how WP theming works. Wappler is much easier to understand and learn in this respect.
So it really depends on what your needs are. Pinegrow is a much more mature application, in particular for front end development and its interface and workflow is quite flexible and adaptable to users' preferences, and Wappler offers custom database connectivity, but as an application still needs a lot of growing up in my opinion.
In short, don't rely on those cherry-picked feature comparison lists from either side. Test for yourself, and allow for a week of testing for each product.

Most of those are related to the lack of database/server connectivity. Pinegrow does have a similar project manager as Wappler, although Wappler can use FTP to connect with your webhost folder.
I did try out Wappler, and the GUI is still very VERY behind compared to Pinegrow. For example, in Pinegrow the same page or different pages can be viewed for various devices simultaneously, side by side. The interface in Wappler is almost completely static, and panels cannot be moved around. The styling controls in Pinegrow are far more user friendly and better exposed for CSS than the ones in Wappler.
It is one thing to compare and cherry pick base features between applications, but an altogether different thing to actually experience how these are implemented, and how the overall workflow and GUI respect the user's preferences. Pinegrow is light years ahead of Wappler in terms of configuration. And supports a live connection with Atom and MS Visual Studio Code for code editing. And many more things related to front-end development which are unavailable in Wappler.
The main difference between the two is that Wappler can connect to live data in a database, which Pinegrow cannot. However, Pinegrow does support direct WordPress theming in the WP edition, which allows for quick WP theming, and via WordPress data does become live. Wappler does not support WordPress. Via WordPress a tremendous library of free and commercial plugins for just about any requirement opens up. While Wappler allows the user to create their own custom database functionality, in comparison the WP ecosystem delivers just about any database functionality you would ever need. And WordPress delivers a user-friendly back-end interface out of the box, while in Wappler you would have to develop it yourself (and you'd never be able to match it on your own).
Pinegrow's WP edition supports custom data bindings through the Advanced Custom Fields WordPress plugin (which then pretty much delivers what Wappler delivers). But getting this far with the WP edition requires a good understanding of how WP theming works. Wappler is much easier to understand and learn in this respect.
So it really depends on what your needs are. Pinegrow is a much more mature application, in particular for front end development and its interface and workflow is quite flexible and adaptable to users' preferences, and Wappler offers custom database connectivity, but as an application still needs a lot of growing up in my opinion.
In short, don't rely on those cherry-picked feature comparison lists from either side. Test for yourself, and allow for a week of testing for each product.

You have several options open to you, with (1) being the closest to WebPlus in regards to workflow, to (6) being the least similar:
Xara Designer Pro or Xara Web Designer (Premium). These offer a way of working that is closest to Webplus: completely visual, and pretty much a regular Publisher type layout application, which converts directly to a working website. Responsive pages are also possible. Sparkle. Not as flexible as either WebPlus or Xara, but no code in sight. And generates quite acceptable code. Around $99 for the pro version. Mac only.
https://sparkleapp.com/ Wappler. Still completely visual, although works with blocks. Also supports full database-driven websites. Free version, up to 49 euros per month for the full version. Service based, no full license, unfortunately.
https://wappler.io/index Pinegrow. The next step "up" from a typical visual design tool which actually works directly with html and css code, and outputs human readable code that actually is quite clean. The workflow is different though. It is column and row based, and the html and css code is accessible and directly exposed to the user through its interface. Basic knowledge of html and css is preferred. $99 for the pro version, which is really needed for multi-page sites.
https://pinegrow.com/ WordPress. The upcoming v5 version will include the new Gutenberg editor, and introduce easier visual editing of content. Or download a visual editor plugin such as Elementor. Free for the most part. Learn to code html and css properly, in combination with a grid framework such as Bootstrap or Foundation. Free! Xara Designer Pro was up for grabs for $15 a while ago through a Humble Bundle, but that deal is sadly over. $99 for the Web Designer Premium version, or $299 for Xara Designer Pro.
Personally, I feel Pinegrow is THE best visual WYSIWYG web page editor on the market today, but it does require some html and css knowledge. If the prospect of coding puts you completely off, then try option (1), (2), or (3). All have free versions or a trial (Xara).
WordPress doesn't require coding either, but you do need either online hosting, or a local webserver to run it on.
PS many online visual website editors have vied for attention since the demise of Adobe Muse. All of these only work online in a browser and require a subscription/monthly rent. I would avoid these myself

It's perfectly fine to ask for the ability to have uncompressed TIFF files, but i have to disagree with that quoted statement.
LZW is not proprietary (though it was at one time patented) and support for LZW compression is part of the TIFF 6.0 standard.

The lack of a custom layer thumbnail size has been discussed to death before. It is only one of several GUI interaction design issues related to the Layer panel.
Here is what happens with longer layer labels:

As anyone can see, this is a less than desirable situation, and things will only get worse when a custom layer thumbnail size is introduced in the Affinity range. And I agree with your @hifred observation that a checkbox is the wrong indicator for layer visibility. 
There are a number of other design problems, and I again agree the entire panel should be scrapped, and rethought. For example, changing the blending range, changing the opacity, or coverage map: none of these are indicated in any way in the layer panel to show the user that a specific layer happens to have other settings applied to. Layers cannot be tagged with a colour either, nor is a search option provided to filter layers. And it is not possible to drag-select like in Photoshop.
But in this respect Photoshop is lacking as well. With both apps the user must select a layer first before it becomes clear which opacity and blend mode settings are applied. The only application that I know of that does include this information for each layer is PhotoLine, and that works very, very well. Looking at a layer comp in the layer panel immediately tells you how things work. I wish other image editors would allow for this, or at least include an option.
Anyway, the way the layer visibility controls are handled in Affinity reminds me of how a programmer would solve it. But it is only one of a whole list of layer panel issues and limitations. I do hope the developers are working to solve and improve these, but I was hoping to see some much-need improvements in the beta of Affinity Publisher, and noticed how little has changed.  Publisher is presumably the v1.7 version of the Affinity range? If so, we may be disappointed when V1.7 is released.
 

The lack of a custom layer thumbnail size has been discussed to death before. It is only one of several GUI interaction design issues related to the Layer panel.
Here is what happens with longer layer labels:

As anyone can see, this is a less than desirable situation, and things will only get worse when a custom layer thumbnail size is introduced in the Affinity range. And I agree with your @hifred observation that a checkbox is the wrong indicator for layer visibility. 
There are a number of other design problems, and I again agree the entire panel should be scrapped, and rethought. For example, changing the blending range, changing the opacity, or coverage map: none of these are indicated in any way in the layer panel to show the user that a specific layer happens to have other settings applied to. Layers cannot be tagged with a colour either, nor is a search option provided to filter layers. And it is not possible to drag-select like in Photoshop.
But in this respect Photoshop is lacking as well. With both apps the user must select a layer first before it becomes clear which opacity and blend mode settings are applied. The only application that I know of that does include this information for each layer is PhotoLine, and that works very, very well. Looking at a layer comp in the layer panel immediately tells you how things work. I wish other image editors would allow for this, or at least include an option.
Anyway, the way the layer visibility controls are handled in Affinity reminds me of how a programmer would solve it. But it is only one of a whole list of layer panel issues and limitations. I do hope the developers are working to solve and improve these, but I was hoping to see some much-need improvements in the beta of Affinity Publisher, and noticed how little has changed.  Publisher is presumably the v1.7 version of the Affinity range? If so, we may be disappointed when V1.7 is released.
 

Having the layer visibility control on the far right is a usability problem, and plain bad user experience design. I agree with the OP: it's really frustrating to work with.
The positioning of the checkmark breaks a fundamental interaction design law (Fitts's law) because the user identifies a layer by its thumbnail and/or label, and is then forced to follow the row to the right with their eyes to finally uncheck the visibility. But since the distance between layer identifier and the checkbox is relatively large, the eye will often re-check whether the thumbnail is the correct one in a document with multiple layers. I started noticing my eyes' behaviour even with just 5 or 6 layers, or so. The visual grouping of the control is all wacky.
Aside from the distance, the tiny checkmark target exacerbates this usability issue even further. It really is quite terrible UI design on display here. Beautiful example of how not to implement this basic task.
This design decision would be understandable if the task were a hardly-used one, but controlling the layer visibility is quite a fundamental action, and used all the time during work.
I am unsure what the developers were thinking when they decided to put this action so far away from the layer's visual and textual identifier. This really is basic 101 interaction design theory.
Having said this, perhaps Adobe has a copyright on this particular interface design?
Refer to this simple explanation of Fitts's Law: https://lawsofux.com/fittss-law
 

Having the layer visibility control on the far right is a usability problem, and plain bad user experience design. I agree with the OP: it's really frustrating to work with.
The positioning of the checkmark breaks a fundamental interaction design law (Fitts's law) because the user identifies a layer by its thumbnail and/or label, and is then forced to follow the row to the right with their eyes to finally uncheck the visibility. But since the distance between layer identifier and the checkbox is relatively large, the eye will often re-check whether the thumbnail is the correct one in a document with multiple layers. I started noticing my eyes' behaviour even with just 5 or 6 layers, or so. The visual grouping of the control is all wacky.
Aside from the distance, the tiny checkmark target exacerbates this usability issue even further. It really is quite terrible UI design on display here. Beautiful example of how not to implement this basic task.
This design decision would be understandable if the task were a hardly-used one, but controlling the layer visibility is quite a fundamental action, and used all the time during work.
I am unsure what the developers were thinking when they decided to put this action so far away from the layer's visual and textual identifier. This really is basic 101 interaction design theory.
Having said this, perhaps Adobe has a copyright on this particular interface design?
Refer to this simple explanation of Fitts's Law: https://lawsofux.com/fittss-law
 

Having the layer visibility control on the far right is a usability problem, and plain bad user experience design. I agree with the OP: it's really frustrating to work with.
The positioning of the checkmark breaks a fundamental interaction design law (Fitts's law) because the user identifies a layer by its thumbnail and/or label, and is then forced to follow the row to the right with their eyes to finally uncheck the visibility. But since the distance between layer identifier and the checkbox is relatively large, the eye will often re-check whether the thumbnail is the correct one in a document with multiple layers. I started noticing my eyes' behaviour even with just 5 or 6 layers, or so. The visual grouping of the control is all wacky.
Aside from the distance, the tiny checkmark target exacerbates this usability issue even further. It really is quite terrible UI design on display here. Beautiful example of how not to implement this basic task.
This design decision would be understandable if the task were a hardly-used one, but controlling the layer visibility is quite a fundamental action, and used all the time during work.
I am unsure what the developers were thinking when they decided to put this action so far away from the layer's visual and textual identifier. This really is basic 101 interaction design theory.
Having said this, perhaps Adobe has a copyright on this particular interface design?
Refer to this simple explanation of Fitts's Law: https://lawsofux.com/fittss-law
 

Having the layer visibility control on the far right is a usability problem, and plain bad user experience design. I agree with the OP: it's really frustrating to work with.
The positioning of the checkmark breaks a fundamental interaction design law (Fitts's law) because the user identifies a layer by its thumbnail and/or label, and is then forced to follow the row to the right with their eyes to finally uncheck the visibility. But since the distance between layer identifier and the checkbox is relatively large, the eye will often re-check whether the thumbnail is the correct one in a document with multiple layers. I started noticing my eyes' behaviour even with just 5 or 6 layers, or so. The visual grouping of the control is all wacky.
Aside from the distance, the tiny checkmark target exacerbates this usability issue even further. It really is quite terrible UI design on display here. Beautiful example of how not to implement this basic task.
This design decision would be understandable if the task were a hardly-used one, but controlling the layer visibility is quite a fundamental action, and used all the time during work.
I am unsure what the developers were thinking when they decided to put this action so far away from the layer's visual and textual identifier. This really is basic 101 interaction design theory.
Having said this, perhaps Adobe has a copyright on this particular interface design?
Refer to this simple explanation of Fitts's Law: https://lawsofux.com/fittss-law
 

For comic work it is absolutely essential to have the option in a layout application to overprint a 1bit 600ppi up to 1200ppi black ink layer over a 300ppi colour one.
I tested this today for the first time in Publisher. While it imports 1bit bitmaps fine, I could not get it to output to a PDF that retains the high resolution black ink layer nor have it overprint a 300ppi colour one. It will either downsample and rasterize the 1bit bitmap to a 300ppi greyscale one, or just display a grey rectangle when I force it not to rasterize anything. 
It might be that I am missing a setting, though. So how do I output a PDF with the 1bit 1200ppi ink bitmap overprinting the 300ppi colour work?
PS  InDesign automatically treats 1bit TIFF bitmaps as overprinting objects, and will retain the original's resolution. In both PhotoLine and Scribus I turn on Multiply blend mode for the 1bit bitmap tiff, and it will overprint and retain the original resolution. But this does not work in Publisher, which downsamples the ink work.

The "Create Guides" function in InDesign is one of my favourite and most-used features in that app. I create a lot of column/row based basic grids, sub-grids, and after installing Publisher and running it one of the very first few things I expected to find was a similar guide column builder, but to my astonishment it wasn't there.
However, Publisher falls utterly flat on its face due to how the handling of guides is integrated. The reason why InDesign's guides work so wonderfully well is very simple, yet effective: guides are treated just like any other object, and are attached to the selected layer you happen to be working in. This effectively means an entire system of grids and sub-grids and helper guides may be built, organized, and maintained through multiple layers. And the colours of individual guides can be changed as well allowing for very intricate and useful nested layout grids to be built.
Publisher's guides are treated like "special" things that do not "live" on any particular layer, but instead are always put in an invisible guides layer over which the user has little or no control. All guides are on or off, and cannot have individual colours, or be managed in groups/layers at all.
In short, nigh on absolutely useless for more complex layout grids. Having access to only one hidden guides layer is SO ill-conceived that I wonder if the developers actually discussed basic layout techniques and workflows with magazine and book designers and creators. 
Only allowing for one singular fixed guides "layer" is a fundamental short-coming of many layout apps. Not offering a good column/row generator either is a second unforgivable mistake from the perspective of anyone laying out semi-complex layouts on a daily basis.
The combination of these two missing options in a new young DTP contender on the market is very, very unfortunate, automatically ruling it out for me or anyone even remotely interested in elaborate grid-based layouting. And even if Publisher received the best grid builder in the world, the lack of layer-based guides in this version would make it rather of limited use anyway. The two go together hand in hand.
Seeing how the guides are implemented on a rather low level in the apps architecture, I don't expect the Affinity developers to re-code this any time soon. At least, I really, REALLY want to be proved wrong here.
If these fundamental shortcomings aren't taken care of at some point, Publisher will remain of quite limited attraction to myself and fellow complex layout grid "layouters". What a shame this would be.

For comic work it is absolutely essential to have the option in a layout application to overprint a 1bit 600ppi up to 1200ppi black ink layer over a 300ppi colour one.
I tested this today for the first time in Publisher. While it imports 1bit bitmaps fine, I could not get it to output to a PDF that retains the high resolution black ink layer nor have it overprint a 300ppi colour one. It will either downsample and rasterize the 1bit bitmap to a 300ppi greyscale one, or just display a grey rectangle when I force it not to rasterize anything. 
It might be that I am missing a setting, though. So how do I output a PDF with the 1bit 1200ppi ink bitmap overprinting the 300ppi colour work?
PS  InDesign automatically treats 1bit TIFF bitmaps as overprinting objects, and will retain the original's resolution. In both PhotoLine and Scribus I turn on Multiply blend mode for the 1bit bitmap tiff, and it will overprint and retain the original resolution. But this does not work in Publisher, which downsamples the ink work.

Hm, InDesign shows such frames in the color of the layer. Assume there are many pages with several objects on the page, it is not suitable to identify such elements in the layers panel.
How should we identify empty frames?
How should we layout something, if we cannot see the frame edges? It seems no good habit to give everything a fill color and remove that later.

I think our memories often deceive us into thinking that things were 'better' or 'easier' in the past. This seems to be part of the 'human condition' with vast swathes of the population pretending the world was preferable to live in only 50 years ago.
Software from the 80s and 90s was, let's agree, much more limited in regards to functionality, and thus easier to master. And hardware capabilities were quite limited as well at the time. I recall being limited to 32 colours from a palette of 4096 and working on a 320x256 screen resolution. I also remember feeling mightily impressed by the sheer graphical power of the Amiga. The first time my eyes feasted on Defender of the Crown? In my memory nothing tops that. From a nostalgic point of view the Amiga will always be my first true computing 'love', with the C64 and Amstrad CPC sharing the second spot.
One application I often see mentioned here and other forums is Freehand, and the assertion that Freehand is still better than current vector drawing software. I worked with and taught Freehand a long time ago. It was good at the time, but certainly not better than current software - the GUI alone is old-fashioned and clunky. Functionality is okay. But again nostalgia plays an important role. That, and animosity towards Adobe for killing the software.
When I compare drawing/painting software from back then (Deluxe Paint anyone? ) with the current Krita or ClipStudio... No competition, of course. Not even in terms of usability. Deluxe Paint or Superpaint didn't even have layers. I can't imagine working without layers nowadays.
Some ancient tech never grows old, tough: I always carry pencils and a notepad around with me for a quick sketch on the road. I tried tablets for a while, but they're awkward, run out of battery, and break when dropped. The screens don't work well in a sunny environment. Drawing on glass felt completely wrong (I even wrap paper around my large Wacom). So after a couple of weeks I returned to ye old pencil and notepad. The 'screen' is always on, the memory never fails (drawings cannot fade away into digital oblivion). Works great even in sun light. Drop it from a ten storey building, and it still works.
 

I think our memories often deceive us into thinking that things were 'better' or 'easier' in the past. This seems to be part of the 'human condition' with vast swathes of the population pretending the world was preferable to live in only 50 years ago.
Software from the 80s and 90s was, let's agree, much more limited in regards to functionality, and thus easier to master. And hardware capabilities were quite limited as well at the time. I recall being limited to 32 colours from a palette of 4096 and working on a 320x256 screen resolution. I also remember feeling mightily impressed by the sheer graphical power of the Amiga. The first time my eyes feasted on Defender of the Crown? In my memory nothing tops that. From a nostalgic point of view the Amiga will always be my first true computing 'love', with the C64 and Amstrad CPC sharing the second spot.
One application I often see mentioned here and other forums is Freehand, and the assertion that Freehand is still better than current vector drawing software. I worked with and taught Freehand a long time ago. It was good at the time, but certainly not better than current software - the GUI alone is old-fashioned and clunky. Functionality is okay. But again nostalgia plays an important role. That, and animosity towards Adobe for killing the software.
When I compare drawing/painting software from back then (Deluxe Paint anyone? ) with the current Krita or ClipStudio... No competition, of course. Not even in terms of usability. Deluxe Paint or Superpaint didn't even have layers. I can't imagine working without layers nowadays.
Some ancient tech never grows old, tough: I always carry pencils and a notepad around with me for a quick sketch on the road. I tried tablets for a while, but they're awkward, run out of battery, and break when dropped. The screens don't work well in a sunny environment. Drawing on glass felt completely wrong (I even wrap paper around my large Wacom). So after a couple of weeks I returned to ye old pencil and notepad. The 'screen' is always on, the memory never fails (drawings cannot fade away into digital oblivion). Works great even in sun light. Drop it from a ten storey building, and it still works.
 

Check out what this guy is doing in Blender 2.8:
https://twitter.com/tauri_34
 

I have to agree on gradient meshes. I can probably count on one hand the number of times I used the gradient mesh tool in Illustrator. It was one of those features that always seemed like it would be really powerful, but in practice was always too hard to get looking just right. 
Illustrator's new freeform gradient tool looks like a big step up, but honestly, I think Affinity Designer still needs to walk before it runs. Fancy gradients are good headline grabbers, but there are other, more basic tools like blend / live repeat, scatter brushes, and vector/pattern strokes that Illustrator has had for over twenty years and Affinity Designer is heading into its fourth without.

This has been requested many times before I realize, but I am going to reiterate it one more time.
As it stands, the export persona is pretty much useless, because it doesn't allow for a real-time preview of the rendered asset(s) to check the quality before export. Therefore, I don't use Photo's export option, and instead export a full quality PNG and optimize in external software.
There are a number of other issues with the export (jpeg quality<->file size, inability to set >256 colour PNG output, lack of dithering options and resample options), but this is really the major one. I don't understand why this wasn't implemented in the first place, but hopefully it will be at some point.

Sure, whatever works. I prefer Opera since it is installed on my local machine, and I can't be uploading licensed (client) work to an online service like that. I need to be able to maintain control over the files.

Sure, whatever works. I prefer Opera since it is installed on my local machine, and I can't be uploading licensed (client) work to an online service like that. I need to be able to maintain control over the files.