I am using Joplin 2.6.9 on Mac OS 12.0.1.
I can't find how to export the rendered version of a Mermaid diagram. I only get the markdown version.
I tried to look for some settings in the preferences but did not see anything related to Mermaid, even in the plugins.
Thanks for your help!
Hey, have you tried exporting the note in pdf or html?
Also, you can download the rendered chart in png and svg from mermaid - Markdownish syntax for generating flowcharts, sequence diagrams, class diagrams, gantt charts and git graphs.
Thank you @graphit0! I did not notice the live editor, at least I can get the figure out.
I did try both html and pdf in Joplin, none came out with the rendered diagram.
Same issue here on Windows with 2.6.9. 2.6.2 seems to be the last version to export to PDF properly.
```mermaid
graph LR
node1 --- node2
renders as code in 2.6.4 and above, but renders as a graph in 2.6.2
Thanks. Yeah, I tested it on windows as well and could reproduce it. Indeed, the rendered mermaid graph doesn't export via PDF.
On linux (2.6.9) works fine though. Once I collect the logs and other info, I will open up the issue on github.
I have upgraded Mermaid and also committed another fix for Mermaid. I have reverted both and it still does not work, so it has nothing to do with these 2 commits.
Unfortunately I don't know what the culprit is, but least I could eliminate my 2 commits related to Mermaid.
@graphit0 Since you mentioned Linux, I checked on Arch (5.15.8-zen) with a manually downloaded appimage and PopOS 21.10 (5.15.5-generic) with the Joplin_install_and_update.sh script. Both give the same error when trying to export PDF:
Error: ENOENT: no such file or directory, open '/home/user/.config/joplin-desktop/tmp/pluginassets/katex/katex.css'
at Object.openSync (fs.js:498)
at Object.func [as openSync] (electron/js2c/asar_bundle.js:5)
at Object.readFileSync (fs.js:394)
at Object.e.readFileSync (electron/js2c/asar_bundle.js:5)
at processLinkTag (node_modules/@joplin…ck/dist/index.js:92)
at Object.onopentag (node_modules/@joplin…k/dist/index.js:154)
at Parser.onopentagend (node_modules/@joplin…2/lib/Parser.js:203)
at Tokenizer._stateBeforeAttributeName (node_modules/@joplin…ib/Tokenizer.js:201)
at Tokenizer._parse (node_modules/@joplin…ib/Tokenizer.js:605)
at Tokenizer.write (node_modules/@joplin…ib/Tokenizer.js:585)
Running the 2.6.2 appimage works fine. @tessus could it be an issue with the export an not Mermaid rendering?
It certainly looks that way, but I don't get any errors in the console.
The rendering itself is fine, otherwise Mermaid graphs wouldn't be shown in the preview window.
That one is a slightly different issue that has been solved, it is a Linux specific case sensitivity issue that didn't affect Windows or macOS
As temporary workaround until the release with the fix is published, you can enable safe mode and do the export.
Also HTML directory export is unaffected by the issue on Windows and Linux (I don't have a Mac), so I suppose we can wait a bit till the new release.
The published issue on GitHub for further tracking
I see the folder name discrepancy now. Sticking to 2.6.2 until the new version. Thanks!
I have a theory on why Mermaid has this issue. I have been following a couple of printing/pdf issue but haven't had time to check on them comprehensively yet. It seems there are multiple problems that causes printing issue for multiple different things but for mermaid specifically the reason might be that webkit never call onload on several events you expect it to call.
I discover this problem while develop several plugins that do "rendering" on the javascript side instead of markdown side. There is a hack for that of course, I will check if it will fix mermaid problem when I have some time for that.
The thing is this worked fine before, so it must be a regression. I suspect that we removed something that made it work previously.
Or do you think it was always by chance that it worked before? But hey, everything is possible with Electron.
Update: When I have a bit more time I will run a git bisect session to find the offending commit.
It is broken in the same commit as the other issue, the html pack commit - Desktop, CLI: When exporting as HTML, pack all images, styles and scr… · laurent22/joplin@98ed2be · GitHub
I did a highly unscientific test and just replaced the entirety of the InteropService_Exporter_Html.ts file with the one from the 2.6.2 commit and it exports the graph.
Edit:
Did some more playing and got rid of just the last function and got the graph back, so it is something in there or something that it calls upon.
(commented out the whole last public async close() function and change it to just async close() {})
Another edit:
Changed this line (line 35 of the same file) to false and it works again - because it then bypasses that function I identified before.
this.packIntoSingleFile_ = 'packIntoSingleFile' in options ? options.packIntoSingleFile : false;
Is there a reason why exporting to PDF needs to go via the additional code added for the HTML single file packing? The change notes imply this should only fire for exporting as a single HTML.
Either way I'll copy this post to the github issue just in case people only look at one of the two
We should probably just use the gh issue to discuss the bug and then post the final solution to this topic, otherwise it get's a bi complicated.... 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.