I'm a fan of both Pandoc and LaTeX.
There's a pretty incredible amount of text preparation which can be done only in bog-standard Markdown, and if that's the case, go for it.
Markdown has its limitations, and if you find yourself starting to fight it ... consider that it's probably time to take the next step.
LaTeX itself is surprisingly easy to write, again most especially if you're writing simple documents.
And using Markdown to bootstrap creating a LaTeX document is also a good option. I find Markdown slightly lower-friction to write, and will use it when either composing or copying works initially. If they do require more complex formatting, I'll generate the first iteration of the LaTeX source with Pandoc, then dive into that and add additional elements or tweak complex sections as needed.
There's really no reason you need to switch. You can put raw LaTeX directly into Pandoc Markdown documents; it'll be ignored in non-LaTeX backends, and in LaTeX it'll just be reproduced verbatim. If you need to tweak the template that Pandoc puts "around" the Markdown content, you can do that too (and then centralize your changes so you don't need to do it over and over again). Eisvogel is an example of a project that does this [1].
I think this is really the best of both worlds, because you can produce documents that (fairly) easily generate print books via LaTeX while simultaneously generating webpages or ePubs for electronic distribution.
[1]: https://github.com/Wandmalfarbe/pandoc-latex-template
Whilst true, you do lose the capability of using a single document source to generate multiple output formats (or at least do so easily) once you do that.
A Markdown + LaTeX file processed with Pandoc will generate LaTeX or PDF outputs fine. It will stumble (or more likely: create incompletely formatted outputs) when you try generating other output formats. I am often using single source to create a number of output formats simultaneously (typically: PDF, HTML, ePub, possibly also plain text and PS).
So long as I stick to a single markup language, Pandoc has a much easier time of it.
Yes, you can embed multiple native formatting bits with some clever playing around with comment characters (I did manage to get both HTML and LaTeX going in one document I was working on, with Markdown as the nominal primary). That's ... not very elegant and tends to be fragile and error-prone.
(I've a StackExchange post somewhere detailing how to do this for those interested.)
My experience is that LaTeX is sufficiently simple and powerful that it's arguably the best underlying universal source.
Using Pandoc, you can still produce HTML or ePub from LaTeX source.
You might want to include or exclude some different front- and back-matter elements or other enclosures. For that I'd recommend developing a good standardised template model and build system (e.g., Makefiles).
You don’t need to play tricks with comment characters. From the Pandoc manual (https://pandoc.org/MANUAL.html) [HN is messing with the backtics, but you get the idea]:
I'm trying to find my earlier example.
This Reddit post describes the challenge / goal:
https://old.reddit.com/r/pandoc/comments/7lnc38/is_it_possib...
And ... found it.
As you suggest, it turns out to be the raw_attribute extension which enables this. Note that this requires maintaining parallel content for each output format.
https://stackoverflow.com/questions/48205029/pandoc-have-eit...
https://stackoverflow.com/questions/48083724/pandoc-markdown...
Yes, it requires parallel content. But I still think this is a better situation than a LaTeX source. While Pandoc can read LaTeX, it's limited to a fairly narrow subset. Anything you do outside of that will generate the raw formatting blocks the gp showed (and won't in general appear in any other format output). And you won't be left with any way to represent what should go in those places in HTML, ePub, etc.
To put it in a more programmer centric way, Pandoc allows you to have the moral equivalent of ifdefs instead of maintaining separate source files for each output format. That's a huge advantage when you want to keep the content in sync.
That’s exactly it. I usually use these raw_attribute blocks for things like tables, when I want more control than I get when leaving it to Pandoc’s translation from Markdown tables to HTML or LaTeX.
Hrm....
Though there are other tools for mapping LaTeX to specific formats.
I'll keep this in mind, and I'm aware that all document formatting specification conversions are lossy, ambiguous, or both. LaTeX seems to me to be the least lossy and most consistent over time, as well as sufficiently lightweight in authoring.
There's an idea I've been using for myself, of a minimum sufficient level of typographic specification. For many works that is truly de minimus. I've typeset book-length works using nothing but Markdown, almost always sufficiently (there are a couple of limitations, with underlining and text justification (right or centre) being the principle ones.
There's no specific hierarchy of formatting levels, though there's a rough classification, from whitespace and emphasis to formuale and interactive diagrammes, as well as document-level constructs such as tables of contents / figures / tables, etc., foot / side / end notes, bibliographic references, and indices. LaTeX supports all of these rather well. Markdown can achieve some of these. HTML itself natively has no inherent concept of many of these, though the typographic and some semantic primitives (e.g., hyperlinks) from which they can be created do exist.
So if I'm looking for a consistent sufficient standard, I'd lean strongly toward LaTeX, and find ways to deal with the edge cases in conversion as they crop up.