gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Why do we even need a "mono" option?

[<br...@ph...>]

Ethan Merritt wrote:

> I have a question about these "mono" options.
> If you send a color postscript or pdf to a mono printer, you
> get a nice grayscale plot courtesy of PostScript itself.

Whether that plot comes out nice grayscale or unreadable grayscale 
depends on a lot of unrelated things.

> Even MSword and PowerPoint offer the option to toggle 
> color/grayscale for individual imported images.

Unfortunately, the PostScript world is a lot larger and more varied than
Ghostscript, Word and PP. The primary customer class insisting on
black&white plots seem to be certain scientific journals. Those editors
apparently reject colour PostScript on sight, because they don't want
the troubles caused by different output devices rendering the same 
colour to different shades of gray.

Re: demos

[Ethan M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 12:10 pm, Daniel J Sebald  wrote:
>
> > Better yet would be to figure out a way to make all.dem itself
> > recognize and skip unsupported demos, but to my recollection past
> > discussions never came up with a reasonable way to do that.
>
> I think a function that allows executing a command without falling
> back to the command line would be nice.  Say "attempt"

Maybe, but it wouldn't actually help in the case of all.dem.
Falling back to the command line would leave you in the middle of
a sequence of now-useless commands.  What we need for the demo
case is some way of skipping the demo altogether.

Hmm.  I've got an idea that wouldn't have been possible before.

Now that we have all these GPVAL_***  variables, maybe
we should load one with the conditional compilation flags as
reported by "show version long".

gnuplot> print GPVAL_COMPILE_OPTIONS
-READLINE  +LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  
+BINARY_DATA  +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION -NOCWDRC  
+X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE 
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE


Then we could do

  if (strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE")) load "image.dem"

Anyone see anything wrong with this approach?



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Why do we even need a "mono" option?

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

Jonathan Thornburg wrote:

> In this case having gnuplot produce monochrome ps
> gives more control over just what will print than having gnuplot
> produce a color ps which some software at the publisher will then
> map to monochrome using some algorithm which I have no control over.

Which is exactly what I pointed out.

Dan

Re: Why do we even need a "mono" option?

[Jonathan T. <jt...@ae...>]

On Thu, 3 Aug 2006, Ethan Merritt wrote:
> Even MSword and PowerPoint offer the option to toggle 
> color/grayscale for individual imported images.
> 
> So why is it necessary to have two output modes from gnuplot?
> In other words, why do we even have a "mono" option in
> the first place?

I would very much want to keep the option of monochrome postscript.
I use this for figures in latex documents which I know will be printed
in monochrome.  In this case having gnuplot produce monochrome ps
gives more control over just what will print than having gnuplot
produce a color ps which some software at the publisher will then
map to monochrome using some algorithm which I have no control over.

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: Why do we even need a "mono" option?

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

Ethan Merritt wrote:
> On Thursday 03 August 2006 11:41 am, Timoth=E9e Lecomte wrote:
>=20

> So why is it necessary to have two output modes from gnuplot?
> In other words, why do we even have a "mono" option in
> the first place?

It's a reasonable question, but I think it is useful for the situation wh=
ere one sends graphics to a publisher of some sort that doesn't want colo=
r figures or plots without charging a very expensive rate.  By first conv=
erting them, as opposed to letting the publisher do that, one will know w=
hat they look like rather than having to wait perhaps until the final pro=
duct appears in print.

There are publishers who are behind the curve on electronic word processi=
ng and graphics for some reason.

Dan

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Ethan M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 12:35 pm, Timoth=E9e Lecomte wrote:
> Petr Mikulik wrote:
> > How to updated the script so that it always generates the same
> > sequence of files? I propose this for ps_header.sh:
> >
> > for i in `ls -1 *.ps | LC_ALL=3DC sort`
>
> Seems ok to me.

=46ine. =20
Anyhow, the output file, prologues.h, is only being provided
for convenience (like gnuplot.texi).  Really it should be=20
regenerated at the time a binary is built for the target
machine to ensure consistency with the source files being
used.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[<tim...@en...>]

Petr Mikulik wrote:
> How to updated the script so that it always generates the same sequence=
 of=20
> files? I propose this for ps_header.sh:
>
> for i in `ls -1 *.ps | LC_ALL=3DC sort`
>  =20
Seems ok to me.

Timoth=E9e

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Petr M. <mi...@ph...>]

>>> Looks OK to me, except that I think your patch contains a modified
>>> file prologues.h that doesn't belong in it. (It reverts iso8559-15
>>> to iso8559-1).
>>
>> It comes out from running the ps_header.sh script; and that what you
>> see is that on my system as well as for LC_ALL=C, the order is:
>> while on that somebody's system who committed it to cvs it was:
>>
>> prologue_8859_15_ps
>> prologue_8859_1_ps
>>
>> I prefer the former order.
>
> My point was that such a change has nothing to do with BlackText,
> and does not belong in the same patchset.

