Mermaid.js state diagrams do not always render in Windows

[afonit]

I have had some mermaid diagrams work, but many don't.

I setup a new environment to test the beta:

conda create -n lab_b1
conda activate lab_b1
conda install -c conda-forge/label/jupyterlab_beta -c conda-forge jupyterlab
jupyterlab 

I was working through some examples on https://mermaid.js.org/ and noticed a lot of them don't work in jupyterlab.

Example 1

On this page:
https://mermaid.js.org/syntax/stateDiagram.html

This is what that site shows:

Here is the code:

---
title: Simple sample
---
stateDiagram-v2
    [*] --> Still
    Still --> [*]

    Still --> Moving
    Moving --> Still
    Moving --> Crash
    Crash --> [*]

Here is what jupyterlab renders:

Example 2

On this page:
https://mermaid.js.org/syntax/classDiagram.html
I see this:

Here is the code:

---
title: Animal example
---
classDiagram
    note "From Duck till Zebra"
    Animal <|-- Duck
    note for Duck "can fly\ncan swim\ncan dive\ncan help in debugging"
    Animal <|-- Fish
    Animal <|-- Zebra
    Animal : +int age
    Animal : +String gender
    Animal: +isMammal()
    Animal: +mate()
    class Duck{
        +String beakColor
        +swim()
        +quack()
    }
    class Fish{
        -int sizeInFeet
        -canEat()
    }
    class Zebra{
        +bool is_wild
        +run()
    }

This is what jupyterlab renders:

Example 3

On this page:
https://mermaid.js.org/syntax/sequenceDiagram.html
I see this:

Here is the code:

sequenceDiagram
    Alice->>Bob: Hello Bob, how are you ?
    Bob->>Alice: Fine, thank you. And you?
    create participant Carl
    Alice->>Carl: Hi Carl!
    create actor D as Donald
    Carl->>D: Hi!
    destroy Carl
    Alice-xCarl: We are too many
    destroy Bob
    Bob->>Alice: I agree

This is what jupyterlab renders:

[bollwyvl]

Thanks for the screenshots, but can you post a gist of an .ipynb, .md or whatever you are using to demonstrate these? It's possible the exact syntax as embedded in marked, is tripping it up, and may need something more aggressive. We sometimes run into these issues around $ math, as well, but typically fenced code blocks are a bit more reliable.

[afonit]

Let me know if this is exactly what you requested:
https://gist.github.com/afonit/90bc19d6a0bc1c20a1a5cff7e0cc5e6c

[bollwyvl]

The only quick hit I found was likely an upstream mermaid/browser bug: the \n stuff that fully broke the image generates <br>, but SVG (as "proper" XML) won't tolerate that. #15661 does it The Hard Way.

As for the rest: it looks like there's trailing junk after some of the diagram closing fences:

```mermaid      # yep this is right

```[End]        # this is busted
```er!          # this is busted
```sh --> [*]   # this is busted

The markdown "spec" is pretty gnarly, but I don't believe I've seen any implementation that had "afterfence" operators.

[afonit]

Humm, I just copied those from the mermaid site (the little copy button in the top right of the examples) and placed the

```mermaid

around them, I will continue to play with other examples.

as far as the closing junk - yes it looks like some other stuff crept in there, when I go into the cell then shift enter it is somehow getting updated/changed - very curious. I assume that is my fault so I will continue to experiment.

[afonit]

Here is that one reworked.
The first one is a copy from https://mermaid.js.org/syntax/stateDiagram.html and put into jupyterlab

the second one is the same thing, but first pasted into a plain text editor, then copied and pasted into jupyterlab.

Here is the gist:
https://gist.github.com/afonit/24523e841a50431cf410804553376d95

[bollwyvl]

In that gist, it looks like Crash was split by the extra content of the closing "fencepost". The fenced code block must end with three or more of the symbol used to create it, and is really only lax about the whitespace.

```mermaid
flowchart LR
  chicken --> egg
```

Some of the other cells also leave out the closing "fencepost"... but have nothing after them.

From the GitHub-flavored markdown spec:

The closing code fence may be indented up to three spaces, and may be followed only by spaces, which are ignored. If the end of the containing block (or document) is reached and no closing code fence has been found, the code block contains all of the lines after the opening code fence until the end of the containing block (or document). (An alternative spec would require backtracking in the event that a closing code fence is not found. But this makes parsing much less efficient, and there seems to be no real down side to the behavior described here.)

[afonit]

Thanks again for taking a look, so odd it saves like that as this is how it looks in jupyter:

So there is nothing that the end user can do in this situation yes? It will be up to the interpreter handling it you said?

[bollwyvl]

nothing that the end user can do in this situation

Ah, looking more closely at the encoded file, you may very well be getting bitten by #14715, where windows line endings (\r), confuse the notebook format, server, and other things at various levels when pasted in. I don't have a solution for this, other than potentially manually removing all the offending line endings by hand, in this case.

[afonit]

@bollwyvl , I think you are right. At work my desktop has to be windows so that is what I was trying this on.
When I did it on my linux server and my (home) linux laptop everything worked and rendered fine.

[bollwyvl]

Yeah, windows support is kind of an on-going struggle, and probably out of scope for that (mostly still) little PR. However, this issue did highlight some of the pitfalls of the <img>-based approach, which we need to investigate more thoroughly.

[afonit]

This has been resolved in JupyterLab 4.1.2