Re: Saves incomplete, multi-plot figure to file.

[Ben Abbott]

On May 11, 2013, at 5:08 AM, PetrSt wrote:

> gholladay wrote
>> Sadly not.  When I replaced:
>> 
>>    figure ("position", [0.5, 0.5, 2.8, 2.0] .* position);
>> 
>> with simply:
>> 
>>    figure (1);
>> 
>> It displayed the full figure with both plots (previously only partial) on
>> the interim window but, when I tried both 'saveas' and 'print' commands
>> for various file types, it froze Octave up (or was just running
>> continuously for a long time) and the only way I was able to stop it was
>> to close the figure window, which forced my to close Octave completely.
>> 
>> Just out of curiousity, I restored the figure command to it's previous
>> settings and it restored the ability to save the file but back to only a
>> partial figure.  I'm at a loss.
> 
> I have seen the command figure(1) in some advices here, but I'm not sure if
> it is a good way, since the number 1 then represents a handle of figure (if
> it doesn't exist a new one with this handle should be created). This is all
> o.k., but print command operates with gcf, so maybe it would be a good idea
> to check, if gcf returns 1, or explicitly define 1 as handle in print
> command. I prefer simple command figure(); or just figure; or fig=figure();
> without any handle specification (fig=figure('property',value,...);, if any
> figure property has to be changed). It is just a note, because I assume that
> the figure you wanted to print was the only created figure at that time, so
> the gcf pointed to the correct one.
> Normally print takes several seconds, but I remember the first time I used
> it, it took several minutes, since I used a graph with lots of points and
> notations, but it worked. My advice is to try a simple example, like
> figure; plot(1:10); print -djpeg test.jpeg;
> If it doesn't work or takes too long then the problem is elsewhere. You
> could also try to change the type of file (.eps or .pdf). If it works fine,
> then it should work also with your graph. If it's complicated and huge, let
> it run for longer time (in my case, as described above, the figure
> background turned to black and stuck for 10-15 minutes).
> 
> In former discussion (
> http://octave.1599824.n4.nabble.com/plot-not-filling-the-page-and-resulting-in-not-clear-figure-td4651044.html#a4651115
> <http://octave.1599824.n4.nabble.com/plot-not-filling-the-page-and-resulting-in-not-clear-figure-td4651044.html#a4651115>
>  
> ) about printing to file I made a script, which could also help you. It was
> about subplots, but basically the same problem.
> test_print2pdf.m
> <http://octave.1599824.n4.nabble.com/file/n4652793/test_print2pdf.m>  

What is the value of the figure's "units" property?  If it is "normalized", 
then the figure you're displaying is larger than your screen.  I don't know 
what the impact would be for gnuplot, but I don't think it will matter.

If you're using the "fltk" graphics toolkit, then this is definitely a problem.

What does the "graphic_toolkit ()" command return?  Are you using gnuplot or 
fltk?

Ben