LWN: Comments on "Typst: a possible LaTeX replacement"

Fully Tagged PDF (even for math) is in the works for LaTeX

jschrod — Mon, 22 Sep 2025 18:49:02 +0000

You chose to use the one example of an error message that comes without a line number.

In all other error messages TeX's error messages consist of two lines. The first line has the line number and all characters that are read up to the error, the second line has the characters that are still to be processed.

But that is actually a bynote. You wrote

> tagged pdf or other niche features

Since journals (especial scientific journals that Lee wrote about) and other publishers increasingly demand the production of barrier free PDFs for online publication, Tagged PDF is not a niche feature, IMNSHO. Customers of mine currently pour 6-digit numbers of Euro in creation of such files. For private production it doesn't matter -- but for publication, it will soon be a must-have.

Bad feeling ...

mathstuf — Sat, 20 Sep 2025 23:49:03 +0000

> That is not my issue with CMake, it is rather that it "forgot" about things like "make distcheck"

I don't think `distcheck` is all that important for CMake because…the source tree *is* the tarball; there's no intermediate step which bundles everything that needs re-verified

> I'd say that at least on the Unixoid side Makefiles are still the predominant backend being used

I'd be very surprised if Ninja were not the most popular generator these days. I believe Fedora has switched its default generator at this point at least? I know Visual Studio's integration prefers it.

> And the Makefiles it generates are sub par compared to what automake generates.

Oh, I don't think anyone is going to argue that CMake's Unix Makefiles generator is anywhere near optimal. There are a number of reasons for it. The most important is that autotools and CMake are different build *systems* even though they do share support for a common build *tool* as an output. Because CMake also supports IDEs with…rather restrictive ideas on what is possible, CMake's model for the build is quite different than autotools'. The build tool is easy to define: it is a build graph executor. Make, ninja, msbuild, just, rake, build2, boost.build, bjam, scons, tup, etc. are all "build tools" that execute a build graph. The build *system* is where things get interesting (for me). Some build tools are also build systems: build2, boost.build, scons, tup. This is the layer which defines things like "what is a target" and "how do targets relate". autotools and CMake both execute at this level and "compile" their input language to something the target build tool understands. This does not mean that build systems expose everything that the build tool supports (e.g., CMake does not allow users to write their own ninja rule statements because…what does that even mean for its other outputs). Of course, some build tool support may have additional features as long as it doesn't conflict with the overall model of the build system itself. For example, CMake's Ninja generator can drop some dependencies other generators need to support the semantics CMake guarantees if it can prove to itself that they're satisfied in other ways.

Now, there are ideas to rewrite CMake's Makefiles output to be more like Ninja: one global graph without per-directory entry points and without the per-target subgraph recursive instance. This would allow the Makefiles generator to do the same pruning of unnecessary dependencies that Ninja does. But because it was following the IDE model of "the build graph is a series of targets; each target's subgraph is an independent entity", we have the non-optimal behavior of "if A links to B, B must link before anything in A starts" because that is how CMake guarantees things like generated headers in B are available when A starts compiling[1].

So, in short, I think CMake tool a more general approach to build systems and its Makefiles output is suboptimal because of that. But because we now also support the Ninja generator which is, IMO, strictly better (unless one needs a job server for nested builds), restricting the scope to the Makefiles output of each is not a fair comparison.

[1] The link dependency can be dropped if A's custom command dependencies are a superset of B's custom command dependencies: any header or whatever B ends up generating is already in A's graph.

To become success story

NYKevin — Sat, 20 Sep 2025 22:11:59 +0000

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.

Bad feeling ...

hholzgra — Sat, 20 Sep 2025 10:44:43 +0000

Yes, CMake solved the "build on Windows" part, something that autotools with its dependencies on a posix shell, a working m4 preprocessor, and real make (not nmake) could not solve. It also has the capability of generating for other build systems than good old Unix Make / GNU Make.

That is not my issue with CMake, it is rather that it "forgot" about things like "make distcheck" and quite a few other things that autotools had solved just fine for ages. So while it supports other build systems besides good old Make, I'd say that at least on the Unixoid side Makefiles are still the predominant backend being used. And the Makefiles it generates are sub par compared to what automake generates.

