enjoysmath
commented
2 years ago It is json befor they convert it to the base64 string so it’s just removing that call wrapper at the call site of the export class implementing url exporting. Just duplicate the export class and make that change if you want the base quiver to be updated. Then you have to add in a quiver gui button in your.is
On Wed, May 25, 2022 at 10:08 AM Amélia @.***> wrote:
So I have a very specific problem. At the 1Lab https://1lab.dev, we're currently discussing how to implement a dark theme: plt-amy/1lab#75 https://github.com/plt-amy/1lab/issues/75. Part of the problem is that, right now, our commutative diagrams are (though made with Quiver), rendered with tikz-cd and converted to svg with pdftocairo, which is.. suboptimal. One of the problems is that tikz-cd is much worse at renderi commutative diagrams than Quiver is, but the bigger problem is that tikz-cd really really wants to draw on a white canvas. Not great when you're trying to display the resulting diagrams on a black backdrop!
The "proper" solution to our problem would be #8 https://github.com/varkor/quiver/issues/8, but AIUI (from the comments on that issue), SVG isn't quite up to the task yet. While there is support for embedding quiver in a website using an
So I have a very specific problem. At the 1Lab, we're currently discussing how to implement a dark theme: https://github.com/plt-amy/1lab/issues/75. Part of the problem is that, right now, our commutative diagrams are (though made with Quiver), rendered with tikz-cd and converted to svg with pdftocairo, which is.. suboptimal. One of the problems is that tikz-cd is much worse at rendering commutative diagrams than Quiver is, but the bigger problem is that tikz-cd really really wants to draw on a white canvas. Not great when you're trying to display the resulting diagrams on a black backdrop!
The "proper" solution to our problem would be #8, but AIUI (from the comments on that issue), SVG isn't quite up to the task yet. While there is support for embedding quiver in a website using an
<iframe>, this doesn't really work for our use case: we have a principle that the mathematical content of the website should work with noscript, and JS should be reserved for chrome. I think this precludes using the<iframe>embed, since aiui that'll use the JS renderer fromq.uiver.app, but I'd be happy to be wrong about this!There's really two things I want:
A human readable/writable import/export format, since we embed commutative diagrams inline (example). But if designing and implementing quiver's own "commutative diagram language" is out of scope, I'd be more than happy to put the 1lab's diagrams in separate files, and use JSON (or something like); I just don't think it's appropriate to include big base64 blobs in the 1lab's source control.
The ability to render offline. The concrete use-case would be loading up quiver as a node.js library, giving it the description of a commutative diagram, and have it render the corresponding HTML.
I'd be more than happy to PR support for (2) if you tell me where in the code I should start poking!