[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnuplot graphics toolkit bugs

From: Ben Abbott
Subject: Re: gnuplot graphics toolkit bugs
Date: Tue, 23 Jun 2015 13:47:20 -0400

> On Jun 23, 2015, at 1:04 PM, Daniel J Sebald <address@hidden> wrote:
> On 06/23/2015 11:58 AM, Daniel J Sebald wrote:
>> On 06/23/2015 08:58 AM, Ben Abbott wrote:
>>>> On Jun 23, 2015, at 2:52 AM, Daniel J Sebald<address@hidden>
>> [snip]
>>>> https://savannah.gnu.org/bugs/?func=detailitem&item_id=43907
>>>> bug #43907: OpenGL render code called even when gnuplot is
>>>> graphics_toolkit
>>>> Dan
>>> Perhaps the most serious gnuplot 5 related bug is below. I’ve attached
>>> a patch to the bug report, but since I’m not able to build Octave 4.x
>>> on Mac OSX, I haven’t pushed it.
>>> http://savannah.gnu.org/bugs/?42838
>>> Ben
>> Well, there is a lot there for me to read, but let me just guess that
>> this is the issue where default EPS mode uses grayscale, not color. And
>> in gnuplot, the grayscale mode translates any non-white color to black,
>> technically monochrome.
> I should add, that the reason this is so significant is that approach of 
> using one terminal type EPS to create an intermediate plot that then is 
> converted to myriad file types. The changeset I noted returns to utilizing 
> all the different gnuplot terminals for various output file formats.  It 
> seems to me that is the benefit of gnuplot.
> Dan

Ok. I was responsible for using EPS as an intermediary. My thought was it would 
be easier to maintain and since gl2ps is more limited in output formats, using 
EPS as an intermediary would make the print() results more consistent for the 
different graphics toolkits. Once the code using EPS as an intermediary became 
stable, I think it was a good idea to modifying the gnuplot toolkit to support 
more output formats.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]