Use both. RMarkdown + Beamer or something.
Reach for Markdown, not LaTeX
91–100 of 184 posts
Re: Reach for Markdown, not LaTeX
#92Earlier quoted context omitted.
Fair enough. My wife uses Adobe tools for typesetting, she is a professional (she pays $100/month for her CS subscription, however). I'm not a professional, I've looked at the amount of effort needed to refine output in these tools and they make LaTeX look usable...
I find that in most cases InDesign takes an order of magnitude less time/effort and dramatically less frustration to get a particular careful output than MS Word, LaTeX, or other commonly available tools. Your wife probably has difficult requirements and exacting quality standards, and could likely get output with quality equivalent to common documents prepared using amateur/automatic tools in a much shorter time, if…
I just updated my resume two weeks ago. Too bad couldn't find the original LaTeX code, so I had to write a new one.
I tried looking for some free MS Word templates, and didn't find anything fit.
Curiosly, I found one while browsing at https://www.overleaf.com. LaTeX again :D
Re: Reach for Markdown, not LaTeX
#93This is great.
I write 100-200 page functional spec documents at a vendor for large scale file based broadcast systems (10-300 linux servers) for a number of customer projects, and have been trying to get away from word since it's slow at that scale and I don't want to spend any time on formatting, and want to get to a templated approach for the others on my team with a consistent output.
Currently I'm using markdown with some CSS and just use Marked2 (Mac) to export but don't have it all worked out yet. Markdown + LaTeX + Pandoc is probably better and more powerful or precise than using CSS. I don't use equations but I do use tables a lot and I'm using multimarkdown ascii ones for now (with a nice atom.io auto-format plugin to make it easy to author) and some code blocks with syntax highlighting.
The idea is to have a folder per customer/project spec, with a consistent structure of one .md file for the body and a local sub-folder for images (svg workflow(bpmn)/system diagrams mostly, some jpgs for logos, screenshots). The folder would be in a local git repo so we can commit changes and export diffs to see what changed between versions and have multiple people work on the same doc with tracking.
I'm using "invisible links" for in-line comments at the bottom of each section that are added while going though it with the customer since it usually takes 5-30 versions before it's finalized and signed off. Those keep a record of discussion with the customer and don't get rendered out in the final output. Also using standard set of status tags (@outstanding, @done, @info) within the comment text.
Ex; `[Note: YYY-MM-DD]: # (comment text @status-tag)`.
Going through the in-progress spec with customers and typing notes inline has been much better than word's commenting system and using markdown makes it easy for the customer to read without extraneous formatting code in-line.
Currently using a multimarkdown header for variables; customer name, project name, author, author email, spec version, etc., but I might move that to a separate YAML file.
Ideally, to make each version of the spec it would be markdown through LaTeX/Pandoc to render a PDF with;
- Title page generated automatically using variables (multi markdown header or separate YAML) - Automatic Table of Contents - Automatic header numbering (h1-h6) - Automatic header/footer using variables & auto page numbering - Ability for basic control of image size; 80% width (svg), original pixel resolution (pngs), etc., positioning. - Ability to have global paragraph numbering in sidebar that the customer can reference while discussions are ongoing, and turn that off for final output to PDF.
I'm going to spend time with the examples from the original link to try to work that all out but any suggestions or tips would be greatly appreciated. I'd be happy to post an example of the final template and write-up of the approach on GitHub.
Re: Reach for Markdown, not LaTeX
#94Author here! I'd like to take a second to point out that the audience I had in mind when writing this article was mostly my fellow classmates in college. In school we were hastily introduced to LaTeX freshman year and were required to typeset our homeworks before submission. The point of the article isn't "you should never use LaTeX" but rather "hey, there's this other, simpler tool that you might like better!" plus…
I'm a bit confused by this. As I see it, LaTeX can do everything that Markdown can before things get complicated. Where LaTeX does get complicated (e.g. when designing figures or drawings), Markdown doesn't offer any advantage or even any functionality. For composing simple documents or outlines and doing typesetting of equations, LaTeX has some boilerplate but it's really not that much.
LaTeX in my experience, is worse than markdown for one crucial use case: formatting code. Formatting large blocks of monospaced text (especially monospaced text that includes character sequences that can be interpreted as LaTeX commands) has always been kind of a chore. In markdown, on the other hand, it's as simple as enclosing the text between two sets of triple-backticks (```).
Re: Reach for Markdown, not LaTeX
#95Earlier quoted context omitted.
If you haven’t tried it yet, I encourage you to give Markdown + Pandoc a try for printed docs. Pandoc can take a LaTeX template and flow Markdown into it. I find Markdown formatting simpler to remember and execute than LaTeX, and there are a huge number of editors and live-preview apps that will let you validate your Markdown as you write. A few keystrokes, and you get a beautiful PDF document, flawlessly typeset in…
Makefiles address that. make html pdf This one has many OSXisms & wants some homebrew bits, but may give you a starting point: https://pastebin.com/raw/H43MKTCq Referenced utility script: https://pastebin.com/raw/J6quT7Mj
Yup, having a default Markdown doc project that you clone is a big help. That way, you can include a Makefile, as well as embed LaTeX header info.
For cases where you really need to share your doc with coworkers in an editable form, you can even define an MS Word target...
Re: Reach for Markdown, not LaTeX
#96Author here! I'd like to take a second to point out that the audience I had in mind when writing this article was mostly my fellow classmates in college. In school we were hastily introduced to LaTeX freshman year and were required to typeset our homeworks before submission. The point of the article isn't "you should never use LaTeX" but rather "hey, there's this other, simpler tool that you might like better!" plus…
I'd also add that while Markdown and LaTeX can do some of the same things, they're designed toward very different tasks. I've used both numerous times in my career, and I can't remember a case where it's been ambiguous which tool was more appropriate for the task. If it's going to be printed, you probably want LaTeX. If it's going to be rendered to a screen, you probably want Markdown. If it's going to be rendered to…
“If it's going to be rendered to a screen and printed, better start looking for a job, because that project is going down in flames.”
Ah that explains what’s going on at Safari Books...
Re: Reach for Markdown, not LaTeX
#97Author here! I'd like to take a second to point out that the audience I had in mind when writing this article was mostly my fellow classmates in college. In school we were hastily introduced to LaTeX freshman year and were required to typeset our homeworks before submission. The point of the article isn't "you should never use LaTeX" but rather "hey, there's this other, simpler tool that you might like better!" plus…
I can second this. Markdown and Pandoc work quite well together. I write documents professionally using this setup. I do fall back to LaTeX for certain formatting, but it's actually quite easy to build pass-through filters so that raw LaTeX can be inserted when specialized formatting that can't be easily simulated in Markdown is required.
I'd be very interested in any details of your approach that you could share. I added another comment to this thread with the details of what I've been working on for professional spec documents with markdown and rendering to PDF (testing with CSS now).
Re: Reach for Markdown, not LaTeX
#98Author here! I'd like to take a second to point out that the audience I had in mind when writing this article was mostly my fellow classmates in college. In school we were hastily introduced to LaTeX freshman year and were required to typeset our homeworks before submission. The point of the article isn't "you should never use LaTeX" but rather "hey, there's this other, simpler tool that you might like better!" plus…
I'd also add that while Markdown and LaTeX can do some of the same things, they're designed toward very different tasks. I've used both numerous times in my career, and I can't remember a case where it's been ambiguous which tool was more appropriate for the task. If it's going to be printed, you probably want LaTeX. If it's going to be rendered to a screen, you probably want Markdown. If it's going to be rendered to…
> If it's going to be rendered to a screen and printed, better start looking for a job, because that project is going down in flames.
What makes you say that? I'm just finished up my first published book. The entire thing is in LaTex, which is extremely powerful. With conditionals and macros etc. etc. So I make a print-ready pdf and I'm good to go.
I run the whole thing through pandoc and it spits me out an ePub that's good to go for the eBook version.
Works a treat. I do battle LaTeX some days, but the results are gorgeous.
Re: Reach for Markdown, not LaTeX
#99Earlier quoted context omitted.
Wow, this is just so far off the mark I don't even know where to begin. LaTeX excels in three areas that are crucial for writing complex documents -- cross references, citations, and indexing. You clearly have not had to endure the house of horrors that is the MS Word ToC, or trying to get autonumbering working as you wish for sections, figures, and tables, or managing a large (100s of pages) multipart document, or a…
I thought Latex was superior to Word in every way than I had a colleague that knew Word. Word if you learn it is just fine generating a ToC or autonumbering sections, figures, and tables. In practice, Markdown is better than either for documentation that isn't printed. It's easier to edit, can be viewed with a plain text editor, and has a minimal learning curve.
"Word if you learn it is just fine generating a ToC or autonumbering sections, figures, and tables." : but can it do this? -- [Common Lisp Quick Reference](http://clqr.boundp.org/clqr-a4-booklet-all.pdf)
Re: Reach for Markdown, not LaTeX
#100Earlier quoted context omitted.
I thought Latex was superior to Word in every way than I had a colleague that knew Word. Word if you learn it is just fine generating a ToC or autonumbering sections, figures, and tables. In practice, Markdown is better than either for documentation that isn't printed. It's easier to edit, can be viewed with a plain text editor, and has a minimal learning curve.
> I thought Latex was superior to Word in every way than I had a colleague that knew Word. Word if you learn it is just fine generating a ToC or autonumbering sections, figures, and tables. No, it doesn't work well even if you know what you're doing. It's much better than when blindly trying to hack your way through, but there are still so many weird quirks it does which you always have to spend a lot of time on.
I would say it works well if you know what you are doing, but in a shared document there is always some dumb ass in the team that does some manual formatting like using the bold-button instead of changing header type, or remove a link from an image. Then the all the references and indexes are beyond repair with the only way to salvage the document is to slowly, meticulously and painfully go through it in this outline-view and try to identify what should be a header and what should not.
If only there was a way to create a Word document that forbids manual formatting it could actually be usable.