How to write LaTeX without writing LaTeX
jarbus.net
jarbus.net
Pandoc shines when targetting multiple backends, like EPUB, HTML and LaTeX/PDF. But the LaTeX markdown package has one advantage when only targetting LaTeX, especially in academic settings: it translates everything to the LaTeX you'd expected. For example, citations are translated into biblatex calls, while pandoc generates all of the citations and the bibliography by itself, bypassing the style and behavior you and your professors might expect.
Even going with bare TeX is surprisingly nicer for plaintext files than I would have imagined. Yes, figures can be hard. But not really much harder than they are in any other tool. With the bonus that I have never really seen a document regress with the addition of new sections.
Really the hardest part of figures and such is coming up with the actual figure in the first place. Most layout issues are ultimately solved by editing the figure.
If you learned it in 20 minutes please point me to the tutorial.
If this is actually a point about latex being difficult to (say) write libraries for then I agree profusely but equally if you are writing latex-without-latex or whatever then you still have to deal with latex's wackiness even if it's got a shiny new frontend with its own quirks.
Some billionaire funding a well designed latex killer would probably be a real gift to science - there is probably a lot of ground to be made up in spreading information (i.e. rendering latex for the web is surprisingly hard) and adding features like (say) structured programming to things like writing mathematics in LaTeX - I'd love for my work to be checked by a CAS automatically for example.
As a personal aside, I can't stand the LaTeX syntax; needing to have a \begin{itemize}, \end{itemize}, \item for every list, as opposed to a simple dash uses way more characters, adds more visual noise, and makes it less pleasant to read when editing. Ditto for something like \begin{tabular} as opposed to a pleasant ascii grid.
Write in a plain text editor, have evince open the generated document, it will reload when updated. Then use inotifywatch to generate on save, or just write a hook in your text editor that will update the pdf.
You don't need to use overleaf to get the overleaf experience...
Ah, the Dropbox comment springs to mind: https://news.ycombinator.com/item?id=9224
Adding a hook for compilation in most decent editors is only a few lines of config, and many popular editors (GNU Emacs, vim, m$ vscode) nowadays have packages that have these hooks predefined, so it pretty much just comes down to installing a package, which I hope you don't think is beyond the capabilities of the average user. Alternatively there are editors like texworks which provide exactly this feature out of the box.
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.
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.
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).
Extension: raw_attribute
Inline spans and fenced code blocks with a special kind of attribute will be parsed as raw content with the designated format. For example, the following produces a raw roff ms block:
`````````{=ms}
.MYMACRO
blah blah
`````````
And the following produces a raw html inline element:
This is `<a>html</a>`{=html}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...
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.
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.
I feel that it led to the development of KDE. I remember Matthias Ettrich released LyX and it used the Qt toolkit.
The next year I remember Matthias announcing the "Kool Desktop Environment" and it also was based on Qt. I don't know if Matthias just really like Qt or if he was happy with the success of LyX and decided to make an entire desktop environment.
Highly recommended if you just want to get started.
Actually, you can just write "numbersections: true" in your front matter. You can also add "toc: true" to get a Table of Contents.
For better control over styles, you can also tell Pandoc to use a DOCX or ODT document (the latter doesn't seem to work as well as the former) as a reference to how to style specific styles when generating a word processor document.
pandoc --reference-doc custom-reference.docx -o resume.docx resume.md
Then use LibreOffice or whatever to convert the DOCX to PDF.My current setup tho is org-mode + cdlatexmode + mathpix.el [2-4]. Then writing latex isn’t that bad.
[1] https://www.texmacs.org/tmweb/home/welcome.en.html
[0] https://orgmode.org/manual/Built_002din-Table-Editor.html
Now, as soon as I'm reaching for packages outside of core, things change. But, again, as soon as I do that in any other package, heaven help me. We still haven't made our tables on our tools site align the numbers on the decimal point.
And if you ask TeX people how to do these things, they will tell you you don’t need to, at which point you will die a little inside.
I should add that I disagree that TeX has a good solution for decimal-point aligned columns. It has an absurd solution which involves dividing the column into two “columns”. As with many TeX features, as soon as you want to do this programmatically, it becomes a nightmare.(I don’t claim that any other markup languages are better at this – HTML still sucks for it - though Excel may do okay.)
Agreed that the TeX solution is bad if you want semantic markup of a table. If you abandon the idea of selective fields, it doesn't seem that bad to me.
I'm also trying to do it with a choose-your-own-adventure style novel and am less sure I'll be able to do that since it requires more custom stuff to get the page refs right. But I think it's possible.
I'm not really sure what would be impossible in pandoc-to-latex that is only possible in latex. Can't you always do custom latex templates and filters, and pass through other latex code?
People tend to be messy and don't really care about code presentation, only whether it "works".
LaTeX code written with care is a pleasure to use; same as other code in general.
I dare anyone to edit an MS Word document via its xml.
They might have it now, at the time I was shocked the dev refused to even consider inclusion of the feature, even if a patch was submitted (from what I remember).
for emacs users, org-mode is another, even greater option in the long quest to treat tex like an intermediate representation.
(for everyone else: org is to latex like markdown is to html)
Oh, and you've got magit[1] as a smarter git front-end to manage versioning.
I use zotero[2] for all of the bibtex management.
You can rapidly toggle display with something like https://github.com/io12/org-fragtog , which is a convenience method on top.