|
From: Benjamin L. <lin...@gm...> - 2010-02-22 17:24:59
|
> One problem I note in both cases: Font changes made with the "Choose
> Font" Windows dialog do not take effect unless followed by a replot
> command. The plot is immediately redrawn when the dialog is dismissed
> with 'Okay', but the font does not change and if the Choose Font
> dialog is called again without an intervening replot, the old font is
> displayed. This separate replot command should not be necessary.
> There is something missing from the code that redraws the plot when
> the dialog is closed. I'm sure that someone who is more of a Windows
> programmer than I can fix this easily.
No, there is nothing missing in the code that redraws the plot.
And I'm not sure this can be easily fixed.
This is a manifestation of a principal problem in gnuplot's plotting
algorithm.
One of the very first commands (actually when I debugged this problem,
*the* first command) sent to the terminal when creating a plot is a
reset-font-to-the-default-font command.
Calling stack:
do_plot() (graphics.c)
boundary() (graphics.c)
find_maxl_keys() (graphics.c)
ignore_enhanced() (term.c)
term->set_font("")
This command will contain the default font at startup. Fine.
Now you change the default font from the dialog box. This changes the
default font name for the terminal. But redrawing the graph simply
re-executes the queued plotting commands. And these do not change unless
you execute a "replot".
Which means that the font hasn't really changed, until you issue a replot.
The reason this works for the line styles is that the line style itself
is not hard-coded into the command queue. It just queues the style
number to use, not the style definition (so if you change the style
definition and re-execute the commands you'll get an updated display).
However, the font names are hard-coded. So there is no special command
for "set to the default font". It's just "set to font FOO" (which
happens to be the default font at the time the command is queued).
benjamin
|