That's my "reinvent it ... badly" pain point with CMake.

Bad feeling ...

mathstuf — Sat, 20 Sep 2025 03:30:52 +0000

> (CMake vs. Autotools rings a similar bell, although in a slightly different field)

*sigh* Note that one of the "sparks" for CMake was Windows (as in MSVC, not MinGW-on-Cygwin or MSYS2) support. Something Autotools still does not have today.

Lout

ceplm — Fri, 19 Sep 2025 20:15:50 +0000

The word “maintained” can cover multitude of sins. See https://git.sr.ht/~mcepl/lout (yes, those commit message with just version numbers is everything we have, there is no better VCS repository anywhere; `whatsnew` is woefully incomplete).

Fully Tagged PDF (even for math) is in the works for LaTeX

notriddle — Fri, 19 Sep 2025 19:04:59 +0000

If Typst manages to steal mindshare from LaTeX, I doubt it'll have much to do with tagged pdf or other niche features. It'll happen because, if I forget a closing brace, pdflatex does this:

This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./t.latex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-01-16>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
(./t.aux))
Runaway argument?
{ripe and green) \end {enumerate} \end {document} \par 
! File ended while scanning use of \emph .
<inserted text>
                \par 
<*> t.latex
           
?

And Typst does this:

error: unclosed delimiter
   ┌─ t.typst:14:12
   │
14 │ + #underline[Good gin  
   |             ^

In TeX's defense, it's not the worst system I've ever dealt with, and a lot of that spew can be cleaned up by just putting it behind a --verbose flag, but the biggest, hardest-to-fix problem is here:

{ripe and green) \end {enumerate} \end {document} \par

Typest's equivalent has a line number. It also actually matches what was written. Is that fixable without breaking changes to the macro system?

Lout

anton — Fri, 19 Sep 2025 18:22:12 +0000

Yes, when I read the article, I remembered Lout; a collegue advocated that in the 1990s. And already at that time it was obvious that TeX was a good typesetting engine, but a badly designed programming language, and LaTeX inherited this. Nevertheless, LaTeX has a big community behind it, and obviously Lout was unable to overcome the network effects coming from that. Will it be different for Typst or other contenders? Would it help if they built on each other rather than starting from scratch?

I looked up when Lout was released, and that was in 1991 (with work starting in 1994). The most recent release is from 2023, but apparently that just made it easier to build, so it's not sure if it is still being maintained. But then, if it works, do you really need any other maintenance?

To become success story

anton — Fri, 19 Sep 2025 18:05:41 +0000

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.

Meander for parshape

adnl — Fri, 19 Sep 2025 15:27:20 +0000

I came here to suggest this as well! I'm writing a grant with meander and the developer was able to add multi-page support in <24hrs after I mentioned it, wild stuff

Fully Tagged PDF (even for math) is in the works for LaTeX

paulj — Fri, 19 Sep 2025 13:17:19 +0000

Lyx has very good inline live preview support for Math. It's just 'compiling' the math snippet itself (with whatever environments/packages the doc is using) so it's near instant.

I'm a big fan of Lyx as a great accessible and fairly user-friendly UI for writing documents to eventually typeset with LaTeX. I've used it for my own dissertation and it made writing so much easier. It's also customisable. I ended up making a few of my own definitions for things, with their own menu entries - which was just a matter of adding some UI definition files.

My father went to uni after retirement and (eventually) got a masters. He used to have endless issues with his masters dissertation in MS Word, with the format going screw and *especially* the required citations being very hard to manage and constantly getting messed up. I was constantly having to go over to him to try help him with his MS Word processing issues. In the end, I switched him over to Lyx. Showed him how to make chapters, sections and sub-sections, and insert citations. Told him just to write, and that the formatting would largely take care of itself. I helped with proofing at the end and help with inserting figures and illustrations, but it saved *both of us* a lot of hair-pulling and time.

