SDLeary

I think a professional design area would be great. Print Design would be fine as well. If there were a bunch of sub-forums then Book Design might be good as well, as it has its own challenges.

I agree with @philipt18 on the benefits but the site needs a professionals area, in general. Typesetting (but a bright broader?... print design maybe?) could be one sub in such an area.
May I also point out to staff it would not only better show to you how your users actually solve their daily problems, make proper use of the suite, but show painpoints and room for improvement in a more straightforward way. Right now we can only assume how others actually work. Anyway, it woukd show to everyday visitors the software and its real world usecase beyond just the occassional tutorial.
Also, it allow users to interact more one on one without being lost in technical support jargon and exchange critical insights. Right now that energy is wasted because it often gets hidden in offtopic dialogue. The prominence of which just shows the community is being underutilized.

The reason I'd like a forum specifically for typesetting issues is there is no forum for it. It's not a bug, it's not a feature request, it's people with everyday issues like how to best get rid of orphans, widows and runts. How to format a table of contents. Certainly these issues come up with many people. They're not feature issues. It would be helpful to be able to go through the issues others have had, and see how they solved those issues. Search is nice, and of course people should properly title their questions, but it doesn't replace being able to scroll through all typsesetting issues and seeing how those issues are solved. Sure, one can go on other forums for this, but I just thought it would be helpful for Affinity Publisher users to have a place to share their issues. It would also probably help the developers to see the ways people are dealing with the issues, what workarounds they need to use, and see if they can make people's lives easier.

SO glad some people have work-arounds that work for them. Please consider (for example) a professional magazine with a feature article that runs a little long on pages 11-13 and then there's some text continued on page 85.

Figuring out where to break the text on each page of a larger document, making sure that it's not awkward or hyphenated when possible, etc. is all part of the job of layout, and it can't be done in Word or Google Docs.  

Now, a late correction from a fact-check or by-line came in, so everything reflows. How are you looking at page 13 and 85 at the same time to look at how to re-split this article and fit it on the required pages. And the deadline is in under 1 hour to get it to press. Your boss is breathing down your neck. Either you — or the app you're using — are the bottleneck.

Are you going to put it back into Word or Google Docs and then bring it back into Publisher, now the story re-flows, you have to apply style sheets again, check the run-around for pull-quotes, add column and page breaks all over, check for hyphenation problems — basically re-do all the work you've already put in all over again (and have it proofed & approved by someone else). Or can you open it up in Story mode, add the needed text, make the corrections, and then check how it's rendered on the 4 pages in question and make tweaks for the final flow so you can get this document out to press…

And this is a realistic situation.

Now the talk goes back to the lighter usage scenarios, but I'm thinking of a story editor for the heavier ones. Think more complex documents, think workplaces, think larger productions of all kinds.
A story editor is not a word processor. It's a text customization functionality for the process that follows once a layouter has the texts. Of course, most texts, especially larger ones, will start their life in a word processor, but there is so much more work to be done in programs like InDesign, where adapting and troubleshooting the text is clumsy and time-consuming in layout mode, and where a story editor is the professional, focused work tool.
The light usage scenarios are well supported in Publisher 2.1 - I look forward to more for the professionals. For example, cross references are sorely missed and finally within reach.
 

I must agree that a story editor would be very handy. Apart from anything else, there are times when it is just so much easier and quicker to look at and edit a single block of text, rather than jumping from text box to text box or page to page!

I completely disagree with that! It is utterly counterfactual. Such a black and white statement can only come from someone who doesn't know about other people's use of programs like this.
Unfortunately, I see a lot of statements about the handling of text and story editor functions in here that unfortunately clearly show a lack of industry knowledge - both in breadth and dept. This makes it incredibly difficult to have a professional dialog in here, which can be seen in how many threads end up in bickering, and it will, all other things being equal, harm the development of Affinity.
If you don't understand what a story editor is used for by others, and that there are customers who need one, then I recommend that you step aside and let these customers explain their needs and wishes so that they and Serif can find a solution.
Barry

Why wouldn't they know? Too afraid to ask the publisher or the printer? Then don't use it and hope for the best like they already do. What happens to the second run if it is lighter? If you are unable to spec the job to the file accordingly or vice versa then again, do what you do now, wing it.
Having run into a third booklet with "bleeds" in the last couple of weeks which need creep, I'm telling you it would be infinitely useful if it were available as part of the layout software, particularly as I said a margin where designers would know not to drop anything important too close to.

Holy simoleons that is a nice tool for the kit. Thanks very much.
 
That said, creep accommodation should be a part of the design process not just the production process because you don't know what you're going to lose until it's lost. As a printer I can use my best judgement, but I shouldn't have to and, honestly, chances are it'll be automatic in software. Given that AFPUB supports independent page sizes the next step seems obvious, although a "creep margin" would be best.
 

It’s not just about having unformatted text to focus on. For any text that flows between linked frames, a story editor obviates the need to move from frame to frame to find the particular text span that you want to edit.

