help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: print -dfig produces completely black plot =(


From: George Barrick
Subject: Re: print -dfig produces completely black plot =(
Date: Wed, 5 Sep 2012 16:12:16 -0400

                                 2012.09.05.19:28:04 UT

Hey aeqel,

     I saw your message in the list, and thought that
I might help.  I get the same problem with printed
.fig files as you described for octave-3.6.2.  What I
did was:

    a) write a really simplistic octave plot that _is_
       rendered well as a .fig,

    b) wrote a slightly more sophisticated octave plot
       that breaks the .fig.

When I compared the two, I found the one thing in the
.fig file that is causing the plots to be black.

     My plotting script was the text that follows:

<file: figexmpl.m>
winXst     =  288 ;
winYst     =  320 ;
winWdt     =  608 ;
winHgt     =  448 ;

winPos  = [ winXst winYst winWdt winHgt ] ;

win    = [ winWdt winHgt winWdt winHgt ] ;

plotWdt     =   500     ;
plotHgt     =   375     ;
plotXst     =    68     ;
plotYst     =    25     ;

plotPos     =  [ plotXst plotYst plotWdt plotHgt ] ./ win ;

xlims    =      [ -2.500,  2.500  ]     ;
ylims    =      [ -1.750,  1.750  ]     ;

mdle = figure()                                  ;
set( mdle,'position',winPos )                    ;
set( mdle,'paperpositionmode','auto')            ;

qdle = axes() ;
set( qdle,'position',plotPos )                   ;
set( qdle,'xlim',xlims,'ylim',ylims )            ;

set( qdle,'dataaspectratio',[ 1, 1, 1 ] )        ;
set( qdle,'nextplot','add','visible','off' )     ;
%% set( qdle,'box','on')                            ;

%% set( qdle, 'xtick',    [ ] )      ;
%% set( qdle, 'xticklabel', '' )        ;

%% set( qdle, 'ytick',    [ ] )      ;
%% set( qdle, 'yticklabel', '' )        ;

%% Plot zero nearly reproduces axis-box around plot.
xvals = [ -2.490  2.490  2.490 -2.490 -2.490 ]   ;
zvals = [ -1.740 -1.740  1.740  1.740 -1.740 ]   ;

n0    = plot( xvals, zvals, 'k-' );
set(n0,'linewidth',2) ;

%% Plot one is just a short line segment running
%%   through the plotting region.
tvals = [ -2.0  2.0 ] ;
yvals = [ -1.5  1.5 ] ;

n1    = plot( tvals, yvals, 'k-' );
set(n1,'linewidth',2) ;

%% These GNU Octave versions of the print command
%%   give precise control over the scaling of the
%%   printed image.
%% print(mdle,'figexmpl.png','-dpng','-S608,448');
%% print(mdle,'figexmpl.svg','-dsvg','-S608,448');
%% print(mdle,'figexmpl0.fig','-dfig','-S608,448');
%% print(mdle,'figexmpl1.fig','-dfig','-S608,448');
%%
</file: figexmpl.m>

     I first ran this plot, and saved its output to
the figexmpl0.fig file.  This showed up fine when I
took it over to Xfig.  Then I commented out the
"Plot zero" and allowed the octave to create a
tick-less, label-less axis-box by decommenting the
the set( qdle ) statements and turning the axis
visibilty to 'on'.  I printed the output from this
to the figexmpl1.fig file.  The file figexmpl1.fig
did in fact exhibit the black plot when I opened
it in Xfig.

      Finally, I looked in the Xfig user manual at:

http://epb.lbl.gov/xfig/fig-format.html

to see if I could understand the mark-up that exists
inside the .fig files.  In the two .fig files, the
lines from about line 10 down through line 137 are
just color definitions, and can be ignored.  That
leaves only the last twenty-five lines or so of each
file to find differences.

      I thought that this ought to be a problem with
some kind of "fill" command inside the .fig file.
As it turns out, you quite probably have a poly-line
(begins with code 2) whose fill-field (the ninth field
in the poly-line) is set to 20.  Just edit that ninth
field in the first poly-line where it occurs.  Change
it from 20 to a -1, and "Bob's your uncle!"; the .fig
file now works!

      This fix is a bit tedious, but I am pretty certain
that it alleviates exactly the problem you are having.  I
have done a quick read through the file

/usr/share/octave/3.6.2/m/plot/print.m

to see if I could recognize the difficulty, but I am not
clear from the reading where this might be happening, or
even whether it is an octave-, gnuplot- or other back-end
processing difficulty.  Also, someone may have already
fixed the problem, and print.m will be fine in octave-3.6.3.
I still do not have octave-3.6.3, as I am a cygwin-geek,
and octave-3.6.3 will not appear among the cygwin binaries
for a few days yet.

Good luck,

George                          g_barrick_at_walsh_dot_edu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]