OK, regeneration of prologues.h is an independent action.
How to updated the script so that it always generates the same sequence of 
files? I propose this for ps_header.sh:

for i in `ls -1 *.ps | LC_ALL=C sort`

---
PM

Why do we even need a "mono" option?

[Ethan M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 11:41 am, Timoth=E9e Lecomte wrote:
> Daniel J Sebald wrote:
> >None of those other defaults are term properties.
>
> Implementing these options in the core seems reasonable, not that
> hard, and would save a lot of code duplication in the terminals.

Despite what Daniel said, these things *are* terminal properties.
The defaults cannot go into the core because they are different for
different terminals.

=46or example, I almost always use lw 2 for png and x11 output,
but lw 1 for PostScript.  Setting "dashed" for x11 produces=20
really ugly output, but it is perfectly reasonable for mono
PostScript.  =20

I have a question about these "mono" options.
If you send a color postscript or pdf to a mono printer, you
get a nice grayscale plot courtesy of PostScript itself.

Ghostscript offers the same flexibility:
  Usage: gv [OPTION]... [FILE]
  PostScript and PDF viewer.
    --monochrome    display document using only black and white
    --grayscale     display document without colors

Even MSword and PowerPoint offer the option to toggle=20
color/grayscale for individual imported images.

So why is it necessary to have two output modes from gnuplot?
In other words, why do we even have a "mono" option in
the first place?


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Ethan M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 09:35 am,  Petr Mikulik wrote:
> >
> > Looks OK to me, except that I think your patch contains a modified
> > file prologues.h that doesn't belong in it. (It reverts iso8559-15
> > to iso8559-1).
>
> It comes out from running the ps_header.sh script; and that what you
> see is that on my system as well as for LC_ALL=C, the order is:
> while on that somebody's system who committed it to cvs it was:
>
> prologue_8859_15_ps
> prologue_8859_1_ps
>
> I prefer the former order.

My point was that such a change has nothing to do with BlackText,
and does not belong in the same patchset.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: postscript monochrome and specified color

[<tim...@en...>]

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
>  =20
>>
>> If you ask for default dashed lines via "set term post dashed"
>> that doesn't stop you from explicitly drawing a solid line.
>>
>> If you ask for a small default font via "set term post font 'Times' 4"
>> that doesn't stop you from explicitly writing labels in a larger font.
>>
>> If you ask for default thick lines via 'set term post lw 5'
>> that doesn't stop you from explicitly drawing a thin line.
>>
>> So if you ask for default black lines via 'set term post mono',
>> why should it stop you from explicitly drawing a blue line?
>>    =20
>
> Because term property "monochrome" outranks other colors in the chess g=
ame of display mediums, I don't know.  None of those other defaults are t=
erm properties.
>  =20
That's where the ambiguity comes from.  As they are options to 'set=20
term', I would tend to agree with Daniel. If you ask the terminal to=20
output in monochrome, you expect everything to be in monochrome.

However, if the above options could be handled by the core, via a=20
command 'set default' for example, then Ethan's described behaviour=20
makes much more sense.

Ex : 'set default dashed font "Times,4" lw 5 mono' would not prevent=20
from override them in particular labels, lines, or whatever.

Implementing these options in the core seems reasonable, not that hard,=20
and would save a lot of code duplication in the terminals. One more=20
thing on my post-4.2 projects list.

Best regards,

Timoth=E9e

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Petr M. <mi...@ph...>]

>> The enclosed patch moves these lines into the definitions of {M}{CLR}show,
>> so that the postscript body is clean.
>>
>> (I'll commit the patch unless some negative feedback is reported.)
>
> Looks OK to me, except that I think your patch contains a modified
> file prologues.h that doesn't belong in it. (It reverts iso8559-15
> to iso8559-1).

It comes out from running the ps_header.sh script; and that what you see is 
that on my system as well as for LC_ALL=C, the order is:

prologue_8859_1_ps
prologue_8859_15_ps

while on that somebody's system who committed it to cvs it was:

prologue_8859_15_ps
prologue_8859_1_ps

I prefer the former order.

---
PM

