MikeA

-

How strange. I can't imagine what... well never mind what I can or can't imagine. Seems to be a bug.
And you're right — I enabled the Only snap to visible objects option and the snapping now appears to work. I would not have thought of this; the column guides don't strike me as 'visible objects' — but I won't argue with success. Thanks very much. And thanks also to walt.farrell.

How strange. I can't imagine what... well never mind what I can or can't imagine. Seems to be a bug.
And you're right — I enabled the Only snap to visible objects option and the snapping now appears to work. I would not have thought of this; the column guides don't strike me as 'visible objects' — but I won't argue with success. Thanks very much. And thanks also to walt.farrell.

I was talking with a guy who's written extensively about publishing tools. He's a bit miffed about AP's lack of InDesign or QuarkXPress-style tag reading during text import. It might be that AP doesn't plan to try going head-to-head with InDesign in all aspects of the publishing business, such as book pagination. Absent a tagging system in AP, QXP and ID will remain more desirable. For shorter documents not requiring automation — could be a far different story. AP's graphics-related features are very impressive.
If a book contains 20 chapters with 6 paragraph styles per chapter plus two kinds of "hard" formatting (italics and boldface), you're looking at 160 separate instance of typing out the regular expressions and manually entering the style assignments into the Replace dialog. That strikes me as a lot of work that screams for automation. In the absence of a batch operations feature or at least the ability to save search/replace instructions for quick recall — doing this correctly requires that you make zero errors when you're typing the instructions out 160 times. Otherwise you end up having to undo a mistake and re-do it.
That's why the idea of using Word as an intermediate format appealed to me...in theory at least. Tagged text -> Perl script -> HTML file -> import into Word (with the CSS instructions actually creating the necessary paragraph styles) -> save as .DOCX -> import into AP document. Admittedly it'd be a workaround and not a solution, until a read-tagging-during-import feature is added.
As for something like this:
Find: <t>(.*?$) Replace: \1, format with Title Could you give yourself much less to type, repetitively, by doing this sort of thing:
Find: <t> Replace: (with nothing) and format current paragraph with style named Title Concerning the other replacements — e.g., Find: <i>(.*)</i> and Replace: \1 (format with italic) — I would suggest non-greedy matches for those rare situations in which a greedy match would give you some grief. Thus:
Find: <i>(.*?)</i> Replace: \1 (format with italic)
 

Editor's ToolKit Plus 2018, from The Editorum.
http://www.editorium.com
I wouldn't be without it.

I too have requested using tagged text. And if Serif decides to do this, I would prefer QXP's style of tagged text as it isn't as verbose as ID's style. I prepare tagged text for every book to be laid out in Q (and ID) to this day. It is reason #1 why I won't use APub for books. The tagged text is generated from Word to CMS systems to raw data out of SQL I'll import to Access and generate the tagged text from.
I don't think Serif has committed to plug-ins, but there has been a lot of interest shown by users and at least one plug-in developer (Astute).
Mike

I generally do not specify the actual p.style or c.style definitions themselves. But that is certainly possible. Instead I will generate the tagged text like you show. Then once inside of Q, I'll actually modify the styles to suit or import the tagged text into a template with styles already set up to the same names.
Here's an example text block from a tagged text file...
<v13.21><e9>
@01 Date:11
@02 Day:TUE<\c>@03 Title:Nosferatu <@FilmRating>(PG)
@04 Time:7<\a>9pm
@05 Location:Minghella Building
@06 Description:Germany 1922. Directed by F.W. Murnau <\a> with Max Schreck, Greta Schroder, Ruth Landshoff
@07 Length:81 min
@08 Spacing:
The first line is the QXP version + the format (<e9> = UTF8), followed by style names ended by the colon, then the paragraph's text. The <@FilmRating> in this case is how character styles are used. Because the paragraph ends with the c.style, there is no need to use a closing tag or the tag to reset the style back to the p.style (which is simply <$>) presently in use. The <\a> tag is for an en-dash.
Importing into my template results in this section's text frames already formatted, across a few pages of listings.

I use tagged text on far more than books, like the above's newspaper. Each section is processed in the same way, whether an article, page ads, listings, classifieds, etc. It takes me less than an hour with all the sections to produce their respective tagged text files, minutes to import and about 2 hours to paginate and produce the first draft of the newspaper. Nearly every job/job type uses tagged text.
With a decent Word manuscript, a novel takes me between 2-4 hours beginning to end, depending upon images. I couldn't do the same in something that doesn't support tagged text.

New here — not much luck yet with forum search. If there's a discussion about this, apologies for not having found it.
Back in the Neolithic I used QuarkXPress, which supported a tagging method for text import: Simple codes embedded in plain text were transformed into complex formatting during import. The competition didn't have such a feature at the time. It was among several reasons for QXP's becoming the program of record for book pagination (until InDesign came along).
Even years before microcomputers took over the world, the typesetting systems I used had tagging and translation-table features. Same purpose: Prepare text containing simple codes, then get complex formatting during text import. The machines' CPUs ran at glacial speeds compared with what we have now. But the text-import systems were fast and efficient.
It's orders of magnitude faster than importing plain text into a design/pagination program and then hand-formatting it. Search/replace is not efficient unless a program supports complex search/replace enabling it to find starting and ending tags and formatting text located between those tags. Even at that, having to do it repetitively is tedious and time-consuming. (If search/replace can be controlled via scripting, that certainly helps.)
Manipulating text outside the pagination program is inherently more efficient. It can be done with powerful and fast tools ideal for that purpose (Python, Perl, Ruby, and so forth). 
Affinity Publisher looks like an excellent contender. It too needs this kind of feature. If the company has no such plans for the near future, I hope the program has a plug-in architecture enabling a third party to add this functionality. To anyone importing a lot of text, that kind of automation is worth paying for.