I would react with a “Thanks”, but I've spent my reacts for today, ha.
Yeah, I mean, I totally get the segmentation thing. Much as I don't want for Designer, Photo or Publisher to turn into Illustrator, Photoshop and InDesign, I don't want Designer to turn into Publisher, or Photo to turn into Designer, or less still Photo to turn into Publisher.
However… Publisher will sort of “morph” into Designer or Photo as needed. What irks me is that Affinity's shared document format concept is much more powerful and versatile than they're ready to recognise or make use of (or, more accurately, to let us make us of).
Yes, it absolutely makes a ton of sense having Publisher at the top (or bottom; ok, let's just say vertex) of a pyramid towards which both raw vector and bitmap data converge. Great! As such, it needs to be a very powerful app. But is it fair that the other two benefit much less from their DTP counterpart than Publisher does from them?
It's as if Serif is throwing in the towel regarding Publisher and just accepting that it offers very little in the way of DTP features, that only a very small subset of users will ever buy it, and that the only way to sweeten the deal further is to have it benefit the most from the other personas, while saving its most basic feature, which could hugely benefit the entire suite, only to itself? Or are they convinced that the crux of editing DTP documents is being able to edit vectors and bitmaps inline? Well… it depends. For self-publishing and small shops, yes. For larger organisations, where stuff may already arrive on your virtual desk pre-digested, not really. You may be yet another cog in a larger machine, and some users may use only Publisher, others may only use Designer or Photo, etc.
As for use cases for DTP features in non-DTP apps, well, Baseline Grids is the crux of the matter here. Seeing them in non-DTP apps was a bit of a revelation for me. As a prospective typography teacher (I won't likely start out as one; I gave some type design workshops, and some classes on colour, but I'll likely make the rounds and teach generic stuff like Project – the main subject in any design course), I can assure you that one can never have enough Baseline Grids. Serif has the chance to redefine those, as not being a DTP feature anymore, but as something which should be present everywhere where a text box, or multiple text boxes, may sit. I wouldn't really mind seeing it as a feature even by default and in all the standalone Affinity apps but, unlike other suggestions I've made before, I fully understand Serif's reasoning for restricting it (for the time being, hopefully, but if it stays that way forever, it's not like their app would be any worse than those of the competition) and it's not a hill I'm willing to die on. But seeing it was a bit like when Apple introduces a brand new product category, which you didn't even dream you had a need for, and suddenly it “clicks” in your head and makes perfect sense. My job here as a tester and customer is to tell Serif all about that, since it didn't cross the mind of anyone over there, it seems, or if it did, it was discarded for dubious reasons (maybe in the short term, it makes sense, as it probably requires some reworking of Designer's Personas, but the way this was handled doesn't inspire much confidence).
So… in any case, what would set apart Designer from Publisher, then? So. Much. Stuff. Not as much as there could be if Publisher was already a Quark- or InDesign-caliber app, but already a lot, yes. Master Pages (that's a big one, and sure, users might be crafty and use a combination of symbols and assets to replace those, but… really? That wouldn't be elegant or practical in the least); spanning objects across spreads (hopefully Designer will allow for that too, one day, once the document model conundrum is properly addressed, but even then I'm guessing it will only be possible by using non-default universal layers, which will be a power-user-bound feature anyway); pages self-aligning to a spine (Designer or Photo will never do this, thus making them inherently cumbersome for “pseudo-DTP”); automatic text reflow when creating new pages (this is an obvious and big one, which its brethren will also never do); pinned, inline objects (this only makes sense for large numbers of pages, and we fought a lot for this one to be a priority for v. 1.7… Either that was one of the few “victories” we had, or we were just lucky that Serif had that one high enough up on the hidden roadmap for it to push through in time); index panel; table of contents panel; some form of GREP-like expressions for automatic text replacement, including GREP styles, and other power-user-bound use cases; advanced text box options; tables…
Is that not enough to differentiate between them already, even in v. 1.7.1? Sure, Publisher will be missing other big ones for quite a while, as per the devs' own admission, like a Multiline Composer equivalent, but still. It will hopefully and quickly turn into a fully functional DTP app in its own right.
However, creating a one-page poster heavy on illustration or other types of vectors might be easier and quicker to do in Designer than Publisher. It all depends on the app where you start, the time you think of spending on each operation, and the relative text-to-illustration ratio. So, check out the example I may redo in Designer as a demo:
This, my friends, is something that, by its very nature, might make more sense to make in Designer than in Publisher. Maybe not this one in particular, but the same kind of single-page, slightly text-heavy but still vector-dominant poster. Sometimes these fonts are not even finished or even imported into Glyphs.app, and I just copy my still vector sketches directly from a different work file, all inside of Ai (again, that was not the case for this one, as this font was already so advanced that 90% of what you see here is all actual text, but having modular type in raw, vector form line up with baseline grids would indeed be awesome). Doing so in a more long-form bound app doesn't make much sense, IMHO (in fact, the official template files usually come in Ai format, leaving any further conversions or reworking up to us). And even though it could benefit from automatic column creation in a DTP app, for such a simple layout which I know I'll reuse virtually unchanged every year, the time it takes me to whip up those more than makes up for not having to deal with extra text box shenanigans; it's not like that with such a bespoke layout, I wouldn't have to link them all manually even in a DTP app, anyway).
The thing with these posters is: I just paste the text into some text boxes, and most of the time is then spent fiddling with those alphabets to get stuff right. In fact, it would be much quicker to re-convert all that stuff to curves and just use distribute commands across the board, instead of bothering with manual kerning and tracking. I know, because I've tried both approaches, and when just doing it with curves it's just much more quicker (the only reason I decide against it when I have the chance is to protect my designs; sure, they are super easy to copy, but I'd rather not make it so easy as to it just being a copy+paste operation away). And the same goes for fitting those titles and subtitles to the grid. Also, if I forget to add an accent or something, it's also easier that way, as I can group them straight away with the corresponding characters.
But where a Baseline Grid manager would really shine here would be to ensure that my smaller, caption text boxes would cross-align with the larger ones at some key lines, in a fixed ratio (usually 4:3, 5:3 or, in this case, 6:4, except I just checked my file and realised that, oops, even though the ratio was correctly set, it's not cross-aligning correctly as it should because… yeah, you guessed it, Ai doesn't have a Baseline Grid and because of some oversight on my part, I got it wrong). To get my stuff to all line up correctly, I'd just have to divide the combined leading of the common, cross-aligned block, by the product of their ratio, i.e. 12, and set that fractional point value as my baseline grid. Boom, done. Most people don't give a damn about this kind of detail, but I was taught this by my typography teachers, I always apply that principle whenever I can, and I intend to impart that wisdom and sense of care on my students as well. Having this feature on all Affinity apps (whether by default or when the three are present, whatever) would go a long way towards enabling this kind of extra care and making them the premium choice for all things typography and typesetting, whether in DTP of a 100+ page document or on a tiny business card. And speaking of business cards, guess what, I sometimes do those in InDesign already because they are precious little objects which physically represent my clients, not quick and dirty posters to show off a work-in-progress font of my own, and I want the extra control it offers me, including baseline grids, but besides that it's totally overkill and I'd much rather do them in something a bit more lightweight, like Designer, while still retaining access to advanced typography features (not exactly tables of contents, pinned objects or automatic text flow, but what we in the field call microtypography, something which should, by default, encompass Baseline Grids; from that it follows that those should, then, extend to all apps which already include some form of said microtypography). Understandably, I'm a bit mad about seeing Serif shooting themselves in the foot with this decision and, once again (and, this time, not for technical reasons), crippling my potential workflows in Designer. I'm really pushing hard for this because it's one of the subjects nearest and dearest to me.
So, yeah, thanks for all the positive feedback guys. I really do try my best here, and I usually back up my suggestions with real-world work. As I've said before, my suggestions are almost always based on past experience, and not just on pure speculation.