Revise the decision to change the rendering pipeline!
Closed this issue · 22 comments
With previous method to use the VS Code rendering pipeline plus Markdown Kroki extension, you were able to render a ton of different diagram types directly in your markdown files.
This functionality is now lost! Now you have to support everything on your own (e.g. #322 etc.).
I considered the method to use the VS Cide rendering pipeline a very smart design decision to reuse existing functionality and not having to implement again and again the support for new diagrams.
When it is rendered in VS Code correctly ba any extension, then it were also able to print it with your extension.
@PeterWone So please, revise this decision or bring back the old method via configuration option.
Try 0.12.5
Didn't revert rendering pipeline. Did support Kroki. If you have a local Kroki server there is a setting for the URL to it.
Hi Peter,
Sry, the Kroki rendering is not working with your extension v0.12.8.
Expected output:
BR,
Gregor
I tested with Mermaid diagrams rendered by Kroki, because that's what I had on hand. They work, but thanks very much for the comprehensive test document, which made it trivial to reproduce the problem. An update will follow as soon as I figure out what's going on with other types. I did stand up a local Kroki server and test the setting for using that - which works perfectly.
Try 0.12.9, I tested with your sample.
v0.12.9 is working with https://kroki.io but still failing with our company internal kroki instance.
How do I get to the debug output for your extension?
There weren't any diagnostic logs surrounding the very new Kroki handling but there are now in 0.12.10
Thank you for your ongoing assistance.
I am testing with local Kroki, very recently stood up. While obviously Print must be a lot more robust than this, possibly it's time to update the company Kroki? but don't do that till we get this sorted!
The way Kroki throws errors requires parsing of the response. Sometimes it starts with <?xml, sometimes with <svg etc. I can't just look for "Error" because as likely as not that string is part of a diagram. In this attempt I have inverted the logic to looking for </svg> anywhere in the string on the basis that I won't get a false positive from diagram text unless the diagram was rendered which is success anyway.
Our server is up to date with v0.25.0, so I do not expect problem here.
The HTML preview is giving following output fetch failed, so I suspect this line has exception: https://github.com/PDConSec/vsc-print/blob/master/src/renderers/processMarkdown.ts#L60C45-L60C53
Improving the error logging for fetch() exceptions (see discussion here vercel/next.js#49896) might reveal more details.
My guess would be certificate problems in TLS handshake or something in that area with fetch().
I'm using the fetch that's baked into Node so I'm not really sure how to respond to that.
I get fetch failed from my local server when I try to use https. The default setup is http, not https. You aren't trying to use https://something:8000 are you?
We do. https:// is mandatory to be used.
I did some testing with Postman and found that some tools may have problems with SSL certificate validation, like self signed (or company internal signed) certificates.
This may be a workaround: https://stackoverflow.com/a/59944400 .
If that's the problem you can tell node where your additional certs are
export NODE_EXTRA_CA_CERTS=/path/to/your/ca.crton Windows it's
set NODE_EXTRA_CA_CERTS=C:\stuffed\subfolder\thefile.pem
I doubt the problem is the Kroki end rejecting because that would bork everyone.
As a quick test before you go to the trouble of finding certs you can disable the check
export NODE_TLS_REJECT_UNAUTHORIZED=0Also get 0.12.12 and try this new setting. I don't have any invalid certs on my network, so I haven't validated this except to the extent that it doesn't seem to break anything. You'll want 12 anyway because the resource resolver is now async to stop diagram rendering from stalling page generation. It was originally designed for pulling fast loading static resources from the bundle, not on-the-fly resources from page-embedded source. For this use it had to become a caching proxy.
v0.12.12 is working perfectly out of the box!
I did not change the setting print.rejectUnauthorisedTls.
Well isn't that just fascinating. To implement the setting I had to switch from Node's built-in fetch to using Axios (a popular library) because the built-in fetch lacks an option for this.
It would appear we have found a node bug.
There will be another release, hopefully this evening after work (it's 15:36 here right now) which uses a double cache
- when there's a miss it tries to use the hash to load from disk thereby demand-populating the in-memory cache
- when that also fails it renders, updates the in-memory cache and the disk cache
- because the key is a hash of the diagram source, if you paste the diagram into another document, you'll still get a file cache hit
We are using the extension jebbs.plantuml v2.18.1 which supports the PlantUML !include directive for local files.
This is essential for maintaining a single source of information for various software components. Additionally we are using an extensive set of preprocessing directives collected in a library include file.
The extension is setup correctly and the preview is WYSIWYG. But Print fails here.
HTML Preview:
I've had a good look, and as far as I can see the functional difference between this and a Kroki call to PlantUML is the resolution of include directives.
- Is that reasonable?
- Is it complete?
If it's reasonable and complete, then essentially I need to lift the path resolution logic and use the jebb.plantuml settings to resolve the include files and replace the include directives with the content of the include files after stripping their @startuml and @enduml lines.
Note that the way I implemented this you can now use it with any Kroki diagram.
If you have any further requirements please raise new issues