I'd second (or third) this request, certainly for book covers and tri-fold leaflets etc. Currently setting up a book cover/jacket or tri-fold leaflet artwork as a single page means
a) no crop marks on the exported PDF indicating the spine width or fold marks for a tri-fold and
b) a lot of manual adjustment of the page elements should there be a need to change the spine width
Would be 'nice' to have the functionality of ID in this respect with the ability to have unlimited pages in a spread but certainly three pages for book covers with the ability to adjust the width of the centre page independently of the front and back cover to accommodate changes in spine width which then includes the addition of crop/fold marks for the spine in addition to the crop marks for the front and back covers.
I suspect this is going to be a heavily requested feature...

As someone who writes 1000+ pages technical manuals, I would say that InDesign (starting from CS6) is a viable substitute for FrameMaker. In addition, it offers a more modern user interface, more versatility in the page layout, better support from CAT tools, and compatibility with the Mac.
I've been using FrameMaker for about a decade. When the Mac version was dropped, I switched to the Windows version, that was actually a downgrade (less keyboard shortcuts, worse support for extended characters). At the time, InDesign was severely lacking for a technical writer.
With CS5.5, Adobe started to move some long-document features to InDesign, later perfected in CS6. With multi-chapter synchronization, better ToC and Index management, and other useful features for long manuals, InDesign became a good technical writing tool, mixing great page design features and long document management. Plus, it was nearly-ready for eBooks, worked with spreads (instead of pages), was compatible with multimedia file formats, and exported much better PDFs.
What InDesign still lacks is a multi-chapter outliner, allowing for keeping track of the overall book structure. I don't know, however, if multi-chapter books are still the best idea for long books. I know that bundle file formats like Apple's .pages or .rtfd are folders masked by monolithic files, therefore light on reading/writing, but easy to manage. I don't even know if this type of file can be moved to a Windows or Linux platform without becoming a folder. However, maybe a single bundle file, with options to separate and export individual sections, could be a more modern option for long documents (just think Scrivener, and how it deals with separate sections).
Paolo
 

If it's a matter of a few footnotes in a document your suggestion will work.
If you have a lot of them you need an automated way of dealing with them.

In the Paragraph Styles panel under Paragraph/Spacing you can set the Alignment to the following:
Left Center Right Justify Last Line Left Justify Last Line Center Justify Last Line Right Justify All It would be nice to see the following:
Away from Spine Toward Spine It is needed (for me) in instances where i am working with headers/footers primarily, and for other layouts when putting together books for art exhibitions etc.

Every now and then my left hand reaches up search for the carriage return bar. 

An absolutely essential Baseline Grid functionality is to align text with:
«All Lines» or «First Line Only». Making a Magazine without the «First Line Only» is quite annoying.
Would be great if you could this essential layout feature implement in version 1.

A one liner like this is not a good example of using a table, in MHO. You could, of course, use a table here if you wanted to but it would really be an overkill.
The example above is mostly used in catalogues where each product has its own line of specs. In a book catalogue you could have Number of Pages, Dimension, Price, etc.
In cases like these automatic paragraph styles are a god-send. You only need to deal with text and nothing else.
Whether you prepare your text outside of a publishing application or not you can format the entire text in one fell swoop.
Of course one could use a script to format all the tables, if a given application supports, it but that wold be an extra step and potentially a lot of extra steps.
In cases where a catalogue calls for a number of lines per product a table might be a better solution.

I have other hassles that end up like this, scares the hell out of me then nothing. I worry that there is some sort of deep problem with the code and the OS not playing together nicely and these invisible bugs will bite us all with version 1.8. (Phase of the moon and relative humidity plus how many vehicles drive past in an hour add up to the magic number needed to trigger this.)
Or, no news is good news.

Views > Guides Manager tick and untick the Percent checkbox clears up some problems with guides not displaying. Also I just recently changed the Preferences > Performance > Display to Metal from OpenGL and have noticed an overall improvement regarding a bunch of little niggly graphics problems like this

That smell, that hot lead smell. It smells like victory.
Plus I don't surf.

I was also somewhat dismayed that there was no grid system baked in from the beginning. Being able to set columns from within a text frame is nice, but really doesn't allow you to visualize the page as a whole, especially if you will have multiple stories and graphics on the same page... think newspaper, or the excellent example provided by 3joern above.
SDLeary

As said above: "The option to create a grid with basic margins/columns/gutters should be front and centre, probably presented when you create your new document." Without this Affinity Publisher is ruling itself out of news and magazine markets.

I was also somewhat dismayed that there was no grid system baked in from the beginning. Being able to set columns from within a text frame is nice, but really doesn't allow you to visualize the page as a whole, especially if you will have multiple stories and graphics on the same page... think newspaper, or the excellent example provided by 3joern above.
SDLeary

Yes, it makes creating mirrored designs in facing pages easier.

I was going to post a request for this exact thing, but I'll just add my voice here instead. A simple way to create column and row guides is a must. I actually spent quite a long time trying to find the settings because I assumed they simply had to be there already.
I feel like the Text Frame settings (View > Studio > Text Frame) are also a bit buried given how important they are (as the only way to easily manage columns). 
The option to create a grid with basic margins/columns/gutters should be front and centre, probably presented when you create your new document.