Re: patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 08:41 am, Petr Mikulik wrote:
> 
> The enclosed patch moves these lines into the definitions of {M}{CLR}show, 
> so that the postscript body is clean.
> 
> (I'll commit the patch unless some negative feedback is reported.)

Looks OK to me, except that I think your patch contains a modified
file prologues.h that doesn't belong in it. (It reverts iso8559-15
to iso8559-1).

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

patch for Blacktext and {LCR}show -- Re: epslatex terminal spews useless output

[Petr M. <mi...@ph...>]

>> More annoying to me are all the output lines
>>  Blacktext { gsave 0 setgray } if
>>  <something>
>>  Blacktext { grestore } if

The enclosed patch moves these lines into the definitions of {M}{CLR}show, so 
that the postscript body is clean.

(I'll commit the patch unless some negative feedback is reported.)

---
PM

Re: postscript monochrome and specified color

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 03 August 2006 12:18 am, Bastian Maerkisch wrote:
> I too would prefer the 'monochrome' terminal property to cause the plot to come
> out in shades of gray only. It saves some effort to duplicate scripts when you
> want colored and monochrome versions of a plot.

Huh?  What effort?
There's a flag at the top of the PotScript output file:
  /Color true def
Just toggle the flag; no need to run your script again.
So I really don't care that much one way or the other how
the PostScript driver acts by default, because it's so easy
to change your mind later.

But the PDF output is not so easily edited.  Therefore it
is of more importance that the initial output be sensible.
If you guys are arguing that for consistency with PostScript,
"set term pdf mono" should map pm3d colors onto a gray scale,
I can see that point of view.  But up till now that has never
been coded into the pdf driver.  So it would not be a 
simple matter of changing the default; someone would have to
add new code.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: postscript monochrome and specified color

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

Petr Mikulik wrote:
>> Not 4.2 critical, and what you said is probably true.  PDF is a 
>> "standalone" sort of output in the fact that it isn't going to be 
>> imported into any other document.
> 
> 
> It is imported by people using pdf(la)tex -- useful mainly when writing 
> reports with a lot of images (the pdf files is considerably small than 
> latex -> dvips -> postscript file).

But there is ps2pdf that can be applied after that.  It wouldn't surprise me however that pdf(la)tex is smaller.  dvips doesn't create efficient files from what I recall.

Dan

Re: postscript monochrome and specified color

[Petr M. <mi...@ph...>]

> Not 4.2 critical, and what you said is probably true.  PDF is a 
> "standalone" sort of output in the fact that it isn't going to be imported 
> into any other document.

It is imported by people using pdf(la)tex -- useful mainly when writing 
reports with a lot of images (the pdf files is considerably small than latex 
-> dvips -> postscript file).


> But an EPS file, or TIFF file, might be something imported into another 
> document or sent to a journal or proceedings where color plots are not 
> allowed.

> Well, probably little.  But I think it _should_ come out as gray in 
> monochrome mode.
> I too would prefer the 'monochrome' terminal property to cause the plot to 
> come out in shades of gray only. It saves some effort to duplicate scripts 
> when you want colored and monochrome versions of a plot. In any case 
> consistency across terminals would be a good thing ;-)

I agree; it would be helpful for 4.2.

---
PM

Re: postscript monochrome and specified color

[Bastian M. <bma...@we...>]

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
>> On Wednesday 02 August 2006 11:38 pm, Daniel J Sebald wrote:
>>
>>> I programmed "with rgbimage" to come out as gray when postscript 
>>> monochrome property is active. 
>>
>> It may be too late to change it now.
>> How much work would it be?
> 
> Well, probably little.  But I think it _should_ come out as gray in monochrome mode.

I too would prefer the 'monochrome' terminal property to cause the plot to come
out in shades of gray only. It saves some effort to duplicate scripts when you
want colored and monochrome versions of a plot.
In any case consistency across terminals would be a good thing ;-)

Bastian

Re: postscript monochrome and specified color

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

Ethan A Merritt wrote:
> On Wednesday 02 August 2006 11:38 pm, Daniel J Sebald wrote:
> 
>>I programmed "with rgbimage" to come out as gray when postscript 
>>monochrome property is active. 
> 
> 
> It may be too late to change it now.
> How much work would it be?

Well, probably little.  But I think it _should_ come out as gray in monochrome mode.

Dan

Re: postscript monochrome and specified color

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

Ethan A Merritt wrote:
>>Not only is the PDF file not monochrome, in addition to the line being red, the borders are red.
> 
> The "monochrome" option to pdf seems never to have been
> implemented fully. It doesn't actually *do* anything.
> It just *doesn't* change the linetype.

