ben_zen

These don't feel like arguments against Markdown in Affinity, just more general concerns. For instance, versioning shouldn't be a concern of the data format―it should be a concern of separate version-control tools; I use git, personally, but other people might find other tools more useful. Likewise typographic precision isn't a concern of Markdown; if I'm adjusting the typography, that should happen here in Affinity Publisher. The whole point is that I don't want to concern myself with typography while writing my documents, I want to write my text. Markdown is the format I want because it most plainly and directly represents the prose I want to convey. If there are other attributes―you've been very vague about what metadata you want to include, by the way; are we talking per-word, per-article, per-section?―then that's what YAML frontmatter is for, and that is commonly supported across implementations, and is more or less a standard now. To me, Markdown is the best source-format to use, because it's got so little extraneous data about it. I can export the same document to an epub as to Publisher by way of Word―but I want to get away from that interstitial step. And look, it's about encouraging what we want to see. I'd love to see some outreach from Affinity about this, I'm sure other people have very different potential uses for markdown from me, my writing is very prose-heavy, and not that photograph-dense or otherwise. It'd be very interesting to see what other users could need.

You said in an earlier reply that you didn't see the applicability of Markdown, or its broad adoption; I'd counter with the fact that Outlook now natively interprets markdown syntax and translates it to its own styling on the fly, Notion's admittedly loose structure takes cues from markdown's syntax, Obsidian is markdown-backed, basically every programming website uses markdown in some way for formatting, and several of the more popular web-publishing toolkits available now (Hugo, etc.) are all based on translating markdown to HTML. The point about semantic information is true, but I hardly think it's a dealbreaker―you tout the importance of standardization but the history of achieving standards is the result of a lot of very messy discussions between stakeholders, especially if you've ever encountered the IETF's processes, or ISO committee meetings. So far, markdown has been the field of programmers, web developers, and plain-text adherents... with only brief forays into other areas where a text-first workflow might be useful. To me, my desktop publishing software should receive text with markup and, yes, semantic specification to simplify typesetting. Your argument stops at a vague claim that markdown's not useful for that, and while you're interested in shoving aside the workable but messy for some unstated future, we're proposing adapting a format that's growing in popularity to fit future needs. Basically, Markdown needs a desktop publishing voice, and I think Affinity could provide that voice in the conversation about what the standard should do. If someone else did (other than Adobe) I'd look to them as well, but I don't hold out hope―and I don't feel like writing that code myself, I do that enough in my day job.

As I start another project and continue revising my novel, I'm reminded again that I'm going to need to face actually typesetting my work. Surely, at some point, we'll get proper markdown support for import―it'd fill an enormous gap in my current workflow. That's not even approaching the fact that I want to present text message conversations in a book as the conversations as viewed by a character.

If the concern is about the numerous non-Gruber markdown styles, limiting the supported features to CommonMark, or looking to use specifically Pandoc's extensions, might be worthwhile; Pandoc especially has support for things like small caps in a way that doesn't end up feeling too out of place with markdown as a whole.

This is my goal-state. Being able to reference a root document (or documents, I'm really not picky) and take that to editors, if they're savvy work with them in Git/other VCS, and have Publisher pull directly from my source-of-truth documents. This would also mean that I could build print versions in Publisher, and have the same source material export to ePub.

Yeah, that makes sense. I'd really rather they had the native support, than have to deal with regexes (my current bane elsewhere, too.) Well, hopefully they'll consider it, because I'd really love a direct workflow like that.

This is a lot of what has me iffy about using something like Typst. I'm expecting (I'll test this workflow first, of course) that I can find a browser-based solution for whoever I work with on editing, and they'll still be able to hand me whatever edits. As for how I'd want to use Markdown, it strikes me that, were there direct support, it'd be cool to be able to use the YAML front matter extension to essentially do form-fill. Chapter titles, other elements (time, location) could be stored there, instead of as headings.

I'll definitely give that a look when it comes to editing; I'm happy with my current setup (I'm using Typora for drafting, since all I want is something that puts text on the screen and has some word processing features, and it has a relatively robust pandoc integration.) As for Affinity, I haven't used the suite enough yet (I'm a neophyte Designer user, now looking to extend into Publisher) to really see the limitations on what it handles. I'll probably fall back to the Word export, since that retains the style information I want. I wasn't aware that find & replace could do paragraph styles! That would almost be the way I'd want to do this, although I'd rather it were, well, automated. Here's the CommonMark spec, but a brief example would be something like this: # Demo This is just a quick document to show off how **Markdown** is written. It's a simple syntax, really. ## Headings Headings are defined by lines starting with one or more `#` characters, followed by a space; the _level_ of the heading is determined by how many hashes there are. ## Lists Lists are just: * one thing * followed by another - and can be nested - when it makes sense Gruber originally developed it to be something that could readily convert into HTML, and it's fairly easy to parse. The downside of that is that everyone has their own way of doing it, and not all of them are compatible.

I'm writing a novel currently, using Markdown as my writing format; I want to produce text right now, I don't want to deal with formatting beyond declaring that something's italicized, bolded, whatever. When it comes to page layout, however, while I'm familiar with LaTeX and wouldn't be opposed to exporting to that and using it to generate PDFs, I was hoping to use Publisher, since I've enjoyed Designer so much. Lacking direct Markdown import means I'd need to export first to Word, then import; this also would break my flow for edits, since my root text is always going to be the Markdown. Part of the goal here is to retain the structural clarity that markdown provides, and the simplicity of working with it, while getting the control of a proper publishing suite.