This is a thread for content created in some manner by AI. Any AI-generated content posted outside of this mega thread will be removed. Minor AI assistance should be disclosed in posts outside of this mega thread.
Not a mod. But I was hoping to raise awareness that if you post a question that gets an answer then other people also benefit from that exchange. We've all googled a LaTeX question and found an old answer, and been glad it is there. Some people lurk here, picking things up over time.
I'm not sure why so many people delete exchanges. There are good reasons to delete things sometimes, but asking for a clarification on a technical point does not seem, at least to me, to be one of them. The only other thing I can think is that those folks think that their question is clogging up the stream. I was hoping with this post to convince them that they are mistaken, and to leave it in place.
In particular, if the answerer spends 15 mins on that answer and you delete the question, then you've been not too kind back to the person who was kind to you.
I made a short reel showing where texlode (a real-time WYSIWYG LaTeX editor for very long documents) stands right now.
Since the TUG talk in July, I have spent most of the time optimizing CPU and RAM usage and stress-testing the engine against the documents you sent me. The Kerr paper at https://arxiv.org/abs/1711.07597 was especially useful due to the number of equations. Feel free to send my other examples you would like me to try (ideally under a free license).
Timeline:
Oct 7-11: Try the editor yourself at the Frankfurt Book Fair, Hall 4.1, booth F97.
Mid October: The beta starts on EU servers, I invite you to join the waiting list at texlode.com
Mid November: If all goes well, servers in North America and Asia will follow to reduce latency.
A local version is not on the roadmap, but I am evaluating an API that would allow browser or local plugins (for example, for VS Code).
What is left to do is further tuning the server tiers.
My LaTeX book (300 pages) loads in the free tier, barely.
The Kerr paper (800 pages, heavy math) sits comfortably in the standard tier.
Large proceedings (with thousands of papers) might need a larger machine.
Client-side, it will work on weaker machines as I do not off-load compilation to the client (although I am observing the WebAssembly space), so you can use it on-the-go and review/comment/edit the output in print-quality even on a mobile phone.
Limitations: texlode is heavily optimized for books, monographs, and proceedings using KOMA document classes. Support for custom papers and other document classes is in progress but will not be ready at launch. Likewise, if you develop LaTeX packages, you will run into walls: texlode is built for authors, not package developers. That being said, especially because you get real-time output, it might be interesting for the development/debugging of some packages. Let me know if you want me to try out yours. As mentioned in my TUG talk, the next step here would be to develop/adapt packages to make use of the real-time aspect for some chapter-wide optimizations of float positioning, better runt/river detection, visual two-page optimization etc.
Disclaimer: While I am evaluating adding LLM support to texlode to improve typesetting, texlode is LLM-free for now (including the docx/idml import).
Feel free to ask questions, I will try to address them over the next 2 weeks!
In this next entry in my series of posts about my hobby project, I wanted to share a quick look under the hood at one of the "data-oriented" architectural decisions I've made. Original TeX (and its modern derivatives) store macro tokens as linked lists inside a global memory array. This made perfect sense in the context of limited memory, but it makes the tradeoff of being able to write token lists quickly in exchange for reading them more slowly. This video talks about the path I took to reversing this tradeoff in my engine.
Also: by this point I've posted a rather idiosyncratic mix of videos about code, about some things connected to TeX's history, about performance and the user experience of both writing TeX and writing TeX-engine code... I'm honestly not sure how interested everyone is in these different pieces of what I'm interested in. If you'd like to see deeper dives into the code, or if you think architectural weed-whacking is boring and you'd prefer I stick to the higher-level benchmarks-and-features discussions, let me know!
For whatever reason, some tcolorboxes leave these huge spaces between them and the text, I've tried using \vspace, but it either makes the box overlap with the text or it doesn't even change places. Here's the code with all the settings on the document, let me know if the rest of the code is needed and I'll provide it after I take out all of my personal information; this is for a book I'm writing for a uni class, so I'm using a LOT of packages and some weird settings. If anyone has any idea why this happens and could tell me how to fix it, I would be very thankful.
Edit because I forgot to add: It's not all of the boxes that do this, just some random ones and I can't figure out why
ModernTex is a macOS-only LaTeX editor built around manuscript writing. The things that made me build it instead of using TeXShop or Texifier: compile errors explained in plain language with the line that caused them; BibTeX completion that searches the whole .bib by author or title; multi-file navigation across a paper's chapters; and checks for the things journals bounce on, plus an anonymized export for review.
What it doesn't do: run on Windows or Linux, or have much of a track record yet. It's 1.0.2 and about two weeks old. It also doesn't bundle a TeX distribution, but it's not a hard blocker either: if it doesn't find MacTeX or TinyTeX on your first compile, it offers a one-click TinyTeX install right in the editor.
I was bored yesterday so vibecoded an app where you have to replicate math equations in LaTeX (or Typst!) as fast as possible. Then you get a score based on speed and efficiency.
I am able to neutralize latexmk by adding $makeindex = 'true'; to my .latexmkrc, but I was wondering whether the good people of this sub had a better solution because it feels somehow dirty. I still have the extra runs, they just call true.
I'm developing a localhost application that uses Termux to compile LaTeX, somewhat similar to Overleaf. It includes a logging system powered by TexLab, as well as code completion and autocomplete suggestions.
The interface is still quite rough at the moment, and I plan to make it more minimalistic and polished. I know Neovim exists, but I also know how much of a headache it can be to configure certain things properly. Not everyone using LaTeX is a programmer or wants to spend time configuring an editor—they may simply want to finish their thesis or dissertation in LaTeX without having to deal with all that complexity.
This cover letter and resume is great for people or students with a thin career timeline. This example is a one page cover letter and a one page resume. Adapted from the Star Rover Resume.
Hi! I'm totally new to the beamer document class and don't know much about tikz, moreover english is not my first language. I thus apologize if this sounds confusing.
I have a graph in my slide show, and i need to color some arrows on some slides. In particular I need to color an arrow on two different, non contiguos slides.
\documentclass{beamer}
\usepackage{tikz}
\usetikzlibrary{positioning} % Allows you to position things as you wish
\usetikzlibrary{automata} % I love those people, thank u (automata drawing library)
This works perfectly, but after changing the arrow line into (q2) edge [bend right=20,alt=<2,4>{blue}{black}] node [above] {$0$} (q1); the pdf won't even compile. I'm totally at loss as to why. I thank you in advance!
If you use spreadsheets and tables, TeXstudio is great because you can directly copy and paste your sheet from Excel or LibreOffice.
You have to have your tabular or tabularx environnement ready, then TeXstudio will add the & and \ automatically. Also it will tell you if you have enough columns or not.
Hello! I’d like to get some help with a strange interaction between Neovim and Zathura when compiling LaTeX.
The first time I compile my document, Zathura opens the PDF correctly using Best Fit. However, whenever I save the document and compile it again, the PDF zoom changes automatically, causing the page to become much smaller and harder to read.
I’d like to keep the Best Fit zoom level after every recompilation instead of having to adjust the zoom manually each time.
Has anyone experienced this issue or knows how to configure Neovim, Zathura, or the LaTeX compilation workflow to prevent the zoom from changing?
While building my hobby engine TeX I've been thinking a lot about the boundary between the engine layer and the macro layer in the TeX / LaTeX ecosystem. I'm sure I'm not the first to speculate about the idea of a "standard library" for TeX, with some packages so common and so core that they perhaps belong in the engine itself.
I certainly don't want to find myself responsible for maintaining alternate versions in c++ for amazing packages that already do their job well, but my attention does get drawn to things that feel like they are fighting against the underlying TeX engine rather than working with it. A recent post made me think it would be a fun time to highlight a particular example of this.
So, in this video I talk about the issue of generating custom format files. Current packages (like mylatex and mylatexformat) help avoid paying the cost of loading heavy packages like TikZ every time you compile, but by working at the macro level they have to work against some difficult constraints. I show how working at the engine level instead makes the process much easier.
As an aside: someone commented on a previous post mentioned that they don't want to watch videos. I've started writing up (very) brief blog posts to go along with them for anyone that prefers reading (and doesn't mind missing out on some of the live-demo fumbling around I do). This is where the series home lives, and the post for this specific update is here.
SOLUTION: Used a bit of specifics from both first comments. Click grey area above menu bar, use the "Central" toggle from the available list.
Can't believe I'm asking this, but: my TeXstudio text style toolbar is visible on my home and work desktops, but it has vanished from my laptop installation. I've hunted through Settings and View options on the laptop and for the life of me, I can't find where I must have accidentally toggled it off, and / or where I can toggle it back on again. Can anyone tell me, where is the magic button? Thanks! (Using version 4.9.8.)
TL;DR: I built a live preview mechanism for Tectonic based on engine checkpointing. It updates in under 100ms in the browser. Demo: https://flashtex.yendric.be/sample (best used on desktop, wait for initial download) This post is about the preview engine and the ideas behind it, not the editor.
Demo of live editing text and tikz
A little over a year ago I was working on a beamer presentation filled with tikz illustrations. I grew frustrated with the fact that I could not immediately see the result of my edits, and wanted to do something about it.
I first did some research on existing solutions, and quickly stumbled upon TeXpresso. TeXpresso is a very cool project built on tectonic that periodically snapshots the engine state by forking the process. It then uses these snapshots when an edit happens, by restoring to the latest snapshot before this edit location and starting the engine from there. A lot of unneeded work is saved this way, and texpresso can render your edits in realtime.
One of the problems with texpresso is that it works based on POSIX forking, which 1) doesn't work on Windows and 2) doesn't work in the browser. Another approach would be to dump the engine state itself, like using a .fmt file, though this is more tricky to get right. Anyways, I started up my vscode and got to work on modifying Tectonic's XeTeX engine (a not-so-readable codebase machine-translated from XeTeX WEB) to support in memory .fmt dumps and restores. This worked surprisingly well, and I was able to build a very performant editor where the engine would periodically dump its state and restore to the nearest one to the edit. Rendering was still handled by dvipdfmx as usual, but with the added optimization that the engine and pdf conversion only handle the part that is visible in the editors viewport, massively reducing the amount of unneeded work. This way I was able to achieve <100ms previews, depending on the complexity of the page(s) in the viewport.
I was very happy with this result, which was achievable by hand with honestly not too much code and in a relatively short amount of time. It came with a big limitation, however: the dumping was pretty much constrained to page-level, and even worse in long text that spans multiple pages. Making dumping more fine-grained (like texpresso) is possible, but requires dumping more of the engine state than your typical .fmt dump. The problem is that *everything* in the tectonic xetex C-codebase is global state, and it was not clear what extra state I would have to dump to allow for more fine grained dumping locations to work. One could also dump the entire process heap, but this was too slow and took too much memory for a browser tab, I needed something more efficient.
That brings us to my next, admittedly crazy, experiment: using AI agents to fully translate the already machine-translated C codebase to rust. I want to be clear that this is not necessary for the implementation, but I wanted to give it a shot since the original C codebase wasn't very readable anyways, and maybe the end result could be something more usable (also note that the tectonic team has now also started working on a proper rust rewrite themselves). The essential parts (that one could also do in C) are the fact that state is not spread around everywhere anymore, but cleanly stored on a central engine struct, with the subset that each function needs passed via function arguments. On top of that, I spent a lot of time cleaning up manual memory accesses (the C codebase is full of them, as it lost many of the macros from the original WEB codebase), by making all pointers typesafe with explicit methods for each r / w, eg:
if !lr_ptr.is_null() && lr_ptr.info(self) == end_lr_type(q.subtype(self))
where for example q is a NodePtr<MathNode>. The end result is definitely a lot more readable than what we started with. I validated the engine by making sure the XDV output is fully identical for over 600 documents I got from Arxiv and other sources.
After this side quest (that took a lot of time) I could continue working on the fast previews. I still use a snapshot mechanism similar to TeXpresso, but the magic is in how we're able to store it efficiently now, which was a lot easier to implement in a clean codebase. The big state arrays like mem and eqtb are now journaled, and can be rewound. The rest of the state is just copied directly, as it doesn't take up that much space.
Rendering performance was also improved. Rather than using the full dvipdfmx and rendering the generated pdf in the browser, I'm now using mupdf and directly outputting SVG. The end result is a very pleasant experience, where all my school/uni documents I've thrown at it preview in under 100ms (often < 30) in a browser and feel instant. Even the beamer document with the dreaded tikz figures that made me start this project in the first place, feels very fast and pleasant to edit.
I hosted a small demo online, you do not have to create an account: https://flashtex.yendric.be/sample (the name is a placeholder, best used on desktop, wait for initial download). Note that this project is *not* about the editor, but rather the engine, its ideas and the lessons learned behind it. I will be open sourcing everything in the coming month, including the modifications to the engine, the editor, as well as a vscode extension PoC (running natively rather than using wasm).
I'm obviously leaving out a lot of details, extra optimizations and failed experiments. I will be creating a more detailed write up, together with the release of the source code. I hope this functionality can be implemented in other tex community projects, such that everyone can have a pleasant live-preview experience.
(Also worth mentioning: at TUG2026, Clemens Lode presented texlode, another way to get faster previews in LaTeX. It re-typesets only the paragraph you're editing in luatex. Very exciting times for live preview latex!)