Title says it all.

I would like to add a few suggestions/elaborations for this feature:

1. Showing variants of a recipe in a gif. e.g. if the craft uses the tag #minecraft:planks, then the gif should cycle through each of the plank variants. Example.
2. If an item can be smelted from both a furnace and a smoker, or a furnace and a blast furnace, then the gif should alternate between each one. Example.
3. If an item is created from smelting, blasting, or smoking, then animate the fuel and progress bar (ideally, both would be in-sync, as currently in the UI they are out of sync)
4. Group several related recipes together and create a single gif switching between each of them. Example.

All the example gifs are from a project of mine, and are set to exactly 1 fps, with each state is a single frame (however, for the smelting animation, significantly more frames will be required). This avoids useless/redundant frames, and keeps the size of the gif low. The ones linked are 75.6kB, 19.0kB, and 8.6kB respectively, at a resolution of 480x272.

Additionally to solo's suggestions, if the screenshot / gif could be copied to clipboard after pressing the button that'd be amazing.

Also, being able to output webp or (less importantly) apng and mp4 would be epic and cool (that way those formats could be generated directly without having to first generate a gif, which is lossy)

That seems like a bit much, sounds like adding a ton of different formats will just bloat the mod and steer it away from its purpose.

Fair, but the addition of at least webp, or the ability to output each individual frame (which can then later be re-encoded by ffmpeg) (named filename/frame1.png, filename/frame2.png, etc.) would be nice, to avoid some of the restrictions of the gif format.

Understood, I figured it'd be a bit difficult to implement.

In general this suggestion is pretty unimplementable. There are no generic systems (and it would be bloat to add them) to determine looping points for animations on widgets (progress arrows and burning fire shouldn't cut off), and rendering recipes with cycling ingredients kinda defeats the whole point of EMI's display systems. There could be pretty ridiculous frame creep with multiplicative loop time stacking.

I want to leave the bug open because maybe I'll change my mind and prioritize this, but as it stands there are serious technical and presentation based blockers that I don't anticipate being resolved, past the obligatory formatting bikeshed.

In a tangential and partially overlapping feature area, I have considered the ability to export EMI data to a static web format, most likely in the form of a collection of understyled html files that would have some of EMI's features like lookup but more importantly tooltip support for collective representation ingredients like tags. This may contain some of the desires for this feature, it may not, but I thought it'd be worth bringing up regardless as something that is more viable and has been considered.

I've decided this is not feasible to implement so I will be closing the issue.

oh well, I mean I can't blame you lol, it sounds complicated™ to implement