My dad generally does not get on with computers. He gets very frustrated with complex programmes, with states affecting things he can't see/understand. He became a big of fan Lyx however, for the way it just let him write and generally staying out of the way, while keeping track of all the citations and layout for him, and producing a beautiful doc at the end thanks to LaTeX.

Lyx is a _great_ bit of software!

Fully Tagged PDF (even for math) is in the works for LaTeX

smitty_one_each — Fri, 19 Sep 2025 12:41:44 +0000

In response to:

> the learning curve to access that power is almost impenetrable

One of my pet cliches is: "Everything is easy, when you know how to do it."

Overleaf provides a gentle introduction to LaTeX.

To become success story

dskoll — Fri, 19 Sep 2025 12:21:48 +0000

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.

Meander for parshape

leephillips — Fri, 19 Sep 2025 11:28:12 +0000

Very nice! It even has real documentation.

This was first released while we were still working on the article. In other words, my prediction is coming true: that packages for Typst will emerge rapidly, because it’s easy (easier) to program in.

Fully Tagged PDF (even for math) is in the works for LaTeX

leephillips — Fri, 19 Sep 2025 11:21:23 +0000

Any particular reason? Using Overleaf is a distinctly worse experience than using a locally installed LaTeX with your favorite editor, Git, Rsync, etc. Although not as convenient for this as Typst, LaTeX can be set up to provide a live preview (but it will lag behind “live” when your document swells, as LaTeX lacks Typst’s incremental compilation).

Fully Tagged PDF (even for math) is in the works for LaTeX

smitty_one_each — Fri, 19 Sep 2025 10:55:53 +0000

Your attention is drawn to https://www.overleaf.com/

Fully Tagged PDF (even for math) is in the works for LaTeX

Wol — Fri, 19 Sep 2025 09:52:16 +0000

AOL.

This seems to be a major blinker problem in FOSS. My brother's comments about his experience of Emacs at Uni 40 years ago are classic - when he first started he thought it was awful, impossible to use, way too complicated. Then after a year or two, once he'd mastered it, he couldn't imagine using anything else.

The reason Word conquered the world (and the reason I hate it) is because it was aimed at people who COULDN'T TYPE - the managerial guys who had professional typists, the couch potatoes who didn't do much, etc etc. WordPerfect - which I took to like a duck to water because it (on the surface) mimicked a typewriter - which failed in large part due to MS's dirty tricks - couldn't compete in the battle for the minds of the people with the purse strings, even though it was a much better professional solution.

FLOSS so often is such a super swiss army knife that anybody new approaching it is left thinking "but how does it fix MY problem ???". I use lilypond, and it's incredibly powerful, but the learning curve to access that power is almost impenetrable (it's driven by a variant of Lisp!).

Cheers,
Wol

Another project with similar aims

taladar — Fri, 19 Sep 2025 09:19:05 +0000

I would argue it is the opposite. Every "purely declarative" or "deliberately not Turing-complete" language eventually gets turned into one anyway because otherwise you lack too much expressive power so you either have the choice of doing so deliberately from the start or doing so accidentally with bad ergonomics later.

To become success story

anselm — Fri, 19 Sep 2025 08:34:12 +0000

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.

Meander for parshape

yashi — Fri, 19 Sep 2025 06:06:35 +0000

> Typst provides no analogue to LaTeX's parshape command

Meander seems to do it: https://github.com/typst/packages/pull/3065

To become success story

wtarreau — Fri, 19 Sep 2025 05:20:52 +0000

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.

Fully Tagged PDF (even for math) is in the works for LaTeX

intelfx — Fri, 19 Sep 2025 02:46:19 +0000

> Just in the last few years, a major undertaking starts to produce tangible results: LaTeX Tagged PDF https://latex3.github.io/tagging-project
> This is bound to be incorporated into the next TeX-Live release and thus will appear in all major Linux distributions in due course.

How does this help with UX of *writing* in LaTeX, which seems to be the major issue driving the competing developments (and specifically the subject of the article)?

<...>

I understand that LaTeX is something you relate to, but your response reads somewhat like this:

