Possible bug in print.m when exporting xfig-files.

[George Barrick]

% 
% Subj: Possible bug in print.m when exporting xfig-files.
% 
%                                2013.02.28.15:38:05 UT
% 
% Hey GNU Octave guys,
% 
%      I think that I have found a bug associated with the
% octave-3.6.4 print.m function.  My system is:
% 
% WinXP-32bit + CygWin-1.7.17-1 + XWin-1.13.2-2 + GNU_Octave-3.6.4
% 
% and I am using the Gnuplot-4.6.0 back-end (but sometimes also
% fltk-1.3.1.9285-1) for plotting.  My other software is xfig-3.2.5b-5
% and transfig-3.2.5d-3 (which brings the fig2dev() function).
% 
%      I believe that the setting of the 'nextplot' parameter
% for the 'axes' object is messing up the call of fig2dev()
% when it exports xfig-graphics for print.m.  When I set
% 'nextplot' _after_ a call to plot.m, and then toggle the
% 'visible' parameter for the current axes, there is no problem.
% However, when I set some of the 'nextplot' values _before_
% a call to plot.m, along with toggling of the 'visible'
% parameter, some of the plots appear almost totally black
% when opened in xfig.  Following is a table of my tests.
% The character 'G' indicates a good xfig-file; the 'B' marks
% ones in which the plot is black.
% 
%   ---------------------------------------------------------------------------
%   |          | no sttng |  'new'  |  'add'  | 'replace' | 'replacechildren' |
%   ---------------------------------------------------------------------------
%   | no sttng |    G     |    B    |    B    |    G      |         B         |
%   ---------------------------------------------------------------------------
%   |  'off'   |    G     |    G    |    G    |    G      |         G         |
%   ---------------------------------------------------------------------------
%   |  'on'    |    G     |    B    |    B    |    G      |         B         |
%   ---------------------------------------------------------------------------
% 
%   Note: Upon printing the xfig-file in the tests of the 'nextplot',
%     'new' setting (second column of my table), I got the warning:
%     'fig: attempt to set palette twice'.
% 
%       When I run these same tests with the setting of 'nextplot'
% occurring _after_ the call to plot.m, the resulting xfig-files
% are fine (everything visible).  Also I ran this same suite of
% thirty tests when using the fltk graphics engine, and in all
% of those, octave's print.m exported the xfig-files with no
% problem.
% 
%      I do realize that the situation where the plots turn up
% black is probably an example of me (and others) mis-applying
% the 'nextplot' parameter when plotting.  However, the documen-
% tation for these settings is pretty meagre, and I think it
% is possible that the GNU Octave developers may consider this
% behavior to be a bug.
% 
%      There was a short address@hidden thread
% surrounding this difficulty back on 2012.09.05 with the
% subject line 'print -dfig produces completely black plot =('.
% At that time, I was able to inform the person who was having
% the problem that if he edited the resulting xfig-file, and
% flipped the fill-number in field nine from '20' to '-1' for
% some of the polyline objects in the .fig mark-up, then the
% difficulty could be circumvented.
% 
%      My minimum working example of the difficulty appears in
% the following code.  I've commented out _all_ of my discussion
% paragraphs here, so that other users can quickly save my posting
% as the file 'minexmpl.m' and see whether the difficulty can be
% reproduced on their own systems.  If this _does_ turn out to
% be easily reproduced, then I think that the recoding for a fix
% could be simple, as it requires only that certain polylines
% in the xfig-file be set with a fill-number of '-1', rather
% than '20'.  I could _also_ be quite mistaken in this kind of
% thinking.
% 
%       I have tried to provide both a very complete report of
% this possible bug, as well as a minimum working example.  If
% there is anything that I have omitted, please _gently_ instruct
% me on what I need to add.  If this _does_ sound like a bug, give
% me some instructions on where I need to post.  Also, if this
% kind of thing is now irrelevant, with the main focus of GNU
% Octave graphics now shifting away from Gnuplot
% (and especially xfig-output) over to the fltk back-end, then
% tell me so, and I can certainly ignore this difficulty.  My
% main requirement right now is for plot dumps to .svg-files,
% and these seem to be working just fine.
% 
% George                        gee_barrick_at_walsh_dot_edu
% 
%% <file: minexmpl.m >

%% graphics_toolkit("fltk")                   ;
graphics_toolkit("gnuplot")                 ;

gca()                                       ;

%% If I manipulate the 'nextplot' setting _before_
%%   plotting, some plots turn up black.  If I do this
%%   _after_ plotting, no problem occurs.
%%
%% set( gca(),'nextplot','new' )              ;
%% set( gca(),'nextplot','add' )              ;
%% set( gca(),'nextplot','replace' )          ;
%% set( gca(),'nextplot','replacechildren' )  ;

xvals = [ 0 : 1 : 10 ]                      ;
yvals =     xvals                           ;

plot( xvals, yvals, 'k-' )                  ;

%% set( gca(),'nextplot','new' )              ;
%% set( gca(),'nextplot','add' )              ;
%% set( gca(),'nextplot','replace' )          ;
%% set( gca(),'nextplot','replacechildren' )  ;

%% set( gca(),'visible','off' )               ;
%% set( gca(),'visible','on' )                ;

%% print('minimeg.fig','-dfig')               ;

%% </file>