Page MenuHomePhabricator

Dynamically generate files with Scribunto
Open, LowPublicFeature

Description

Currently, we have modules that create pie charts by stacking divs with very thick, differently-colored borders, as well as ones that do even crazier things. Perhaps Scribunto should be given a {{#invokefile:foo|bar}} syntax (or something), where the output returned by the module is treated as contents of an image (or in theory, even other types of files, such as audio). Primarily, I see this being used to make SVGs, as a replacement for the HTML hacks used to create "images" today. We can already have dynamic file generation with Extension:Math, so it should be feasible to do with Scribunto as well.

Details

Reference
bz64460

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:23 AM
bzimport added a project: Scribunto.
bzimport set Reference to bz64460.
bzimport added a subscriber: Unknown Object (MLST).

Change 113759 had a related patch set uploaded by Jackmcbarn:
Support for modules-as-images

https://gerrit.wikimedia.org/r/113759

This could also replace EasyTimeline, see bug 27156, bug 60263, bug 35320.

The reason I used the [[File:Module:XXX]] syntax for the prototype, is, that it enables these scripts to be used whereever images can currently be used. It was important to me that it worked with Extension:ImageMap, since that is necessary if we want to replace EasyTimeline.

I have another implementation strategy idea. We could let the module generate iframe data that would be embedded by base64'ing it. Since iframes do not allow scripting per default (http://www.w3.org/TR/html5/webappapis.html#sandboxScriptBlocked) and the data would not be linkable, this would allow for manually made image-maps in SVG's but still retain security. Old browsers that run scripts in iframes per default, would need mitigation. The format of code in the module could be the same as my previous patch, but a new parser function would be needed. What do you think?

MediaWiki-extensions-Graph should now cover most use cases. However, any imperative language is still a breath of air compared to Vega's declarative syntax.

I think we should reject this task, because Lua can already generate <graph>...</graph> chart -- that's what Template:Graph:Chart actually does, or, better yet, use one of the templates like Pie from row or Line chart to plot data directly from a dataset table on Commons.

There are more to files than just graphs.

@Anomie of course, but we should be very clear about listing the usecases that cannot be currently solved in any other way.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:13 AM

Why don't you enable inline SVG, which can be generated by whatever mechanism that is available in MediaWiki, including Scribunto, templates or parser functions?

This extension might help.

https://gerrit.wikimedia.org/r/113759

Now that graphs are no more, is there any interest in reviving the patch? Making pie charts, bar graphs etc are already possible by generating the HTML and inline styles through lua. I'm not familiar with SVGs - is there an advantage to using it instead?

https://gerrit.wikimedia.org/r/113759

Now that graphs are no more,

There are still several extensions able to display graphs; see the list. At least for one of them, the graph (not only .dot) code can be generated dynamically, by a template or a module, and the resulting SVG code is injected into the page.

is there any interest in reviving the patch? Making pie charts, bar graphs etc are already possible by generating the HTML and inline styles through lua.

The way that Module:Chart renders pie charts, using only HTML, CSS and a single SVG circle drawing, is very ingenuous; but I think that this approach is stretched to its limits. SVG would offer more powerful and less esoteric, but, as far I understand, one cannot inject SVG with modules.

There are still several extensions able to display graphs; see the list. At least for one of them,

Yes but none of them are deployed on Wikimedia wikis.

Removing subtask as the dynamically generated SVG can be server-rendered. It doesn't need to render on the client and so doesn't need any more validation than we do today.