- Project A sucks at ABC, and I'm badly tired of it, so I don't wish to use project A anymore. I'm looking forward to possible replacements.
- But project A is the best at XYZ, so this proves we are better than project B!

Fully Tagged PDF (even for math) is in the works for LaTeX

jschrod — Fri, 19 Sep 2025 00:28:36 +0000

Readers of this article might be interested that work on LaTeX is ongoing. This is not a decades old dying project as some of the comments might make you believe - who report of problems that happened 25 years ago.

Just in the last few years, a major undertaking starts to produce tangible results: LaTeX Tagged PDF https://latex3.github.io/tagging-project/
This is bound to be incorporated into the next TeX-Live release and thus will appear in all major Linux distributions in due course.

With it, one can prepare barrier free PDFs with acceptable effort - *even for math*. I don't know if any other system that provides this level of capability. This is the stuff that gets developed in established FOSS ecosystems by people who work on typesetting systems since decades.

Disclaimer: I'm personally involved in the LaTeX project, though I'm not a developer any more.

To become success story

jschrod — Fri, 19 Sep 2025 00:03:07 +0000

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.

About the compatibility story...

ejr — Thu, 18 Sep 2025 20:58:01 +0000

This. Unfortunately some functionality relies on external programs (e.g. eps<->X conversions). Those do bitrot.

There was ConTeXt as well. I'm not sure of its status. And "worse is better" seems to have been a thing for me this week in many venues.

About the compatibility story...

SLi — Thu, 18 Sep 2025 20:54:34 +0000

Have you tried modifying those .sty files?

If only the underlying language was something modern and somehow modular and encapsulated instead of a weird macro mess with not-really-scopes.

