[snip]
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.
changeset.patch