octave w/ gnuplot backend produces bad pdf

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

octave w/ gnuplot backend produces bad pdf

Dmitri A. Sergatskov
The following octave scrip produces a bad pdf

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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

bad_gp.gp (984 bytes) Download Attachment
bad_pdf.pdf (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: octave w/ gnuplot backend produces bad pdf

Daniel J Sebald
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
> [hidden email]
> 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

------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

bad_gp_mod.gp (904 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: octave w/ gnuplot backend produces bad pdf

Dmitri A. Sergatskov


On Tue, May 31, 2016 at 4:35 PM, Daniel J Sebald <[hidden email]> 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.
--



------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: octave w/ gnuplot backend produces bad pdf

sfeam
In reply to this post by Dmitri A. Sergatskov
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



------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: octave w/ gnuplot backend produces bad pdf

sfeam
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



------------------------------------------------------------------------------
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
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Loading...