Maybe I never got deep enough into it to really appreciate its cleverness (now I do appreciate that it's 50 years old), but in my experience it doesn't exactly take just "not thinking" to not break something by an unrelated change.

About the compatibility story...

SLi — Thu, 18 Sep 2025 20:49:17 +0000

I use LaTeX because the other options tend to suck more, but I sure hope something more solid replaces it. As of now, I understand TeX enough to wonder if it really seemed a good idea even when it was invented; but, granted, the TeX part is relatively solid, in the same way perhaps as MS-DOS is relatively solid and it's all the applications causing all the problems.

I think one big problem that I've seen in my field of CS is that people have become used to the output of LaTeX to the extent that everything else looks "unprofessional" to them merely by virtue of being different, even if it fixes some real annoyance in LaTeX output.

So while I still do my maths and typesetting often in LaTeX, I'm actually happy that the modern practitioners are refusing to take that route, even if it means them using Word. We shouldn't teach people to rely on stuff built on MS-DOS and Cobol either, even if the best typesetting tool remains some obscure DOS executable.

About the compatibility story...

hholzgra — Thu, 18 Sep 2025 17:12:06 +0000

My early 90s experience was different, I wrote my bachelors thesis with WinWord 2.0a originally, then after switching universities for my masters degree they made it clear that they would expect me to use LaTeX, so as a learning exercise I re-did the complete thesis using LaTeX (somewhere around the switch from 2.09 to 2ε).

WinWord could already no longer process it properly when WinWord 6.0; the version right after 2.0a, came out.

The LaTeX version worked all the way until late 1999, when due to a series of mishaps the source was lost and I was left with only the PDF result, which I still have. (Generating PDF from Word documents on the other hand was basically unheard of back in the 1990s ...)

I also still have a few smaller texts I've written after the 1999 backup disaster, and these I can still process using current LaTeX versions.

Bad feeling ...

hholzgra — Thu, 18 Sep 2025 17:02:41 +0000

I somehow have a similar bad feeling about this as I had about replacing DocBook based documentation stacks with AsciiDoc, or even worse: MarkDown derived solutions.

Lower entry barrier for sure, but always having a taste of

"Those who do not understand XXX have to reinvent it ... poorly"

(CMake vs. Autotools rings a similar bell, although in a slightly different field)

I'm afraid that once again we are forgetting about quite a few things that were already solved in the past by switching to such new solutions carrying less of a history with them ...

About the compatibility story...

pizza — Thu, 18 Sep 2025 13:02:22 +0000

> Whether the MS Word documents render the same as they did before, hell whether they render the same on one PC as another, is another question though.

...Even on the *same* PC, with the *same* version of Word, "rendering the same" was not guaranteed.

(Back in the day, I recall that merely changing the printer driver was sufficient to cause the document to paginate differently..)

Another project with similar aims

smoogen — Thu, 18 Sep 2025 12:41:48 +0000

The first company I worked at was a browser company who thought that you could meet 80% of all document pages with something simple. What we learned was that what we thought was an 80% solution really only covered 20% of the actual document space. This seems to have been the case with many other attempts I have seen over the years. You can add a couple of items in a highly opionated method of 'this is our one true way' but you quickly find that there are conflicting 'choices' in how people visually perceive layout.. In the end you either accidentally create a turing complete language or put one in on purpose.

To become success story

aragilar — Thu, 18 Sep 2025 12:35:09 +0000

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.

Lout

ceplm — Thu, 18 Sep 2025 11:36:31 +0000

I was a big fan of Lout (http://jeffreykingston.id.au/lout/), which has very clear (fully functional) language for writing was PostScript oriented from the beginning (yes, that shows the age of the project). Unfortunately, the author was never interested in moving the program to the Unicode world we live now, and especially there were just not enough packages for it to really take off. Pity.

Another project with similar aims

epa — Thu, 18 Sep 2025 10:10:06 +0000

So Typst is still a Turing-complete programming language? It would seem cleaner to have something less powerful, or at least define a subset without fully general macros that's good enough for 80% of documents. I think that gives a better chance of forward compatibility too: some of the unhappy experiences with LaTeX bitrot are because LaTeX packages can do anything at all, so it's hard to guarantee that a new version works the same, or to automatically convert documents from old to new.

About the compatibility story...

paulj — Thu, 18 Sep 2025 09:38:15 +0000

Whether the MS Word documents render the same as they did before, hell whether they render the same on one PC as another, is another question though. (And the answer is "often not"). So your "perfectly" very likely has a wide margin of error.

Very friendly and helpful Community

al4711 — Thu, 18 Sep 2025 09:21:54 +0000

At my beginning with Typst I had a punch of questions and the Peoples at the community forum https://forum.typst.app/ was very friendly and helpful which is also a point of view, imho.

About the compatibility story...

Cyberax — Thu, 18 Sep 2025 02:18:05 +0000

I have LaTeX files from university days (early 2000-s). I can't render them anymore. Ironically, MS Word documents that I wrote during that time are perfectly readable.

About the compatibility story...

iabervon — Wed, 17 Sep 2025 21:26:01 +0000

I think there was originally a model of fetching the packages you were using and storing them with the document that used them (and not continuing to update those copies); you had to go and get packages and get them again for them to change. As networking got faster, we switched to effectively having a local mirror of CTAN that you used packages from directly and updated periodically, which means that maintainers who aren't thinking about long-term backwards compatibility break old documents.

About the compatibility story...

dskoll — Wed, 17 Sep 2025 21:24:00 +0000

Hmm... I have three manuals I started writing 20 years ago and continued writing through 2018; they total almost 600 pages and still build perfectly fine on whatever version of LaTeX ships with Debian 13.

I don't go crazy with untested or new packages, though... all of the packages I use have been around for a long time and are very stable.

About the compatibility story...

warrax — Wed, 17 Sep 2025 20:51:58 +0000

Yes, TeX itself has been rock stable, of course, but the idea that you could just rebuild LaTeX documents years after making them hasn't been true for me. I can't remember the exact packages I used which broke, but I'm certain it wasn't anything particularly advanced. Of course it broke with inscrutable error messages, etc.

I do think you're correct that backward[1] compatibility *is* important, but the LaTeX ecosystem as a whole isn't necessarily great at that... it very much depends on what packages you use.

[1] Future versions being able to process old code/documents is usually referred to as 'backward' compatibility.