gnuplot-beta

octave w/ gnuplot backend produces bad pdf

[Dmitri A. S. <das...@gm...>]

The following octave scrip produces a bad pdf
(similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )

graphics_toolkit ("gnuplot")
x=linspace(-1,1,11);
y=0;
z=x;
mesh(x,y,z);
colormap([0,0,0]);
print("bad_pdf.pdf", "-dpdfcairo")

====

A gnuplot script tat demonstrates the problem is attached (it contains
binary data).

Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
would not.

I suspect the problem with octave's
colormap([0,0,0])
command here.
But I also think that gnuplot should not produce bad pdf.

Dmitri.
--

Re: octave w/ gnuplot backend produces bad pdf

[Daniel J S. <dan...@ie...>]

My observations after modifying some lines of your .gp file:

1) The pngcairo terminal appears to work with your example.  I see a 
black line for all segments and the colorbox is all black.  This is how 
it appears in the PNG file and Qt terminal.

2) The attached modification "fixes" the pdfcairo view problems.  What I 
did was add more levels to the colorbox so that grey and white are 
visible.  I then see one segment of the line in black and another 
segment of the line in white.  This is how it appears in the PDF file 
and Qt terminal.

So, it appears that there is either a Cairo bug or something is wrong in 
gnuplot (probably colorbar) when the number of color levels is 1.

Dan


On 05/31/2016 03:03 PM, Dmitri A. Sergatskov wrote:
> The following octave scrip produces a bad pdf
> (similar to one in https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
>
> graphics_toolkit ("gnuplot")
> x=linspace(-1,1,11);
> y=0;
> z=x;
> mesh(x,y,z);
> colormap([0,0,0]);
> print("bad_pdf.pdf", "-dpdfcairo")
>
> ====
>
> A gnuplot script tat demonstrates the problem is attached (it contains
> binary data).
>
> Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> would not.
>
> I suspect the problem with octave's
> colormap([0,0,0])
> command here.
> But I also think that gnuplot should not produce bad pdf.
>
> Dmitri.
> --
>
>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: octave w/ gnuplot backend produces bad pdf

[Dmitri A. S. <das...@gm...>]

On Tue, May 31, 2016 at 4:35 PM, Daniel J Sebald <dan...@ie...>
wrote:

>
> So, it appears that there is either a Cairo bug or something is wrong in
> gnuplot (probably colorbar) when the number of color levels is 1.
>
>
​If you change colormap command to
​colormap([0,0,0;0,0,0])
it would work fine. But it is still one color level, isn't it?



> Dan
>
>
>
​Dmitri.
-- 
​

Re: octave w/ gnuplot backend produces bad pdf

[sfeam <sf...@us...>]

On Tuesday, 31 May 2016 03:03:51 PM Dmitri A. Sergatskov wrote:
> The following octave scrip produces a bad pdf
> (similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
> 
> graphics_toolkit ("gnuplot")
> x=linspace(-1,1,11);
> y=0;
> z=x;
> mesh(x,y,z);
> colormap([0,0,0]);
> print("bad_pdf.pdf", "-dpdfcairo")
> 
> ====
> 
> A gnuplot script tat demonstrates the problem is attached (it contains
> binary data).
> 
> Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> would not.
> 
> I suspect the problem with octave's
> colormap([0,0,0])
> command here.
> But I also think that gnuplot should not produce bad pdf.

I have not yet looked in detail, but my first thought is that the gnuplot command
	set palette ... maxcolors 1
is a nonsense command.   A palette with only one color is no palette at all.

I could understand a general case script that sometimes reduced to a
degenerate palette for which the endpoint colors were the same. 
This would correspond to gnuplot commands
      set palette defined (0 "black", 1 "black")
But in this case I expect the "maxcolors" parameter would still be 
0 (continuous interpolation) or 256 or whatever. 

	Ethan

Re: octave w/ gnuplot backend produces bad pdf

[sfeam <sf...@us...>]

On Tuesday, 31 May 2016 03:11:44 PM sfeam wrote:
> On Tuesday, 31 May 2016 03:03:51 PM Dmitri A. Sergatskov wrote:
> > The following octave scrip produces a bad pdf
> > (similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
> > 
> > graphics_toolkit ("gnuplot")
> > x=linspace(-1,1,11);
> > y=0;
> > z=x;
> > mesh(x,y,z);
> > colormap([0,0,0]);
> > print("bad_pdf.pdf", "-dpdfcairo")
> > 
> > ====
> > 
> > A gnuplot script tat demonstrates the problem is attached (it contains
> > binary data).
> > 
> > Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> > would not.
> > 
> > I suspect the problem with octave's
> > colormap([0,0,0])
> > command here.
> > But I also think that gnuplot should not produce bad pdf.
> 
> I have not yet looked in detail, but my first thought is that the gnuplot command
> 	set palette ... maxcolors 1
> is a nonsense command.   A palette with only one color is no palette at all.

....and it's never going to work because of code like this:

   color.c:152    gray = (double) i / (sm_palette.colors - 1);    /* rescale to [0;1] */

and the equivalent is hard-wired into the PostScript palette code:

   /pm3dround {maxcolors 0 gt {dup 1 ge
        {pop 1} {maxcolors mul floor maxcolors 1 sub div} ifelse} if} def

So no.  maxcolors = 1 is not a legal value.

	Ethan