Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Picture-generating blocks #307

Closed
pveber opened this issue Nov 20, 2020 · 6 comments
Closed

Picture-generating blocks #307

pveber opened this issue Nov 20, 2020 · 6 comments

Comments

@pveber
Copy link

pveber commented Nov 20, 2020

Following the discussion on discord, I'm opening a discussion to see if mdx could be extended to support graphic outputs. I have prototyped a tool that reads a markdown file with ocaml blocks and produces an html file with toplevel outputs + rendered pictures in the document. My goal here is to see if I can help providing a similar functionality in mdx.

I have to admit it's not totally clear to me how this feature would fit with how mdx works currently. First question is, would that feature make sense in the pp and test modes? Or would it be better to include it only in a new mode (like the jupyter notebook output, or a new mode for markdown to markdown transformation)?

Also, what would the API for picture rendering? How should pictures be rendered in the final document? In my prototype I started using the install_printer directive of the toplevel to install a printer for a dedicated image type. The printer would render values of this type as HTML img elements with embedded data using an src attribute of the form src="data:image/png;base64 ...". Registering a printer is however not very appropriate, notably because the image values are also rendered as HTML when they appear within a list for instance, and this is then pretty useless and inconvenient. I implemented another mechanism where one explicitly calls a show function to have a picture rendered in the document, and the picture is interleaved with toplevel output. The implementation is less pretty than the output though, as it relies on side effects and a call to Obj.magic... There are certainly better ways to proceed.

Let me know your opinion, and tell me if I can help in some way or another.

@XVilka
Copy link

XVilka commented Nov 23, 2020

Please also keep in mind animated images like GIF (though it's better to let it go in 2020 already!), WebP, AVIF or WebM blocks.

@yminsky
Copy link
Member

yminsky commented Nov 25, 2020

One idea I've had about this is around graphs and other visualizations. You could imagine capturing the raw data backing a graph in the text of the mdx (which can then get committed to your source repo), and then being able to convert this into a proper visualization, either in a properly equipped editor (like vscode?) or in web-output. That way, diffs that affected the data could be meaningfully viewed with an ordinary textual diff program, which could be quite useful for various kinds of number-crunching applications.

@pveber
Copy link
Author

pveber commented Nov 25, 2020

An HTML element (img or table for instance) could definitely serve that purpose, with the benefit that the syntax is already somehow part of markdown (and already understood by tools like pandoc).

@gpetiot
Copy link
Contributor

gpetiot commented Nov 27, 2020

I'm not sure it is in the scope of mdx, as mdx focuses on executable blocks, and not on rendering the graphic contents of markdown files, is it not possible to pipe mdx with another rendering tool?

@pveber
Copy link
Author

pveber commented Nov 27, 2020

😲
I'm sad I've not even once thought of that. So basically, you call a function that prints an encoding of a picture, and that part of the toplevel output is detected and transformed by an independent tool. I see no downside, and it is so much simpler (and composable) than what I've been prototyping. I'm closing the issue, thanks a lot!

@pveber pveber closed this as completed Nov 27, 2020
@NathanReb
Copy link
Contributor

I think @gpetiot is right, it feels like this is out of the scope of MDX. What we could eventually consider to make it easier to implement such an independent tool is to extract bits of MDX parsing logic into a small library. We already considered this for formatting related issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants