MikeA

I've been hunting about on the web and have run across a few more tools, including something called Pandoc, which its author describes as a Swiss Army Knife of conversion tools. It scores the usual 11 on the 1-to-10 geekiness scale and has the usual minimalist reference material. Whether it can convert from, say, Markdown to a .docx file containing named (user-defined) paragraph and character styles, I can't tell yet.

Thanks. Those tools sound extremely useful, all right. Makes me wonder if there's a tool that can take a plain text file containing tagging of some kind and convert it into MS-Word document, creating named paragraph and character styles as it goes (not just the usual "Heading 1", "Heading 2", etc. styles). That could make the job somewhat less painful. AP supports RTF, eh? I used to try parsing that stuff in scripts. Painful.

Sorry to hear about the no-HTML. These are significant gaps, as it were. The cleanup program sounds intriguing. It might be useful for other purposes, too. What program is it?

Thanks for taking the time to post that. It's an excellent illustration of how critical such a system is for efficient work. It's triggering a memory of once having done a catalogue job in much the same way. The tagging saved a huge amount of time. (I take it from what you're writing that QXP has some life in it yet.) At the shop where I worked we had many problems with a thousand little MS-Word "gotchas." I began to dread receiving customer source material in Word format. Because it contained formatting, working with it was faster than importing plain text. Still, there was always a lot of manual "massaging" afterward — sometimes, line-by-line searches for weird problems. Word would sometimes insert strange zero-width characters — I never did learn what they are — that had to be rooted out. It's a mixed blessing. I hope Affinity Publisher's authors take this kind of thing seriously — much sooner than later. (Or, again, that there's a plug-in architecture making a third-party tool possible. Does AP at least accept plain text with HTML tagging — simple stuff like <strong> or even just <b> — as input? (I haven't bought it yet. I probably will. It really does look excellent in so many ways.)

If the underlying architecture doesn't now support plug-ins, I wonder how much difficulty they'll have adding that later. I never used InDesign — I was out of the book-pagination business long before it became "a thing" — and haven't seen its tagging system. Is it ghastly, along the lines of SGML? My recollection of XPress Tags is a bit hazy. If memory serves, XPress Tags permitted you to specify not just character styles, but named paragraph styles during text import — yes? I actually worked on a book about QuarkXPress way back then. I suppose I could just go look it all up. :-) Even rudimentary tagging would be better than nothing. {pstyle:"some-style-name"}Some text {cstyle:"italics"}with formatting{/cstyle} via tagging.{/pstyle} I suppose that to someone who's never used systems like that, it looks decidedly user-hungry. But to people accustomed to scripting it's a walk in the park. I did this in creating a simple e-book once. Devised my own system of text codes (far simpler than the above) and then wrote scripts to transform the simple codes into XHTML in which the style names matched what was already set up in the ePub editor. Not worth taking the time for a small job, but absolutely worth taking the time to set up if it's a long document. In the end you save a lot of time and headache...

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.