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

[Dan Sebald]

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

After looking at the graphics code and gl2ps_print code for a while, I think
we should probably apply the current small change as an intermediate step. 
After that, there would need to be a bigger change--not huge, but it would be
shaking the tree a bit.

I just couldn't find a way to make that gl2ps_print function work outside of
the opengl graphics toolkit.  The reason is that the gl2ps_print() routine is
fed a graphics_object reference that is *const*, i.e.:


  void
  gl2ps_print (const graphics_object& fig, const std::string& stream,
               const std::string& term)
  {


Hence there is no way in C++ land to modify "position" property and rerun the
"update transform" that is important for making the draws have the proper
scale during print.  The compiler won't allow changing the property values
directly, and it also won't allow reruning any of the graphics routines
complaining about a "const 'this' pointer" not suitable for member functions. 
So, currently the *only* way of changing the layout and internally re-running
the update-transform is from Octave command-line land.  Hence, as things are
currently setup, there is no way of not modifying the on-screen figure to get
the proper transform scaling.

Yes, there is some internal Booleans that disable updating the toolkit, etc. 
But those don't seem the most convenient, and messing around with that I've
found there were artifacts like the background of the plot outside the borders
turning out black in the PDF file.  I also started down the route of dropping
the "const" from "const graphics_object& fig", but that's really not the
proper thing to do.  I then thought to pass another Boolean into the draw()
routines to indicate that the PaperPosition should be used instead of Postion
for the transform, but that too isn't very good.

Here's what the problem is (then I'll describe two ways of changing this).  As
member functions of the axes::properties object are these functions:


    void update_transform (void)
    {
      update_aspectratios ();
      update_camera ();
      update_axes_layout ();
    }


which manage that important information about transformation matrices and so
on.  Because the on-screen and print renderings are a different size, these
routines must be run for both.  As described above, the only way of causing
that code to run is by changing the figure's Position property.  Doing so
causes an update of the toolkit figure.  With the current setup that code
can't be run in a straightforward way from a C++ routine; that's the problem.

One main point is that it seems that the camera and layout internals (i.e.,
the transform matrices) really aren't part of the properties.  Instead, those
seem more like something that should be associated with the *renderer*.  So
that is the first approach:

1) Move the update_aspectratios(), update_camera() and update_axes_layout()
code from axes::properties to the opengl_renderer object (of which
gl2ps_render inherits).  That way, both the toolkit's opengl_renderer and the
print's gl2ps_renderer can have their own associated transform formula (the
former using Position, the latter using PaperPosition) independent of and not
interfering with the other renderer.  They both use the same figure
properties, but the transforms are different.

The above seems the proper approach simply because of the natural association
of the transform and object.  Another approach that doesn't seem as elegant
for some reason is

2) Move the gl2ps_print method to a member function of the graphics.cc
hierarchy.  When the print is a member function of the graphics objects it
would have non-const access to the internal data and member functions
update_camera() and so on without having to go through the
"set(fig,"position",...)" script interface.

    _______________________________________________________

Reply to this item at:

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

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