I’m not trying to flame, I just have no idea why anyone would choose to use it over html/css or just a word processor.
I’m not trying to flame, I just have no idea why anyone would choose to use it over html/css or just a word processor.
Is it really a problem that requires manually writing the code? Seems like there should be more elegant solutions by this point.
You can turn on citation linking (in the text), you can apply a custom latex template.
Once it is all setup, you just write text in Pandoc Markdown.
New students do occasionally complain about images/figures not being where they are relative to the text in the code, thats a solvable problem in latex by embedding it in a minipage but honestly people complain about images having a mind of their own in word too ;)
The problem with wysiwyg word processors is that people get creative and it's very difficult to enforce the same style for all the material.
- I can use my text editor of choice
- I don't have to worry about messing with the formatting by accident
- It goes through git easily
Anything shorter and I just use a word processor, it's not worth the time messing with the boilerplate.
I do use it for writing letters - I have a template I just fill out and it spits out a nicely formatted letter with an envelope.
It's also handy for when I need documents in multiple languages - you can make one change to the formatting and it changes them all.
It's not what it's designed for, but Eledmac has some interesting tabular features — https://ctan.math.washington.edu/tex-archive/macros/latex/co...
There's a good list here — https://tex.stackexchange.com/questions/12672/which-tabular-...
Also, with some care, the tabular environment can be made to work very well. Example —
% In the preamble:
\def\qfont{\usefont{T1}{AlegreyaSans-LF}{m}{}} % only here as used in example document
% In the body:
{\footnotesize
\begin{center}
\begin{tabular}[pos]{| >{\qfont}c | >{\qfont}c | >{\qfont}c || >{\qfont}c |}
\hline
{\textbf{YEAR}} & {\textbf{PLATE OFFERINGS}} & {\textbf{ENVELOPES}} & {\textbf{TOTAL}} \\ \hline
1915 & 1,904.86 & 4,587.50 & 6,492.36 \\ \hline
1916 & 2,165.21 & 5,091.24 & 7,256.45 \\ \hline
1917 & 2,259.34 & 5,441.92 & 7,701.35 \\ \hline
1918 & 2,325.87 & 6,877.40 & 9,203.27 \\ \hline
1919 & 2,848.31 & 8,842.37 & 11,690.68 \\ \hline
1920 & 3,188.90 & 10,785.15 & 13,974.05 \\ \hline
1921 & 3,404.60 & 11,069.74 & 14,474.42 \\ \hline
\end{tabular}
\end{center}
}
Also, as pointed out deeper in other responses, the basic tabular environment is not terrific when you're not just presenting standard table data.
Breaking apart the image and table and letting LaTeX handle the layout Just Worked (TM) and looked better in my opinion. That said, LaTeX images and tables are pretty easy and look great by default when you're not doing something weird with them.
Edit: A better way to phrase this might actually be that a major principle for LaTeX is that I should be able to just drop in a new chapter in the middle of a large document and LaTeX will automatically reflow and typeset the entire document without any of the very specific fiddling necessary in WYSIWYG word processors.
A major example is for instance, figures/images/tables will move to new pages but will remain correctly placed between paragraph X and Y. Because I've marked it up as such, if paragraph Y is on the page following paragraph X, it will bring the figure along with it to the new page. In WYSIWYG word processors, that figure would likely just sit at the end of the page until I manually moved it myself.
When you try to micromanage the layout of a very specific page, even if it's just the title page, you're going to have a pretty bad time unless you've written your own \documentclass. :-)
LaTeX works out amazingly for two very specific use cases: 1) Large, collaborative documents and 2) producing the exact same, highly structured print document over and over. I have pretty extensive experience with the second use case.
When I was Secretary for a non-profit organization, I had an entire little personal library of macros that sat on top of the minutes[1] package. I could open an empty text file, type in \attendee{Name} as people arrived. Type in \maketitle and do a quick preview and the document would instantly build out a front page that included if we had quorum or not, etc. I typed the document exactly as the meeting happened while marking up things like tasks (and who they're assigned to), decisions made (with voting tallies and who motioned what), and so on.
All that data would get duplicated to the end of the document in nice lists for quick reference. It had consistent formatting. The build system (a make file and latexmk iirc) would wrap my new file in the basic boilerplate and spit out the PDF for me to email. I consistently had the meeting minutes published an hour after every meeting whereas my predecessors often took 24 hours or more to publish meeting minutes due to Word being Word. Those documents also lacked a table of contents or the various appendices with summary data.
That said, there were things that I tended to avoid doing, like complex tables or something. There's something to be said for staying inside the box of what comes built into LaTeX. I recall giving up with floating an image to the left of a table on our title page and just plopping the image inline in a horizontally centered paragraph and then putting the rest of the title content beneath it.
Also, many documentation frameworks (sphinx comes to mind) use LaTeX under the covers to produce their PDF output. So you might think you're just using markdown or RST, but somewhere someone is converting that to LaTex or TeX in order to leverage a very good typesetting engine.
- The way I conceptualize it, LaTeX is a word processor. So, for example, if I'm writing a rec letter and I choose LaTeX over Word, I'm thinking "I like this word processor better than that one."
- LaTeX/PDF is often criticized for being static, but in my experience, this is a good thing in most cases. If I am discussing the contents of a file with someone else, it is useful if we are both looking at exactly the same thing.
- I don't try to do any significant programming, or extensive customization of how my documents look. I agree that trying to do so would be annoying, but this is not part of my use case. If you look at a random selection of math papers, say here
https://arxiv.org/list/math/new
you'll notice that all of them look more or less identical.
And you're right, single file HTML with embedded images would be a much better format, but I assume publishers are preventing this.
Reading long form content on a screen gives me awful eyestrain.
Plus I love the smell of a good book.
I hope that e-inc displays will mature. Paired with the UX of a modern I Pad this will replace printed stuff.
It worked fine. There where some minor issues around page breaks. But then again, most people don't use paper for reading anymore, so I'll happily accept these minor issues over the absolute inconsistent hell that is text-selection, searching and hyperlinks in most PDFs.
Or use epub, which lets you store the images as part of the zip archive without having to store binary files as bloated and text editor killing base64 text.
Writing anything with complicated mathematical typesetting, for one; their have been improvements in word processors and thinks like MathML/MathJax, but they are still behind.
Works pretty well for autogenerated docs with more going on than is easy in Markdown, also - but that's often a bit of a wash.
I have various custom C++ programs to generate the puzzles. But, getting the results to a formatted PDF was nearly impossible.
I use LaTeX as I can have my C++ program output a text file which, when compiled with LaTeX, creates the pretty puzzle books.
Essentially, I can press a button and “poof” I have a print-ready puzzle book ready to go up on Amazon.
HTML is not an authoring tool. Maybe pandoc or sphinx or other system would compete.