Comment by jihchi

Comment by jihchi 7 hours ago

This is cool! One use case is generating a Mermaid diagram as an image. For example, you can use the following HTML[^1]:

  <!doctype html>
  <html lang="en">
    <body>
      <pre class="mermaid">
    graph LR
        A --- B
        B-->C[fa:fa-ban forbidden]
        B-->D(fa:fa-spinner);
      </pre>
      <script type="module">
        import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs';
      </script>
    </body>
  </html>

Then html2png.dev will serve you:

  https://html2png.dev/api/blob/oTVGhhCc6rDZYQFDIE3EGkcKs-KO6J9-_DHs-jO2OJc-d23fb4f2.png

[^1]: https://mermaid.js.org/config/usage.html#simple-full-example

JimDabell 6 hours ago

Why wouldn’t you just use Mermaid to generate the PNG directly?

Reply View 3 replies

Garlef 6 hours ago

One reason I could think of: Fewer dependencies that need integration

Reply View | 2 replies
- JimDabell 4 hours ago
  
  By introducing a dependency on a third-party service with no SLA? This seems to make the dependency situation worse.
  
  Reply View | 1 reply
  
  mcny an hour ago
  
  Ah haha. I love this conversation of trying to find a product market fit in public.
  What if the input to the JavaScript (mermaid in this case) is not trusted to run on the end client machines but by running untrusted input on a sandbox (this service, or self hosted idk) is somehow acceptable and the output a blob of an image is acceptable to display on the actual client machines.
  Takes the planets to align just right and need us to squint just enough but I think we can find something if we look hard enough.
  But then mermaid can simply output PNG so you could run it as a worker... Thinking...
  
  Reply View | 0 replies