Export to Typst/Fletcher diagram

[FliiFe]

I've implemented initial support to export to Typst diagrams. Incompatibilities are reported through the incompatibilities metadata object (that is: shortened arrows, empty arrow body, and k-cells for k > 1)

This still needs some UI adjustments to show the incompatibilities and instructions just like with latex.

I marked this as Draft because I feel like this feature cannot be fully used as-is since I haven't implemented in-browser rendering of the formulas. Looking into how to do that with typst.ts.

Feel free to leave comments and to try this out. Diagrams should be readily useable with

#import "@preview/fletcher:0.5.3" as fletcher: diagram, node, edge

at a document's start.

[FliiFe]

For a bit of fun here's an example in which I crammed almost every variation of options (except those that are incompatible with Fletcher)

[FliiFe]

@varkor Couple questions if you have time for them.

At this point I've implemented Typst rendering, but the (AFAIK only) library is very bare bones so I've had to work around some minor issues. Notably, concurrent renders seem to break the library but I've implemented a queue for the rendering, which is quick enough to work as a permanent solution. Onto real issues:

• Typst.ts loads a 20MB binary in memory (it's the wasm-compiled typst compiler). Would you rather have everything load from the project as is currently the case with KaTeX, at the expense of having a 20M binary added to the directory, or would you rather load the library & binary from a CDN ? Obviously there's no doubt in my mind this will end up being opt-in and lazily loaded.
• When rendering with Typst, I simply overrite the innerHTML of the corresponding label.element. From what I could gather this is also what KaTeX does. However, some functionalities seem reliant on those .katex, .katex-error divs existing. Could you briefly explain why ? What I've noticed is that
  1. all the labels for edges have disappeared
  2. moving cells is completely broken

Do you have an idea about the possible cause of these breakages ?

Cheers

[FliiFe]

quiver/src/arrow.mjs

Line 550 in 4fee690

const defs = this.requisition_element(this.svg, "defs");

This call is returning undefined if I do render arrow labels with typst. The rendered version is an SVG, and in execution of requisition_element, elements.length is actually 3. This means at some point the SVG generated by Typst was taken into account when it shouldn't have. Any idea where the corresponding selector resides ?

EDIT: Fixed, see commit below.

[varkor]

Thanks for the pull request!

I must admit that it hadn't occurred to me that Typst has different syntax for mathematics than LaTeX, which makes support for Typst subtler. I suppose it will be necessary to have a toggle in the UI for LaTeX/Typst mode – I'll have to think about how to do that without complicating the UI too much.

• Regarding loading the binary, my feeling is that (at least for now) Typst users will be a small minority, so that it probably makes more sense to load it from a CDN (this can always be changed in the future if/when Typst becomes more popular).
• Once a KaTeX equation had been rendered, we need to examine the corresponding .katex, .katex-error element so that we can measure the width/height of the equation (since KaTeX does not have APIs for measuring equations, or at least did not when quiver was initially written). This is used to work out the bounding boxes for the label elements, so that they are positioned and cropped correctly. If there is some element whose width/height corresponds to the dimensions of a Typst equation, it should be possible to simply use that element in place of the .katex, .katex-error elements – I don't believe there are any special features of those elements that are being used that wouldn't be valid more generally.

Unfortunately, the timing is a little inconvenient, as I'm about to go on a research trip for a few weeks, and don't yet know whether I'll have time to look at this in detail before I get back. However, if I don't manage to look at it during my trip, it will be a priority for me once I return. I'll try to answer any questions you have in the meantime, though.

[FliiFe]

Thanks for your time ! Regarding the second point, this was actually all addressed in the latest commit which makes me confident this is close to releasable. Don't worry about the timing though, I can just host the fork somewhere in the meantime.

What's left (for me) to do:

• Colour labels correctly when rendering with typst
• Add a toggle somewhere to switch between KaTeX and Typst (lazy-loading will be easy to implement). I do feel like this setting should be remembered, via localStorage most likely.
• Implement the incompatibilities-reporting functionality in the typst export window, and maybe add some customization options there too

[FliiFe]

That's it, I'm calling it releasable ! Let me know what you think.

[jingkaimori]

Some detailed but incomplete suggestion for code

[jingkaimori]

Commit 82aaf18 introduced a bug causing typst fails to load when toggling between katex and typst mode multiple times. Here is the patch to fix it:

diff --git a/src/ui.mjs b/src/ui.mjs
index 646d2b8..e1e52d1 100644
--- a/src/ui.mjs
+++ b/src/ui.mjs
@@ -7892,6 +7892,9 @@ const TypstQueue = new class extends PromiseQueue {
 // Load the Typst library as an ES6 module when invoked. Unlike KaTeX, this is on the heavier side of things. We don't
 // wait for it.
 const load_typst = () => {
+    if (Typst !== null) {
+        return;
+    }
     Typst = import("https://cdn.jsdelivr.net/npm/@myriaddreamin/typst.ts/dist/esm/contrib/all-in-one-lite.bundle.js").then((module) => {
         const $typst = module.$typst;
         const preloadRemoteFonts = module.preloadRemoteFonts;
@@ -7912,8 +7915,6 @@ const load_typst = () => {
     }).catch(() => {
         // Handle Typst.ts not loading (somewhat) gracefully.
         UI.display_error("Typst failed to load.");
-        // Remove the loading screen.
-        ui.element.query_selector(".loading-screen").class_list.add("hidden");
     });
 };
 
@@ -8015,7 +8016,13 @@ document.addEventListener("DOMContentLoaded", () => {
     });
 
     // Load immediately if Typst if the renderer set in user settings
-    if (ui.settings.get("quiver.renderer") === "typst") load_typst();
+    if (ui.settings.get("quiver.renderer") === "typst"){
+        load_typst();
+        Typst.catch(() => {
+            // Remove the loading screen.
+            ui.element.query_selector(".loading-screen").class_list.add("hidden");
+        });
+    };
 
     // Load the style sheet needed for KaTeX.
     document.head.appendChild(new DOM.Element("link", {

[jingkaimori]

ColourPicker class provides a LaTeX literal for color. Is it more consistent to display typst literal when typst mode is detected?

quiver/src/ui.mjs

Lines 6901 to 6904 in 82aaf18

	}, {
	name: "LaTeX",
	colours: [],
	}, {

[FliiFe]

ColourPicker class provides a LaTeX literal for color. Is it more consistent to display typst literal when typst mode is detected?

quiver/src/ui.mjs

Lines 6901 to 6904 in 82aaf18

	}, {
	name: "LaTeX",
	colours: [],
	}, {

This list is only ever filled up when importing LaTeX macros and when those macros contain shorthands for color definitions (if I read the code correctly). I guess it would make sense to hide this list when in Typst mode, as there is currently no way to import Typst macros (although this wouldn't be too hard to implement since we use the actual typst compiler with a predefined preamble).

A note for implementation if going in that direction: in a macro list, we can retrieve variable names via standard matching (e.g. /^#let\s+(\w+)\s*=/) and then filter out which of these variables are colors with typst type(var) == "color".

I say in the current state of things, this list can remain hidden in Typst mode. I'm also wondering if it's not worth hiding the Typst export button when in LaTeX mode. This would allow in the future to add buttons for fletcher import and typst macro import without having too much clutter in the bottom bar. Exporting a fletcher diagram from a LaTeX one will also almost always yield incorrect maths syntax (although that can be dealt with using the typst package mitex).

[jingkaimori]

IMO importing external typst content could be implemented in another pr.

I'm also wondering if it's not worth hiding the Typst export button when in LaTeX mode.

I agree with this. And mode toggling button could be moved to bottom bar, so that things related to label rendering appears together.

---

Default mode applied to input is differ between KaTeX and typst. In KaTeX, input is considered as if in math mode, but in typst, input is treated as normal text.

In this pr, a wrapper is applied automatically when typst is selected as renderer. Therefore changing label to text mode needs unnecessary wrapper.

quiver/src/quiver.mjs

Line 325 in 82aaf18

const label_text_to_fletcher_label = text => text === "" ? "" : `[$${text}$]`;

quiver/src/ui.mjs

Line 5610 in 82aaf18

TypstQueue.render(`$${cell.label}$`).then(result => {

But according to #45 (comment) such wrapper should be applied by user.
A better solution is rendering text without math mode wrapping "$${text}$", and create new node with initial label "$$"