To become success story [LWN.net]

To become success story

Posted Sep 17, 2025 17:07 UTC (Wed) by wtarreau (subscriber, #51152)
In reply to: To become success story by spacefrogg
Parent article: Typst: a possible LaTeX replacement

> the necessity to maintain forward compatibility as much as possible.

Interesting because while that may be true in theory, it's precisely the opposite that made me abandon it over time. Trying to rebuild my old docs systematically resulted in cryptic errors. Looking on the net suggested that foobar.sty was replaced by somethingelse.sty which was close enough but required modifications etc. It happened to me several times to spend half a day updating a 5-year old manual to accommodate new packages. It might very well just be that some packages are less strict than the lower layers and that I hadn't been using state-of-the-art ones, but for the end user experience the problem is the same, a document you wrote doesn't build anymore spewing many errors. That happened to me with documents written between 1995 and 2000 roughly. Some packages were even related to how to deal with character encodings, which newer versions implemented more naturally but probably caused more difficulties to adapt to. I also remember some of article.sty no longer being compatible with the older one I used. I'm speaking about old memories, as it's been 20 years or so since I progressively stopped using it. It always made me sad because I loved the output quality which was super pleasant to read. Also I remember that newer versions were way simpler to install than the pre-2000 ones where you had to collect styles from everywhere and build your own packages from sources.

to post comments

To become success story

Posted Sep 17, 2025 18:38 UTC (Wed) by ballombe (subscriber, #9523) [Link] (4 responses)

The problem is that some website push you to use the newest gimmick package that will break compatibility in two year instead of the tried and true solution. But how is it different from other software?

To become success story

Posted Sep 17, 2025 20:23 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

If you are publishing something, you don't (usually) have a choice. Your publisher will hand you a LaTeX template, probably with a big stack of arbitrary packages, and tell you to use that. But then what is the benefit of LaTeX being stable, if we're just going to depend on random unstable stuff anyway?

To become success story

Posted Sep 18, 2025 12:35 UTC (Thu) by aragilar (subscriber, #122569) [Link]

My impression (from what packages I was required to use) was the journals didn't pick the unstable (or new or modern or even maintained) packages, but the oldest ones (along with old compilers)? I'm not sure that whatever system is used that the journals will support the latest (or recent) version anyway.

To become success story

Posted Sep 19, 2025 18:05 UTC (Fri) by anton (subscriber, #25547) [Link] (1 responses)

Yes, you get a class file, and a template with \usepackage invocations (or they are in the class file), and if you want to produce the exact same output, then yes, you may need to keep the old packages around. But in that scenario I can just keep the resulting output (e.g., a PDF) around.

If I want to revise the paper (e.g., submit a revision of a rejected paper to a different conference), the original appearance is not desired, and usually I need to produce a different format, so it does not matter much if the original class and template no longer works. What matters is that I can easily copy my text to the new template. That is mostly easy, but recently I have had to deal with templates that want all kinds of meta-data, and place standard elements such as \title and \author in a non-standard location, which makes things somewhat time-consuming. But the main part of the paper can be reused and revised, with a formatting pass at the end.

Concerning longevity, I have rarely had the need to process a really old work, but just to see how well it works, I have tried a thesis from 1990, and the main text works (graphics are separate, and I would have to invest more time to find out how they were built). I also tried papers from 1992 and 1993, and they compiled fine; the paper from 1992 contains Framemaker graphics, and I no longer have a way to convert that to Postscript, but fortunately I have the Postscript output; for one picture, the placement is slightly wrong, though. The 1993 paper looks fine.

Maybe the advantage with these old papers is that there were no style/class files coming from the publication venue, so I just used article (or, for the thesis, report), and not many packages, either.

To become success story

Posted Sep 20, 2025 22:11 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

It sounds to me as if you're arguing that stability is not required in the first place so long as the main text works. Which is fair enough, but it is also exactly the point I was trying to make. If stability does not exist in practice, then obviously it can't be a functional requirement of the software.

To become success story

Posted Sep 19, 2025 0:03 UTC (Fri) by jschrod (subscriber, #1646) [Link] (4 responses)

Well, you mentioning article.sty means you complained about a major LaTeX upgrade that happened in 1994 and your problems, owing to that upgrade, appeared some 6 years later - when many other people report that they had no problems at this time, because backward compatibility was very important to us.

But you still bring this up, 31 years after the upgrade - which was 5 years in the making before. From a developer point of view, this is a complaint about a development that happened 35 years ago.

Are you aware that this statement is similar to "I will not use Wayland because I had to write XFree86 modline configs back then"? (Because, as you surely remember, this was even before the days of the X.org server with better autoconfiguration that now is considered obsolete.)

Disclaimer: I was part of the team that introduced LaTeX 2e back in 1994. I am still connected to that work and to the people working on it, though I'm not an active developer anymore.

To become success story

Posted Sep 19, 2025 5:20 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (3 responses)

I get your point and am not really complaining against LaTeX, which I still love, I'm describing my annoying experience of upgrades. Sure, other programs like gcc break compatibility way more often (every release) and in more subtle ways (silently produce bad code by abusing UB).

The thing is that when you don't use LaTeX often enough and each time you do it's difficult, then what remains of the experience is frustration. The frustration of not being able to reproduce a previous report that you spent a lot of time arranging, etc.

When I was using it on a daily basis 30 years ago, I *loved* it. Never having to think about what the output would look like and just typing was really awesome and I haven't found anything getting close to that experience. And I'm still pleased to read papers written using it, which are instantly recognizable. I'm also a bit suspicious about tools that try to imitate it, because, as you say, it has accumulated decades of expertise in what it's doing, so users risk losing great stuff.

It's very possible that forward compatibility has improved a lot since these experience, but due to these problems I got used to no longer using it. The rare times I need to write something with different fonts and sizes, I just write HTML and let the browser of the moment render it. It's a bit more painful but relies on a standard that's not going to disappear any time soon.

To become success story

Posted Sep 19, 2025 8:34 UTC (Fri) by anselm (subscriber, #2796) [Link] (2 responses)

When I was using it on a daily basis 30 years ago, I *loved* it. Never having to think about what the output would look like and just typing was really awesome and I haven't found anything getting close to that experience. And I'm still pleased to read papers written using it, which are instantly recognizable. I'm also a bit suspicious about tools that try to imitate it, because, as you say, it has accumulated decades of expertise in what it's doing, so users risk losing great stuff.

LaTeX is great if you're largely happy with what it does. If you need to bend it to your will to obtain a specific effect, that can easily become an exercise in frustration – fortunately now there are extension packages which will let you, e.g., control how chapter and section headings look like, which was something that in the 1990s required fairly arcane knowledge of the insides of LaTeX to change in even minor ways. Similarly, LaTeX input is reasonably straightforward to write once you've got the hang of it, but it is an absolute bear to parse if you want to process it with a tool that isn't LaTeX itself. TeX input, if anything, is worse.

The main problem of the TeX and LaTeX ecosystem is that it is, to a large extent, based on ideas which were innovative in the 1980s, but the publishing world has continued turning in the meantime, and TeX's stability guarantee in particular, while commendable in principle, has largely prevented it from evolving along. When TeX was new, PostScript hadn't really been invented yet, PDF wasn't even on the horizon, font technology looked a lot different from what it does today, and Unicode wasn't a thing at all, but now there is no way around these developments. The solutions that Knuth and his colleagues came up with (DVI, Metafont, and so on) didn't catch on outside the TeX community, so TeX has been chasing what the rest of the world was doing in these areas, through non-standard variants such as eTeX, PDFTeX, LuaTeX, etc.

It is true that it is perfectly possible, in 2025, to use LaTeX to typeset a PDF document with OpenType fonts based on UTF-8 encoded input, but this means you have to run a version of TeX that has special code extensions not necessarily found in other versions of TeX, using special LaTeX packages which may come bundled in a “batteries included” distribution such as TeXLive but are not actually part of LaTeX itself. This fragmentation tends to make life with (La)TeX more difficult. Also, nowadays people expect to be able to write a document in a single source format and render it, without source changes, in wildly different output formats such as HTML and PDF, in a way that avails itself of the specific advantages of the format in question, and TeX/LaTeX doesn't really have a straightforward and obvious answer to that requirement like Markdown, Pandoc, or Sphinx (to name but a few examples) do.

I've been a TeX and LaTeX user for 40 years now but I'm looking at Typst with considerable interest.

To become success story

Posted Sep 19, 2025 12:21 UTC (Fri) by dskoll (subscriber, #1630) [Link]

Also, nowadays people expect to be able to write a document in a single source format and render it, without source changes, in wildly different output formats such as HTML and PDF, in a way that avails itself of the specific advantages of the format in question, and TeX/LaTeX doesn't really have a straightforward and obvious answer to that requirement[...]

I solved this problem (with a little bit of pain) for my 600-page set of manuals I mentioned earlier. I wanted PDF output as well as HTML output. There's a pretty nice program called htlatex that does a creditable job of generating HTML, and then I post-processed it to (eg) replace the generated images with the original source images so figures were of higher quality. I also defined a few conditional macros that inserted links to training videos in certain spots... something you can't really do with PDF.

Yes, it was a bit annoying to set up, but once I had my Makefile written, it worked beautifully.

Inclusion of PDF files has been implemented

Posted Sep 27, 2025 9:26 UTC (Sat) by Delio (guest, #179554) [Link]

The article mentions Typst's inability to include PDF files but this feature has been merged recently: https://github.com/typst/typst/pull/6623

To become success story

Posted Sep 27, 2025 11:59 UTC (Sat) by simlo (guest, #10866) [Link]

Seems to me, that what you need is a requirements lock file, similar to what you get with pip compile. Unfortunately, a lot of packaging systems doesn't provide that. You can't even build containers with a lock on the dependencies of the packages you install - at least not in a way I have figurer out.