Re: pdfcairo terminal; seams between bars in the colorbox

[Dima K. <gn...@di...>]

Hi Ethan. Thanks for looking at this.

If possible I'd like to get the colorbox-as-bitmap logic integrated. I'm
all for filing bugs in popper and mupdf and all those, but I don't have
an understanding of what's going on there at all, or if these are even
bugs. So hopefully we can get another implementation of gnuplot colorbox
rendering we're happy with.

The patches I'm proposing are here:

  https://github.com/dkogan/gnuplot/tree/colorbox_smooth

This is the "colorbox_smooth" branch of that repo. There are several
no-op cleanup patches that consolidate duplicated logic. And one patch
to use the colorbox-as-bitmap path if term->image is available. If it's
not available we fall back to the existing implementation.

I think this works. I tested it with horizontal/vertical colorboxes and
logscales. Before/after patch behavior is the same, except for the
anti-aliasing artifacts we're trying to get rid of.

More notes inline.


Ethan A Merritt <me...@uw...> writes:

> On Sunday, 11 June 2023 16:22:01 PDT Dima Kogan wrote:

> This is already possible in current gnuplot, although to be fair it is not
> hooked up automatically to colorbox generation and maybe not well
> enough documented.   See "named_palettes.dem" for an example.
> In a nutshell:
> 1) Define your palette ("set palette ...")
> 2) Save it as a colormap ("set colormap new NAME")
> 3) Use the colormap as a pixmap
>    ("set pixmap 1 colormap NAME at screen 0.92, 0.3  size screen 0.03, 0.4")

OK. Yes. I have confirmed that this uses a bitmap for the colorbox. I'm
not sure what bearing this has. Are you saying the code that does this
should be consolidated with the new code that does the bitmap colorbox?


> However this approach has at least two limitations,
> whether done via colormap+pixmap or via your proposed new code.
> 1) Not all terminals support it

The patches above fall back on the discrete slices if term->image==NULL


> 2) It does not handle nonlinear color mappings,
>    e.g. "set log cb"

I just tested it. It looks the same before/after. The logscale affects
the tic marks on the colorbox, not the color box image.


> There is a third issue also that would apply to using it for svg or
> canvas output. See the 7th plot in heatmaps.dem. The display programs
> for these modes apply an averaging/blurring function across image
> pixels, which means that discrete palette colors would be muddied or
> mangled entirely if represented by image pixels rather than by
> separate solid color rectangles.

I don't see this. I'm looking at

  https://gnuplot.sourceforge.net/demo/heatmaps.html

The 7th plot is the last one. I don't think that's what you mean. If I
run the "headtmaps.dem" script with the current gnuplot in git (the
website should match!) I see a different sequence. The 7th one is the
one with the two images without any colorboxes at all. But they all look
right in any case.

Can you try the patches?

Thanks