A full install means installing ~4000 packages, including their source files (tens of thousands of tex files) and built documentation (thousands of PDF files) and hundreds of free fonts (otfs, ttfs, texs own format).

This is huge (>7GB, not just the 5 GB claimed here).

However, you don't need 99 % of this for any given document.

Not installing the source files and documentation PDFs will alone reduce the size by roughly half.

Only installing the packages you really need from a minimal installation gives you a few hundred megabytes at most for even complex documents.

It's a bit annoying to get the list of packages needed though, since there is not really any working dependency management.

I wrote a python wrapper around the tex live installer [1] to make this easy for CI jobs, see e.g. [2].

On a side note: I'd recommend luatex over xetex.

- [1] https://github.com/maxnoe/texlive-batch-installation/

- [2] https://github.com/pep-dortmund/toolbox-workshop/blob/8b00f0...

It’s mostly a death by a thousand cuts thing.

MikTeX, which is available for Mac and Linux as well as Windows will do on-demand downloading of packages and is probably my recommendation for a new installation.

A lot of the drawbacks to TeX stem from to trying to meet the combined requirements of computing platforms of the 1970s–1990s. All input files effectively live in a single namespace so you cannot have two input files with the same name (the same applies to coding where you have a single namespace for all your commands as well).

I recall I managed to cut MiKTeX down to about 12MB. Never heard a single complaint about it.

Sounds like someone should just create a wrapper that catches file opens of uninstalled dependencies and automatically downloads them on the fly.

https://tectonic-typesetting.github.io/

