Static HTML export

[plt-amy]

So I have a very specific problem. At the 1Lab, we're currently discussing how to implement a dark theme: the1lab/1lab#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 from q.uiver.app, but I'd be happy to be wrong about this!

There's really two things I want:

1. 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.

2. 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!

[enjoysmath]

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: the1lab/1lab#75 <the1lab/1lab#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 <#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 from q.uiver.app, but I'd be happy to be wrong about this! There's really two things I want: 1. A human readable/writable import/export format, since we embed commutative diagrams inline (example <https://github.com/plt-amy/1lab/blob/main/src/1Lab/Path.lagda.md#L167-L172>). *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. 2. *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! — Reply to this email directly, view it on GitHub <#139>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMIF5Z5ENCJM5H73O2APQLVLZNBDANCNFSM5W5ZXQGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[enjoysmath]

Ui.js * On Wed, May 25, 2022 at 11:52 AM Luna Tuna ***@***.***> wrote:

…

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: the1lab/1lab#75 > <the1lab/1lab#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 > <#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 from q.uiver.app, but I'd be happy to be > wrong about this! > > There's really two things I want: > > 1. > > A human readable/writable import/export format, since we embed > commutative diagrams inline (example > <https://github.com/plt-amy/1lab/blob/main/src/1Lab/Path.lagda.md#L167-L172>). > *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. > 2. > > *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! > > — > Reply to this email directly, view it on GitHub > <#139>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAMIF5Z5ENCJM5H73O2APQLVLZNBDANCNFSM5W5ZXQGQ> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[varkor]

1. While a flexible DSL for commutative diagrams would be a nice thing to have, I do think it's out-of-scope for the time being. Regarding instead representing diagrams as JSON instead of base64: as @enjoysmath says, quiver already has an internal JSON representation for diagrams (which is stable, as it's how quiver generates links). So depending on your set up, you should be able to decode the base64 into JSON and store that instead. While this still may not be very human readable, it should be slightly more amenable to diffs than the base64 string is.
2. I think this would not be a lot of work. I may be able to give a more detailed outline later, but for now, the main method you should look at is QuiverImportExport.base64.import. In theory, one could pass a base64 string to this method, get a quiver: Quiver out (which contains the data of a diagram) and then call quiver.rerender to draw the diagram to a <div>. However, at the moment, this logic is not decoupled from the specific interface that quiver uses, so will take some refactoring to make this actually true. I think this shouldn't be too painful, but I haven't thought too long about it. After this, one should then just be able to include quiver.js and a few dependencies and make a call to draw a diagram in a specified <div>. (Interacting with the diagram would not be possible, but this wouldn't be necessary to simply see the diagrams.)

[enjoysmath]

@plt-amy Have you resolved this issue, and what did you do to resolve it?