RE: print ('-depslatexstandalone', 'test.tex') now prints dashed line s?

[Schirmacher, Rolf]

> -----Original Message-----
> From: John W. Eaton [mailto:address@hidden
> Sent: Friday, October 26, 2007 5:19 PM
> To: Schirmacher, Rolf
> Cc: 'address@hidden'
> Subject: print ('-depslatexstandalone', 'test.tex') now prints dashed
> line s?
> 
> 
> On 26-Oct-2007, Schirmacher, Rolf wrote:
> 
> | I found some strange behaviour of the print command with the gnuplot
> | backend, which seems to have changed with 2.9.15:
> | If I have a "standard" plot with solid coloured lines and I 
> do the above
> | mentioned
> | 
> | print ('-depslatexstandalone', 'test.tex') 
> | 
> | I get a plot with coloured, dashed lines.
> | The reason is that the current print.m sets the 
> "new_terminal" string to
> | 
> | new_terminal = epslatex standalone mono dashed
> | 
> | So, we have two issues here: Although mono is specified in 
> the terminal
> | string, coloured eps is produced (that is probably on the 
> gnuplot side) and
> | the logic for the postscript terminal settings prefers to 
> go to "mono
> | dashed" unless otherwise specified. The current logic is
> | 
> |     if (any (dev == "c") || use_color > 0)
> |       if (force_solid < 0)
> |     options = strcat (options, "color dashed ");
> |       else
> |     options = strcat (options, "color solid ");
> |       endif
> |     else
> |       if (force_solid > 0)
> |     options = strcat (options, "mono solid ");
> |       else
> |     options = strcat (options, "mono dashed ");
> |       endif
> |     endif
> | 
> | that is, unless the device name contains a "c" or color is 
> explicitly asked
> | for, it assumes mono which defaults to dashed unless solid 
> is specified. As
> | epslatex and other likewise terminals / devices are 
> typically used for file
> | output (and post-production) these days and the default 
> plots of octave are
> | coloured anyway, I would propose to change the behaviour 
> here to default to
> | colour solid output. Integrating a "c" in the name of the 
> devices seems to
> | be wired and the postscript produced is coloured anyway, as 
> mentioned above.
> 
> What is the Matlab compatible behavior?  I think we should aim for
> that.  But it may not be completely possible with the current gnuplot
> which seems to have some inconsistencies with linestyles for various
> terminal/output drivers.
> 
> It would be great to have a patch for this because I have no clue how
> to make this work properly.
> 
> jwe
> 

Ok, now, Matlab offers a -deps and a -depsc device (among other ps devices).
-deps plots black&white, i.e. all colors get black for simple line plots and
no dashes. -depsc plots with colors, again no dashes. There are no "latex"
devices within Matlab.

In octave, there are the "latex" devices, but no epsclatexstandalone, only
epslatexstandalone.
For comparison, -deps gives a coloured eps file with the second line dashed
(so, 2 errors compared to Matlab, colour and dashes) and -depsc gives two
lines colored, no dashes (i.e. the same as Matlab). Nevertheless, when doing
the plots, there are some more differences about plotsizes, ticks, etc. and
most notably, the octave/gnuplot result looks much better as the axis fix
much more closely the data range.

My test was a simple

plot((0:0.1:2*pi), sin(0:0.1:2*pi), (0:0.1:2*pi), cos(0:0.1:2*pi))

which results in an x axis from 0 to 7 in Matlab and having curves stopping
at 2*pi looks really awfull then...

For completeness, I was comparing Matlab 6.5 with the current windows binary
distribution 2.9.15, so if you get different results ...


So, we have really three issues here: 
- the gnuplot eps terminal print results in coloured results even if b&w is
requested by octave
- octave goes with dashes at (pseudo)- b&w while matlab stays at solid (all
defaults only)
- as there are no "c" versions of the "latex" printers, the defaults seem to
be strange to me (and as they do not exist in matlab, we are free to define
reasonable defaults on our own).

Rolf