It should do something.  Regular color mode would be better than the colored borders.


>  So in mono mode, whatever linetype
> you have is stuck forever.  At the least, setting "mono" should also
> select "dashed" so you can tell the lines apart.

Right.


> So this one may not be fixable for 4.2, although I suppose I can at
> least patch it to set the line color back to black.
> 
> Obviously no one is using PDF in mono mode, or this would have
> been noticed a long time ago.

Not 4.2 critical, and what you said is probably true.  PDF is a "standalone" sort of output in the fact that it isn't going to be imported into any other document.  If one outputs in color, fine, because the PDF viewer can deal with that.

But an EPS file, or TIFF file, might be something imported into another document or sent to a journal or proceedings where color plots are not allowed.

Dan

Re: postscript monochrome and specified color

[Petr M. <mi...@ph...>]

> I programmed "with rgbimage" to come out as gray when postscript
> monochrome property is active.

The same is true for plots "with palette" options, as the palette fallbacks 
into grayish in the monochrome postscript file.

---
PM

Re: postscript monochrome and specified color

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 02 August 2006 11:38 pm, Daniel J Sebald wrote:
> 
> I programmed "with rgbimage" to come out as gray when postscript 
> monochrome property is active. 

It may be too late to change it now.
How much work would it be?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: postscript monochrome and specified color

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 02 August 2006 11:32 pm, Daniel J Sebald wrote:
> gnuplot> set term pdf monochrome
> Terminal type set to 'pdf'
> Options are 'monochrome noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0  '
> gnuplot> set output 'foo2.pdf'
> gnuplot> plot x lc rgb "red"
> 
> Not only is the PDF file not monochrome, in addition to the line being red, the borders are red.

Dang. That was Bug #1517932.  I thought I fixed that one already.

grumble, grumble.

Wait a minute.  

The "monochrome" option to pdf seems never to have been
implemented fully. It doesn't actually *do* anything.
It just *doesn't* change the linetype.  So in mono mode, whatever linetype
you have is stuck forever.  At the least, setting "mono" should also
select "dashed" so you can tell the lines apart.  But it doesn't,
perhaps because "dashed" is itself not supported by all versions of
PDFlib.

So this one may not be fixable for 4.2, although I suppose I can at
least patch it to set the line color back to black.

Obviously no one is using PDF in mono mode, or this would have
been noticed a long time ago.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: postscript monochrome and specified color

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

Ethan A Merritt wrote:
> On Wednesday 02 August 2006 11:05 pm, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>You ask for blue, you get blue.  
>>>If you don't want blue, don't ask for blue.
>>
>>But I asked for monochrome too.  Why can't I have that instead?
> 
> 
> If you ask for default dashed lines via "set term post dashed"
> that doesn't stop you from explicitly drawing a solid line.
> 
> If you ask for a small default font via "set term post font 'Times' 4"
> that doesn't stop you from explicitly writing labels in a larger font.
> 
> If you ask for default thick lines via 'set term post lw 5'
> that doesn't stop you from explicitly drawing a thin line.
> 
> So if you ask for default black lines via 'set term post mono',
> why should it stop you from explicitly drawing a blue line?

Because term property "monochrome" outranks other colors in the chess game of display mediums, I don't know.  None of those other defaults are term properties.  If there were a term property "nosolidlines" I would expect to not be able to draw any solid lines.

I programmed "with rgbimage" to come out as gray when postscript monochrome property is active.

Dan

Re: postscript monochrome and specified color

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

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> 
>>On Wednesday 02 August 2006 10:45 pm, Daniel J Sebald wrote:
>>
>>
>>>set term postscript monochrome eps
>>>plot x with points lc rgb "blue"
>>>
>>>will produce a plot that still has blue points.
>>
>>
>>You ask for blue, you get blue.  
>>If you don't want blue, don't ask for blue.
> 
> 
> But I asked for monochrome too.  Why can't I have that instead?


And now in PDF things are doubly problematic:

gnuplot> plot x
gnuplot> set term pdf
Terminal type set to 'pdf'
Options are ' noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0  '
gnuplot> set output 'foo.pdf'
gnuplot> replot
gnuplot> set output

OK, as expected, red line, black borders.  Now:

gnuplot> set term pdf monochrome
Terminal type set to 'pdf'
Options are 'monochrome noenhanced fname 'Helvetica'  fsize 6 linewidth 1.0  '
gnuplot> set output 'foo2.pdf'
gnuplot> plot x lc rgb "red"
gnuplot> set output

Not only is the PDF file not monochrome, in addition to the line being red, the borders are red.

Dan