If people are curious, I've worked on this project since February 2026, relatively consistently. In that time, through Codex, I've used around 700M tokens for this project (not counting cache reads), which at API rates would have cost $15k (but I actually paid only around $500 in ChatGPT subscription fees).
The first part I implemented was the basic parser -> SVG renderer (restricted to the simplest TikZ constructs) and then put in a basic drag-and-drop interface to validate whether the architecture was promising. Code structure was decided pretty much entirely by Codex -- it asks my opinion with multiple choice questions during plan mode, which I like. I tend to alternate between feature expansion and code quality passes (e.g. making sure no files are too big, folder structure makes sense, test coverage is good, etc).
Indeed I have scripts for compiling a given tikz figure using latex (in particular dvisvgm so I get an SVG instead of a PDF) as well as my js-based renderer. I apply that script to various corpuses, mostly particular pages from the tikz manual (see https://tikz.dev), but there are also a few books about TikZ that have downloadable zips of all the examples they use. I then inspect the correspondence between the two renderers by eye and give Codex a list of which figures are wrong and why, and it then goes and fixes the underlying issues.
You'd think that finding discrepancies between the renderers could be done automatically, but it hasn't worked well in my experience. The models are multimodal but still kinda blind; they think two pictures are the same even if they are very much not the same. But once you tell them whats wrong, they're then pretty good at iterating until it is fixed. (One could also try to do a pixel diff of rasterized images, but that's super noisy, and text rendering isn't going to be pixel perfect anyway.)
> When using draw.io I’d suggest exporting to PDF instead of PNG so you keep it as vector graphics.
I had trouble getting that working (admittedly years ago) and as long as you have a high enough resolution people can't really tell a difference between it and SVG, though obviously it will make the filesize bigger.
Just tried the text nodes and indeed the arrows work. I guess I would also suggest doing the same for regular shapes.
Thanks, this is good feedback. I think the difficulty lies not so much in code generation, but determining what a user would expect. If I click the "align bottom" button, I would be surprised if
suddenly were to get a new randomly named \coordinate and relative coordinate notation. On the other hand, if you start out with "nice" code, the app will in many cases refuse to let you drag things since it doesn't know (and in many cases can't know) what the drag should mean (do you change the named coordinate or change the offset to the coordinate etc).
A follow-up comment: when dragging, you could perhaps offer a 'sticky' mode (toggle/enable with Shift/Alt/Ctrl key?) that locks nodes to TikZ's default alignment features, and display a tooltip with the anchor position in question. Contrary to most drawing apps, this could be the default mode, and the toggle key could switch to absolute, freeform positioning.
I don't use Typst myself and am not familiar with Cetz. From the docs it looks like it's in early stages of development, so it doesn't feel like the right time to do this to me (or at least should be a separate, perhaps forked, app). But certainly it would make sense to develop bidirectional converters that could in particular be used at file open and file save in this app.
Generally yes! It is permissively licensed. I originally considered writing this app as a VS Code extension (because most app ideas that include a source editor are more simply done as an extension) but then decided that I wanted to have more control over the source view.
Perfect! I've been working on a general purpose Swiss army knife for technical note taking/ knowledge management/ sharing. This could very well be an add-on missing piece for heavier latex rendering and editing. Thank you!
Yeah that's odd, the grid should be square. Is the web version looking correct in the browser? Feel free to paste some screenshots into https://github.com/DominikPeters/tikz-editor/issues and I can look into it.
I think the web version looks correct, although the grid lines are so faint there that it's hard to tell. I'll paste some screenshots to that link--thanks for the work!
> TikZ’s name is intended to warn people that TikZ is not a program that you can use to draw graphics with your mouse or tablet. Rather, it is more like a “graphics language”.
While making the app I was worried that I was going against the TikZ philosophy. Maybe I should have named it "TikZ ist doch ein Zeichenprogramm" (TideZ)..
It does support editing it if relative positioning is used in the code, i.e. if you drag the object it will continue being relatively positioned. But if you add new elements with the various tools, they will be absolutely positioned (not sure what would be a good UI for switching an element to relative positioning) unless you edit the source. You can try with
\begin{tikzpicture}
\node[draw] (A) at (0,0) {A};
\node[draw, right of=A] (B) {B};
\end{tikzpicture}
> not sure what would be a good UI for switching an element to relative positioning
1. Right-click on an existing object, offer drop-down context menu.
2. Menu item `Position relative to...`.
3. The cursor now selects _other_ objects in the field.
a. If there is no other object, then offer to create a new label-less node with (x,y); default to the origin.
b. Once an object is selected, then offer `right of`, `left of`, `north of`, `south of`, `southeast of`, etc as a drop-down menu, and a field for radial displacement.
i. As a stretch goal, offer a `Custom position...` button to specify an (x, y) displacement, or a polar angle and radial displacement. These three options (fixed offsets, Cartesian, polar) could also be tabs in the resultant menu from (b) above.
reply