Re: pdfcairo terminal; seams between bars in the colorbox

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

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.

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