#558 Add an option to workaround the colorbox rendering issue in pdfcairo terminal on MacOS

[Hiroki Motoyoshi]

The commit '[391723] smooth colorbox rendered as an image - revised logic' has improved colorbox rendering. I think it effectively eliminates artifacts between adjacent colors in a colorbox.

However, this improvement also created a problem for MacOS users who use the pdfcairo terminal.
The attached file "test.pdf" is the output of the following sample script.

set terminal pdfcairo
set output "test.pdf"

set view map
set yrange [0:6]
set isosample 7
set samples 2

set palette viridis maxcolors 6
set cbrange [0:6]

splot y with pm3d

The maxcolors 6 option is specified for the set palette to represent the colorbox with six colors.

The attached files "Fig1.jpg" and "Fig2.jpg" are screenshots of Adobe Acrobat Reader and Preview (the standard viewer on MacOS), respectively. "Fig1.jpg" shows the correct representation, but in "Fig2.jpg", the colorbox is somehow represented continuously, which is not what was intended.

If this is a problem with Preview only, we can use a different viewer. However, there is a problem that the same behavior occurs when PDFs are pasted into applications such as Keynote, PowerPoint, and Word, which is a rather deep-seated problem.

This phenomenon is caused by the behavior of the MacOS PDF rendering engine, which forces smoothing on the image. However, there is no way to remove this smoothing. This is a long lasting problem in PDF handling of MacOS and this situation will not change in the future...

My request is to add an option to access the colorbox rendering method prior to the commit as a workaround for MacOS users. This situation is the same as needing the pixels option (or failsafe) for with image on MacOS (see "help image pixels").

I would be pleased if you would consider this.

[Ethan Merritt]

I think it is not reasonable to add special options to gnuplot just because one particular pdf viewer is buggy, particularly since it is on top of another special case variant added to work around other buggy pdf viewers. It won't stop people from running into the bad viewers and asking for help or filing a bug report on gnuplot. Would it not make more sense to limit the gradient-fill colorbox treatment to palettes with more than N colors, where N is some reasonably small number like 10 or 20?

[Hiroki Motoyoshi]

Thank you for your response.

In principle, I think you are correct. But the issue I am talking is not just about the Viewer, which is why I wrote "workaround" for MacOS Users, not for Preview Users.

Almost all software that uses MacOS's core PDF rendering engine to display PDF components is affected; Keynote, PowerPoint, Word, and other tools display the same way. Adobe Acrobat Reader, for example, which has its own rendering engine, can display the image correctly.

The 'images' style has the same problem but can be avoided using the "pixels" option. However, the upcoming release has no workaround for the colorbox problem.

To make do for the time being, I have written a private patch that introduces a configure option that, in effect, cancels the commit of [391723] only on pdfcairo, epscairo, cairolatex terminal.

If we are going to actually implement this, we need a more flexible approach.

[Ethan Merritt]

That makes little sense to me - it would cancel the new colorbox code on exactly the terminals it was added to improve. I would revert [391723] altogether rather than do that.

However it also seems to me that this is really is not our problem to fix. The same problem would hit those same programs on MacOS when viewing or embedding PDF files generated by other programs or on other platforms. Here's a relevant blog post/rant: https://www.userlandia.com/home/2021/11/the-mystery-of-mac-os-mangled-image-interpolation-implementation

So as I understand it, using scaled pixels rather than little boxes makes things worse on MacOS while making things better on [all] other platforms. Instead of introducing additional complexity we could just wrap the change in #ifndef __APPLE__

diff --git a/src/color.c b/src/color.c
index 67b7c296e..90267b0a3 100644
--- a/src/color.c
+++ b/src/color.c
@@ -618,9 +618,11 @@ draw_inside_colorbox_bitmap_smooth()
      * FIXME: if this causes problems for other terminal types we can
      *        switch the condition to if (!strcmp(term->name,"pdfcairo"))
      */
+#ifndef __APPLE__
     if ((term->flags & TERM_COLORBOX_IMAGE))
         draw_inside_colorbox_bitmap_smooth__image();
     else
+#endif
         draw_inside_colorbox_bitmap_smooth__filled_polygon();
 }

But that still means gnuplot images generated elsewhere but viewed on MacOS would be incorrectly blurred. From that perspective a cross-platform fix that doesn't require either special configuration or platform-specific changes would be better. So I'm still thinking that this would be a better change to consider:

diff --git a/src/color.c b/src/color.c
index 67b7c296e..ef52f9dbd 100644
--- a/src/color.c
+++ b/src/color.c
@@ -615,10 +615,9 @@ draw_inside_colorbox_bitmap_smooth()
 {
     /* The primary beneficiary of the image variant is cairo + pdf,
      * since it avoids banding artifacts in the filled_polygon variant.
-     * FIXME: if this causes problems for other terminal types we can
-     *        switch the condition to if (!strcmp(term->name,"pdfcairo"))
      */
-    if ((term->flags & TERM_COLORBOX_IMAGE))
+    if (((term->flags & TERM_COLORBOX_IMAGE))
+    &&  (sm_palette.use_maxcolors <= 0 || sm_palette.use_maxcolors > 20)) 
         draw_inside_colorbox_bitmap_smooth__image();
     else
         draw_inside_colorbox_bitmap_smooth__filled_polygon();

[Hiroki Motoyoshi]

Thank you for taking the time to stop and consider this issue.

Based on the information you provided, I have come up with one crossplatform modification. The outline is as follows.

---

• As it is now, adopt the method of rendering colorbox as image.
• Only if maxcolors is given, oversample steps by a multiple of maxcolors so that steps is around 1000.
• Since we are only embedding image data (1000x1 pixels), there should be no performance impact due to oversampling.

---

Attached is a patch file, a script for checking, and a PDF of the output.

The row number of pixels will increase, but the representation as an image will be the same by making steps a multiple of maxcolors. Although oversampling is just a wasted effort for the right viewers, PDFs created on other platforms will be correctly displayed on MacOS. On Preview or Applications on MacOS, the boundaries between colors are slightly blurred, but the colorbox representation is correct (discrete colors).

I understand the frustration of conforming to MacOS's specifications, but what do you think about this proposal as a compromise?