|
From: Ethan A M. <me...@uw...> - 2023-06-10 23:14:22
|
It is likely that the artefact is due to the viewing program rather than being intrinsic to the pdf file output by gnuplot. I see no such effect when viewing with the current version of okular, although at various times in the past I have found that toggling anti-alias in the viewer settings can make a difference in some cases. "gv" used to be quite bad in this regard but has improved since then. The quadrangles making up a pm3d surface can have the same, or similar, problem. That was mitigated by adding an option "set pm3d border retrace", which can reduce or remove this artifact for solid fill areas at the cost of introducing a "phantom grid" artifact for semi-transparent fill areas. I do not remember at the moment if a similar treatment was added, or could be added, to the quadrangles making up the color box. On Sat, Jun 10, 2023 at 12:56 PM Dima Kogan <gn...@di...> wrote: > > !-------------------------------------------------------------------| > This Message Is From an Untrusted Sender > You have not previously corresponded with this sender. > See https://itconnect.uw.edu/email-tags for additional > information. Please contact the UW-IT Service Center, > he...@uw... 206.221.5000, for assistance. > |-------------------------------------------------------------------! > > Hi. I'm seeing ugly lines between the bars in the colorbox when making > .pdf files. Trivial plot to demo this: > > set terminal pdf > set output "/tmp/tst.pdf" > plot 5 with points palette > > This isn't a new issue, and I was wondering if anybody here had insight > about fixing it. > > gp_cairo.c says this: > > /* By default, Cairo uses an antialiasing algorithm which may > * leave a seam between polygons which share a common edge. > * Several solutions allow to workaround this behaviour : > * - don't antialias the polygons > * Problem : aliased lines are ugly > * - stroke on each edge > * Problem : stroking is a very time-consuming operation > * - draw without antialiasing to a separate context of a bigger size > * Problem : not really in the spirit of the rest of the drawing. > * - enlarge the polygons so that they overlap slightly > * Problem : It is really more time-consuming that it may seem. > * It implies inspecting each corner to find which direction to move it > * (making the difference between the inside and the outside of the polygon). > * - using CAIRO_OPERATOR_SATURATE > * Problem : for each set of polygons, we have to draw front-to-back > * on a separate context and then copy back to this one. > * Time-consuming but probably less than stroking all the edges. > * > * The last solution is implemented if plot->polygons_saturate is set to TRUE > * Otherwise the default (antialiasing but may have seams) is used. > */ > > And the gnuplot code today already does the "enlarge the polygons so > that they overlap slightly" thing. color.c has: > > draw_inside_colorbox_bitmap_smooth() { > ... > for (i = 0, xy2 = xy_from; i < steps; i++) { > > xy = xy2; > xy2 = xy_from + (int) (xy_step * (i + 1)); > > ... > if (color_box.rotation == 'v') { > corners[0].y = corners[1].y = xy; > corners[2].y = corners[3].y = GPMIN(xy_to,xy2+1); > } else { > corners[0].x = corners[3].x = xy; > corners[1].x = corners[2].x = GPMIN(xy_to,xy2+1); > } > ... > } > > Note the "+1". I still see the ugly bars in the resulting .pdf file > though. I can run experiments, but before I do anything, does anybody > have a comment? The draw_inside_colorbox_bitmap_smooth() stuff changed > in 2020, so maybe looking deeper at the effects of that patch would be > an interesting thing to do. > > Thanks > > > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!gvmIXc1ZjdPjHB_McnIXjBk792CcUxJIsyISfkYLL-khZyZZpKxIltBsw8-8FEqW9sKJr2ZQwh0CDRgiIi_iCkB-blo_0w$ -- Ethan A Merritt Department of Biochemistry University of Washington, Seattle |