Re: pdfcairo terminal; seams between bars in the colorbox

[Ethan A M. <me...@uw...>]

On Wednesday, 14 June 2023 10:43:26 PDT Dima Kogan wrote:
> 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

I do not know how to generate the relevant patches via github.
It says:  "master and colorbox_smooth are entirely different commit histories"
Could you please send me the relevant patch series as generated by
"git format-patch"?
  
> > 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?

Mostly I meant that the good/bad effects of this approach can be tested
using the code already there.  

> > 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

OK.  The other alternative is to make this specific to cairopdf.
Unless you know of other terminals that suffer from the same problem?

> > 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.

You are right.  I was thinking of something else, but never mind.

> > 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

That is the png version; it doesn't show the effect I'm talking about.
Have a look at the svg version
    https://gnuplot.sourceforge.net/demo_svg/heatmaps.html

In particular the plot with title
    Compare "image" and "image pixels"

> Can you try the patches?

If you send them as patches, yeah.
Or upload them to the patch tracker
    https://sourceforge.net/p/gnuplot/patches/

	Ethan