On 7/8/2026 12:21 PM, Florent Michel wrote:
Hi Hans,
To be honest, I can't think of a use-case that would justify the work of
implementing these shadings if they are not already there. I am not able
to share the specific example I'm working on, but the idea is to draw a
surface plot with neater interpolation than, say, a linear shading can
provide with a relatively small number of patches (see the example ‘A
Coons patch’ for an example with a single patch https://tikz.dev/
pgfplots/libs-patchplots <https://tikz.dev/pgfplots/libs-patchplots>).
Nothing that can't be achieved with existing tools, though, e.g.
MetaPost with linear / radial shadings and a finer sub-division in patches.
I gave it some thought (again) but didn't change my view on these matters:
- this kind of meshing is normally the result of some function driven
rendering
- so you end up with many e.g. triangles, say thousands or even tens of
thousands
- which is why there is that complex approach of 1-32 bit integers,
colors etc
- putting paths on the "with" specification makes little sense because
one already have a path and that onw can be segmented so basically one
only needs color specs on top of that then
Basically these shading mechanisms are there to accomodate some
applications. So:
- starting from the spec to come up with some interface makes little sense
- no one is going to enter 5000 * n "withsomething" specifiers which is
inefficient and likely generated anyway
- so we're basically function driven
- which means that there are functions behind the mesh as well as coloring
- which eventually in the viewer results in a bitmap
Also:
- if we implement this basically we generate some huge specification in
order to come up with some bitmap in the end ... pdf bloat
- we're not talking 3D animation-in-pdf which btw is also kind of messy
and why would one use pdf for that anyway
That said:
- it makes very little sense to waste time on this and and ugly code to
the codebase
- if you have a specific use case we can see if we can already handle it
by using different mechanisms present in luametafun
- showing off that we can support every pdf features makes little sense
(no one pays for that anyway)
- not the pdf spec is the starting point but what users need is
And for the rare cases one needs this, using some real advanced
application and exporting makes more sense.
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : [email protected] /
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
