[Top][All Lists]

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

[Octave-bug-tracker] [bug #48273] Incorrect axes position updates in Ope

From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #48273] Incorrect axes position updates in OpenGL plotting
Date: Thu, 25 Oct 2018 16:22:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #18, bug #48273 (project octave):

Oops, something went wrong with the verbatim tags in my previous comment. 
Here it is again:

After looking at this for a bit longer, I pushed the following changeset:


This improves things significantly for me, but we can probably still do

Given the following function, I can get plots on the screen for a large range
of values for NR and NC.

function foofcn (nr = 2, nc = 2)
  set(0, 'defaultfigureunits', 'normalized') ;
  set(0, 'defaultfigureposition', [0.7   0.7   0.25   0.25]) ;

  clf ;
  n = nr * nc;
  x = randn(3,n) ;
  for j=1:n
    subplot(nr,nc,j) ;
    plot(x(:,j)) ;
  print foo.png

However, I see the following ghostscript error on printing to a png file when
using NR=1 and NC=25 (for example).

Error: /undefined in -nan
Operand stack:
   --nostringval--   (-2.5)   --nostringval--   0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   2043   1   3   %oparray_pop  
2042   1   3   %oparray_pop   --nostringval--   2023   1   3   %oparray_pop  
1884   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2  
--nostringval--   --nostringval--   --nostringval--   2   %stopped_push  
Dictionary stack:
   --dict:969/1684(ro)(G)--   --dict:0/20(G)--   --dict:83/200(L)--  
Current allocation mode is local
Last OS error: No such file or directory
GPL Ghostscript 9.25: Unrecoverable error, exit code 1

So it looks like we may still be generating some bad values.  I would also
guess that we will also fail for large enough numbers of subplots no matter
what the orientation.  But rather than place an arbitrary limit in the subplot
function, I think it would be better to try to fix the plotting code to detect
bad values if/when they are generated.  That way, any plotting code that
attempts to do something silly will fail with an error message instead of just
avoiding the problem in the subplot function.


Reply to this item at:


  Message sent via Savannah

reply via email to

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