[Octave-bug-tracker] [bug #52940] Regression with "PaperPosition" and printing

[Dan Sebald]

Follow-up Comment #11, bug #52940 (project octave):

I too think rolling back probably isn't the thing to do.  It seems tempting,
but as I see it the issue still exists for QGLWidget--which is the fact that
the on-screen OpenGL rendering goes through those contortions when print is
invoked; that shouldn't happen.

Regarding those size numbers, for QGLWidget, the numbers are

viewport = 0 0 560 420
viewport = 0 0 720 396
viewport = 0 0 720 396

but that first 560 420 doesn't seem to make a difference.  What's interesting
is that for the QOpenGLWidget numbers

viewport = 0 0 720 396
viewport = 0 0 720 485
viewport = 0 0 720 485

the very first combination (0 0 720 396) works and matches the second set of
number of the QGLWidget case.  So, likely the 720 396 is the proper size that
is needed to make the nice centered plot.

In the remaining prints for QOpenGLWidget, the numbers are 720 485.  That 485
suggests a bigger view port in the y-direction, and the difference is roughly
90 pixels and yeah, that could be about 1" in PDF layout terms.  But why does
the image shift, rather than scale?  Is it because we are just talking the
view port *and* perhaps the coordinate system is the non-Euclidian "(0,0) in
upper left corner" that is common to some graphics systems?

Clearly things are set up slightly differently between these two widgets.

Anyway, it seems there might need to be a GLCanvas::initializeGL() that
changes the OpenGL context from on-screen to gl2psCONTEXT.  That might stop
the redraw of the on-screen image, which is a first good step.  Right now it
might be size-change, context-change when it should instead be context-change,
size-change.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52940>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/