Description

The Django template system is able to process any kind of text document, including SVG.

But the standard filter provided by Django are mostly "text" oriented, and does not provide basic "mathematical" operations often required by SVG template authors.

Specifically, it appears that when producing SVG chart for example, one require often to scale from model data range to chart axis. With the added complexity that SVG y-axis grows downward -- whereas many charts y-axis grow upward. For now, the only solution is (a) to perform the scaling in the view, which throws out the separation of concern or (b) preferably, provide a custom filter.

Since I think this is a common pattern while producing SVG, it could be interesting to provide a standard "scaling" filter. Here is what I propose (a patch is attached):

As stated in the comment, this is modeled after the corresponding Processing map() function, since our designer was more familiar with that language. Maybe, "scale()" could be less confusing for Python-aware people.

While django's template language can be used to render any text-based format, its builtin library of tags and filters is heavily biased towards outputting HTML.

Seeing how it's relatively easy to create a third-party application that defines custom template tags/filters, could you provide some more arguments as to why it makes sense to include this new template filter in django's core? Your current usecase seems quite specific and I find it hard to see how it could be useful in a more generic context.

We currently have the widthratio tag [1] that does something similar to what you're proposing. Could you address its shortcomings and the reasons why it doesn't fit your needs?

Personally, I'm -1 on this feature. While it's probably useful, I think it'd be better if it lived in a third-party application.

Also note that for a new feature to get merged, it needs to have tests and documentation. See the contributing guide [2] for more info.

I saw the 'widthratio' but I couldn't manage to use it to do what we need, as it assume both original and destination scale both have 0 for origin. In our particular case, that wasn't almost never the case. As an example, while drawing a line chart, we have to map temperature in the -55°C +125°C range to some vertical axis whose origin is not at "0px" (to gets things worse, (0,0) is the top-left of an SVG drawing).

As a matter of fact, it could be a better idea to extend "widthratio" to accept both 3 arguments as today, or 5:

{% widthratio value min_value max_value min_rang max_range %}

But, as you mention, maybe we are the only one using the Django template system to generate SVG? And having that specific need? I was thinking with the advent of HTML5 this could be a more common use case. But as for today you are probably right.