Re: pdfcairo terminal; seams between bars in the colorbox

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

On Sunday, 11 June 2023 16:22:01 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > I may not understand what you are suggesting.
> 
> Hi. I guess I wasn't clear. The suggestion was that instead of creating
> 128 discrete bars with different colors we create a 128x1 bitmap and
> draw it as an image. The thought was that this would work because images
> look correct in pdfcairo, without the ugly border lines.

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

Because it is not hooked up automatically to colorbox generation,
you would have to position the pixmap on top of the colorbox.
I admit that would be a nuisance.  Maybe you would like to look into
adding it as a colorbox option?

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
2) It does not handle nonlinear color mappings,
   e.g. "set log cb"

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.

For these reasons I do not think this approach is suitable as
a replacement for the current colorbox code.

On the other hand if you can figure out some change to the
cairo + pdf pathway that avoids triggering bugs in poppler or
other external pdf-handling programs, that would be a good thing.
Of course fixing or at least filing bug reports for those
external programs would also be a good thing.

    Ethan

> 
> I implemented this in the attached patch, and it works and looks good. I
> tried several gnuplot terminals (x11, qt, wxt, pdfcairo, png, svg), and
> it looks like it works there too. I haven't found anything that this
> breaks. The script I used to test:
> 
>   plot 'demo/blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage, 5 with points palette
> 
> I don't understand the gnuplot codebase deeply, so I might have missed
> things. Some questions:
> 
> - I patched draw_inside_colorbox_bitmap_smooth() only. There are other
>   flavors of this function (look where it is called), and I don't know
>   if the others should be updated in this way as well
> 
> - I have an extra "gray = 1 - gray;" that I don't understand. It makes
>   things correct, though
> 
> - The patch uses rgb unconditionally. I that going to break something in
>   some terminal?
> 
> - I copied most of the logic from the old function without an
>   understanding of what it does. Am I handling these properly?
> 
>     - sm_palette.use_maxcolors
>     - sm_palette.gradient_num
>     - sm_palette.positive
> 
> - If I "set colorbox horizontal" then the colorbox stays in the same
>   spot with the same shape, but I change the color sequence to move
>   horizontally. This happens even before my patch. I'm here:
> 
>     ae7dfa3f3..: Ethan A Merritt 2023-06-09 qt:  qt4 was apparently weak at int->double promotion
> 
>   Shouldn't the colorbox move below or above the plot, and reorient
>   itself? Or is it the user's job to set the geometry?
> 
> This makes my PDFs look nice. It'd be good if some version of this patch
> was merged.
> 
> Thanks
>