Octave graphics bugs and thoughts

[Daniel J Sebald]

I've come across some bugs in the gnuplot implementation of Octave's graphics.  
I also want to give some thoughts and suggestions.  The order will be 1) 
thoughts, 2) bugs, 3) suggustion.

I commend those who've done so much work on the gnuplot graphics.  Many 
complain about gnuplot, but what I've seen is near as good as Matlab in 
appearance and functionality.  In fact, the gnuplot implementation has one 
advantage: if one is running a long simulation that occassionally puts out a 
plot, because gnuplot is a separate process, the plot can be viewed while the 
simulation is still running.  That doesn't work so well in a single-threaded 
app.

Here are some bugs...

The X11 terminal has a problem with all characters appearing as Greek when some 
other piece of text in the plot has a Greek character.  Here are some commands 
and the results I see:

plot([1:50])
title('Here is English text')
 <Text appears as it should in X11 terminal>
xlabel('\omega H')
 <The title changes to all Greek characters>
title('Here is English text')
 <Nothing changes>
title('Here is English text \omega')
 <The title appear appropriately in English mixed with Greek>

So there is some odd behavior there, but perhaps it is gnuplot that has a bug.  
Other terminals seem to be OK.  If developers think this is a gnuplot issue, I 
will check into it.

A colorbar will shift as a result of printing the plot in PostScript.  Only 
after a PostScript print is there a problem.

imagesc(rand(50))
colorbar()
 <colorbar looks good in X11 terminal>
print('-depsc2', 'junk.eps')
 <colorbar still looks good in X11>
print('-dpsc2', 'junk.ps')
 <colorbar shifts leftward in X11, but in PostScript it is in the correct 
positon>

The colorbar will look correct in the PostScript plot, but only for the first 
plot. Subsequent plots will have the colorbar wrong in PostScript.  I do see 
some special consideration in the Octave scripts for the PostScript case; 
perhaps a variable is not being set back to the correct value.

I know that John once set up Octave plotting via gnuplot so that a redraw isn't 
done until all commands are processed.  That is, say in a script file is 
title(), xlabel(), legend()... the redraw would happen only after the last 
command.  The source tip now has a lot of flashing of screens and such as 
though all intermediate plots are redrawing.

The output for PS in the example above has a wider-than-should-be colorbar.  
However, the output of EPS (junk.eps) looks pretty good; unfortunately the 
default font size is too small compared to other terminals.  (I have a kludge 
workaround; it leaves tick marks bigger than they should be.)  This brings me 
to the suggestion portion of this email.

Gnuplot isn't set up to maintain a consistently proportioned default font size 
across all its terminals.  Call it a short-coming, I don't know.  It is more a 
philosophy as to not caring how the terminal behaves once it is set up.  But 
the comments on this list sound as though consistency is desirable for Octave.  
However, looking at the gnuplot scripts, there is a slight short-coming that 
makes it difficult to achieve this.  It is the fact that information about the 
terminal type isn't carried down to the level at which commands for basic 
elements are added to the plot stream.  So font size is difficult to adjust, 
and I also see this comment:

 ## FIXME -- linetype is currently broken, since it disables the
 ## gnuplot default dashed and solid linestyles with the only
 ## benefit of being able to specify '--' and get a single sized
 ## dashed line of identical dash pattern for all called this way.
 ## All dash patterns are a subset of "with lines" and none of the
 ## lt specifications will correctly propagate into the x11 terminal
 ## or the print command.   Therefore, it is currently disabled in
 ## order to allow print (..., "-dashed") etc. to work correctly.

which is the same sort of issue, I think.  It's as though Octave's graphics 
have been set up with the same philosophy as gnuplot, i.e., set the terminal at 
a high level and let the user tweak details.

It seems to me that what Octave w/gnuplot should have is a mapper or two at the 
low level that appropriately deals with these items right before they are used. 
 For example,

function [f, s, fnt, it, bld] = get_fontname_and_size (t)

should have access to terminal information in some way so that a final 
adjustment can be done to correct for size, e.g., rather than

if (isempty (t.fontsize))
  s = 10;
else
  s = t.fontsize;
endif

do

if (isempty (t.fontsize))
  s = 10*__gp_font_scale__(term);
else
  s = t.fontsize*__gp_font_scale__(term);
endif

Also, it doesn't make sense to attempt dealing with this on a higher level by 
setting all font sizes of objects based upon what the terminal is.  That would 
be a mess.

So, what do the graphics developers think?  Should the terminal type be carried around?  I would 
suggest doing it in an efficient way.  Don't keep testing for "eps", "png", 
etc., but instead have a collection of functions associated with terminal, e.g.,

term_num = __gp_term__(term_switch_string);
 <then pass this integer about where needed, e.g.,>
font_scale = __gp_font_scale__(term_num);
line_type = __gp_line_type__(term_num, ...);

Most of the above commands would simply be a look-up-table.

Dan