[EDIT: And in fact, if a cousin comment is to be believed, TeX Live also allows this kind of installation! https://news.ycombinator.com/item?id=32535521]

Hah, TeX Live is... not that.

It's been enormous since I installed it off a CD in the 90s. The idea, and it works, is that you can just compile anyone's stuff out of the TeX ecosystem.

There is just... a lot... in it. You don't need a package manager if you install the whole universe locally. Like I said: not what I would call a modern approach to tooling.

On the other hand, I have latex files from the mid-Noughties and, I don't even need to check: they'll compile if I want them to.

But yeah, if you want just a little piece of TeX here and there, you're off the beaten track. That's not how TUG rolls.

More modern approach: "hey, we have a lot of disk space, we can install everything locally".

Even more modern approach: "hey, we have fast Internet access, we only have to install stuff when we need it".

It also seems quite slow to update, and a recent (?) name change of `tools' to `latex-tools' seems to have broken multicol, which drove me to MikTeX. Internet connection required, but far less headache.

Man, I think once you're Kernighan there should be like a 1gigabit/sec symmetric circuit wherever you go just in case you use it to do something else useful.

Besides, where would you put the bar for “distinguished”? Who would take the decision?

Which should make the problems of any such system obvious: it inevitably becomes yet another “in club” for people with connections and power.

Grand prizes with honorariums and perks of various kinds are a longstanding tradition with value.

I was mostly kidding, but: Kernighan totally can afford a big internet connection wherever he is. But he chooses not to buy it. The social benefit from him having one likely outweighs the personal benefit from him buying it.

Of course, if I still operated internet access and Kernighan was in my area, I'd definitely comp him a circuit. :P

It’s just that the distros also include oodles of (plain text!) macro packages for everything under the sun. There are some legitimately large things such as fonts, but generally speaking a full TeXLive or MiKTeX distribution is bloat by ten thousand 100-kilobyte files, like a Python distribution with the whole of PyPI included.

If you know what you want, you can probably fit a comprehensive LaTeX workbench in under 50M, but it takes an inordinate amount of time.

> a manual source port to a different language is painful enough that nobody tried

there are in fact quite a few, many of which are complete: https://tex.stackexchange.com/questions/507846/are-there-any...

But if you want to have every macro package that everyone everywhere likes, you're going to use some space.

There may be some technical reason why this isn't practical. Anyone know, offhand?

But the reason I don't use it is because I don't always have Internet when I need to write my document. I'd rather download all the packages and their documentation beforehand.

He can try "Tectonic" [0] - a modern XeTeX based TeX/LaTeX distribution that installs a minimum system and then downloads and installs dependencies on-demand. Tectonic is written in C and Rust [1].

[0] https://tectonic-typesetting.github.io/en-US/

[1] https://github.com/tectonic-typesetting/tectonic

[1] https://github.com/tectonic-typesetting/tectonic/issues/459

"MacTeX installs TeX Live, which contains TeX, LaTeX, AMS-TeX, and virtually every TeX-related style file and font. [...] MacTeX also installs the GUI programs TeXShop, LaTeXiT, TeX Live Utility, and BibDesk. MacTeX installs Ghostscript, an open source version of Postscript."

Which is, as you say, considerably more than just "XeTeX".

(Also those are universal binaries containing both Intel and ARM versions which probably adds some heft.)

Heh, I remember when "universal binaries" meant "PowerPC and Intel". Different universes ….

I wonder what distro or editor he is using...

I remember installing teTeX (the predecessor of TeX Live) back in 2003 and I despaired at the file size because I knew it would take days to download on the shitty dialup connection I had at the time. Yeah, it wasn't 5 GB big back then, but it was certainly big by 2003 standards.

Well, I've been using groff on and off for a few years, I can give it a shot. Most "macros" as in TeX, are invoked by having the first character of a line be a `.` and then as in TeX, refer to a name. Now, macros in groff are weird. Macros are not delimited by `{}` delimiters as in TeX, but either by having an environment block like so:

    .TS
    .TE

    .NH 1
    Some heading here
    .PP
    Start of a paragraph.

    .EQ
    f ( x ) ~=~ x sup {2} - 1
    .EN

Groff also does pictures, so you can for example create a box with some text in it (it is capable of more, like strokes, macros, color, and I believe rotation[not sure]). To start a picture, `.PS` and `.PE` will do so, and again, a small language as input in that block.

Now, to print anything you should know the design of the original troff system was heavily based on the UNIX philosophy, which means the output you get from running the groff program prints the output to stdout. Just redirect the output to a file to get a PDF or a PS document.

Obviously, there is much I have not covered in this comment, such as macros, registers, and other exciting topics such as refer(1), but this should give you a quick start.

I didn't know about '\&' as a way to "short circuit" groff from interpreting something as a macro that should be literal (such as a line-initial period). That's great to know.

I've found a couple of resources that have been helpful. Mostly, I've been referring to this[0] page on gnu.org. I've also learned from this[1] article on Linux journal and Luke Smith's YouTube playlist[2] on groff.

To practice, I'm trying to re-typeset a paper I wrote in school that follows the Chicago Manual of Style[3]. I formatted the original in MS Word using a template my school provided, so I have something to visually compare against. I'm using the -ms macro set, mostly because that's what Luke Smith demos in his videos so that's what I got started with.

I've already got a reasonable imitation of the original document, which is fun and a bit rewarding. But there's a couple of very small details that I'm finding difficult to crack. Are you very well-versed with -ms? In particular, right now I'm trying to figure out how to add one blank line of space in footnotes AFTER the horizontal line, but BEFORE the first footnote begins. I suspect I'll need to redefine the -ms macro that controls the trap for footnotes...? But I haven't figured out which macro that is just yet.

[0] "The GNU Troff Manual", https://www.gnu.org/software/groff/manual/groff.html

[1] "Typesetting with groff Macros", https://www.linuxjournal.com/article/4375

[2] "groff/troff for Minimalist Document Complication", https://www.youtube.com/playlist?list=PL-p5XmQHB_JRe2YeaMjPT...

[3] "The Chicago Manual of Style Online", https://www.chicagomanualofstyle.org/home.html

First I would point you to the manpage, but, we all know that manpages are a mess, so it might not be there. I will however point you, perhaps not /super/ helpful, but alas, I know not of any better solution. If you go to /usr/share/groff/current/tmac/s.tmac and search for «module fn», that should be the code for the footnotes. Aside, the -ms name comes from this, -m means macro, and whatever letter comes after it is the macro set, hence why -man will be called an.tmac in groff source code, or in this case, s.tmac.

I am not sure where documentation is on traps in groff, but I assume it’s buried withing some manpage or info document somewhere. Software is crap, eh? :D

Of course, you could ask in the groff mailing list[1], they are usually pretty helpful in these matters. Which course of action you chose is of course up to you, I will investigate for myself as well to educate myself more on traps.

[1]: mailto:[email protected]

I'm struggling to understand this sentence. Who are they? What's a boonie? What's not finished?