Export to Typst/Fletcher diagram #262

FliiFe · 2025-01-09T17:55:16Z

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.

…eaks moving cells.

FliiFe · 2025-01-09T23:46:53Z

@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 · 2025-01-10T21:18:22Z

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 · 2025-01-10T23:29:47Z

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 · 2025-01-10T23:38:22Z

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 · 2025-01-12T20:35:14Z

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

Co-authored-by: jingkaimori <jingkaimori@gmail.com>

jingkaimori · 2025-01-28T17:34:04Z

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 · 2025-01-28T18:33:03Z

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 · 2025-01-29T09:23:36Z

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.

Solved content

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 "$$"

src/ui.mjs

varkor · 2025-03-27T21:11:53Z

I'm now back from my trip and plan to review this soon. Feel free to ping me in a couple of weeks if I haven't gotten round to it by then.

Initial typst rendering. Loaded from CDN at the moment. Completely br…

5f5a26c

…eaks moving cells.

Fix arrow labels, fix cell moving with typst

0247d61

FliiFe added 4 commits January 11, 2025 02:51

Conditional rendering and minor refactoring.

e399c36

Add serve phony target and make nvm dependency optional

cb0cc26

Implemented lazy loading, label colouring, and renderer toggle

bb87382

Added tip and incompatibilities warning for typst exports

861f227

FliiFe marked this pull request as ready for review January 12, 2025 20:33

FliiFe changed the title ~~[DRAFT] Export to Typst/Fletcher diagram~~ Export to Typst/Fletcher diagram Jan 12, 2025

This comment was marked as resolved.

Sign in to view

Load KaTeX via import()

c136458

This comment was marked as resolved.

Sign in to view

Better semantic handling of typst render errors, patch by @jingkaimori

3c07762

Co-authored-by: jingkaimori <jingkaimori@gmail.com>

FliiFe force-pushed the master branch from 05dd6f4 to 3c07762 Compare January 24, 2025 18:39

This comment was marked as resolved.

Sign in to view

Load typst with import()

82aaf18

This comment was marked as resolved.

Sign in to view

Fix regression induced by the previous commit

115a735

Myriad-Dreamin reviewed Mar 2, 2025

View reviewed changes

src/ui.mjs Outdated Show resolved Hide resolved

Pin typst.ts version

9211c38

Do not assume math mode in typst

07d2cf4

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Export to Typst/Fletcher diagram #262

Export to Typst/Fletcher diagram #262

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

Export to Typst/Fletcher diagram #262

Are you sure you want to change the base?

Export to Typst/Fletcher diagram #262

Conversation

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.