Jump to content
You must now use your email address to sign in [click for more info] ×

ben_zen

Members
  • Posts

    5
  • Joined

  • Last visited

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.