Choosing graphics backend for documentation

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Choosing graphics backend for documentation

Rik-4
Ben, Mike,

The scripts that generate the images are m-files in doc/interpreter.  They
all have a subfunction called set_graphics_toolkit() which is shown below.

-- Start of Code --
## This function no longer sets the graphics toolkit; That is now done
## automatically by C++ code which will ordinarily choose 'qt', but might
## choose gnuplot on older systems.  Only a complete lack of plotting is a
## problem.
function set_graphics_toolkit ()
  if (isempty (available_graphics_toolkits ()))
    error ("no graphics toolkit available for plotting");
  endif
endfunction
-- End of Code --

This could be modified to check for the presence of OSMESA and attempt to
use gnuplot if it is not present.

This check works for me

if (octave_config_info ().features.OSMESA)
 ...
endif


Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey
Ben, Mike,

The scripts that generate the images are m-files in doc/interpreter.  They
all have a subfunction called set_graphics_toolkit() which is shown below.

-- Start of Code --
## This function no longer sets the graphics toolkit; That is now done
## automatically by C++ code which will ordinarily choose 'qt', but might
## choose gnuplot on older systems.  Only a complete lack of plotting is a
## problem.
function set_graphics_toolkit ()
  if (isempty (available_graphics_toolkits ()))
    error ("no graphics toolkit available for plotting");
  endif
endfunction
-- End of Code --

This could be modified to check for the presence of OSMESA and attempt to
use gnuplot if it is not present.

This check works for me

if (octave_config_info ().features.OSMESA)
 ...
endif


The way I wrote the preliminary version of this, it fell back to
gnuplot (if available), but I am not sure that this is really a
good idea. Having copies of the Manual built with problems
may not be helpful.

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Mike Miller-4
On Mon, Jul 27, 2015 at 17:14:16 +0100, Michael Godfrey wrote:
> The way I wrote the preliminary version of this, it fell back to
> gnuplot (if available), but I am not sure that this is really a
> good idea. Having copies of the Manual built with problems
> may not be helpful.

Agreed. Are you mostly referring to bug #42838 (black plot area with gnuplot 5)?

I suggested another acceptable alternative might be to build the
figures with "visible" set to true if osmesa is not available.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator
In reply to this post by Rik-4
> On Jul 27, 2015, at 12:06 PM, Rik <[hidden email]> wrote:

>
> Ben, Mike,
>
> The scripts that generate the images are m-files in doc/interpreter.  They
> all have a subfunction called set_graphics_toolkit() which is shown below.
>
> -- Start of Code --
> ## This function no longer sets the graphics toolkit; That is now done
> ## automatically by C++ code which will ordinarily choose 'qt', but might
> ## choose gnuplot on older systems.  Only a complete lack of plotting is a
> ## problem.
> function set_graphics_toolkit ()
>  if (isempty (available_graphics_toolkits ()))
>    error ("no graphics toolkit available for plotting");
>  endif
> endfunction
> -- End of Code --
>
> This could be modified to check for the presence of OSMESA and attempt to
> use gnuplot if it is not present.
>
> This check works for me
>
> if (octave_config_info ().features.OSMESA)
> …
> endif
Rik,

It would be nice if a change were made to allow a build to complete when osmesa isn’t present.

However, I’d also like to have print() work when the figure isn’t visible (i.e. I think the problem is broader than building the docs). What do you think of the attached patch?

Ben


backup_osmesa_with_gnuplot.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator
In reply to this post by Mike Miller-4
> On Jul 27, 2015, at 12:36 PM, Mike Miller <[hidden email]> wrote:
>
> On Mon, Jul 27, 2015 at 17:14:16 +0100, Michael Godfrey wrote:
>> The way I wrote the preliminary version of this, it fell back to
>> gnuplot (if available), but I am not sure that this is really a
>> good idea. Having copies of the Manual built with problems
>> may not be helpful.
>
> Agreed. Are you mostly referring to bug #42838 (black plot area with gnuplot 5)?
>
> I suggested another acceptable alternative might be to build the
> figures with "visible" set to true if osmesa is not available.
>
> --
> mike

I think that is a good idea. I’d prefer this be handled in print() so that printing of hidden figures work in all cases.

Ben
Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey
In reply to this post by Mike Miller-4


On 07/27/2015 05:36 PM, Mike Miller wrote:
On Mon, Jul 27, 2015 at 17:14:16 +0100, Michael Godfrey wrote:
> The way I wrote the preliminary version of this, it fell back to
> gnuplot (if available), but I am not sure that this is really a
> good idea. Having copies of the Manual built with problems
> may not be helpful.
Agreed. Are you mostly referring to bug #42838 (black plot area with gnuplot 5)?

I suggested another acceptable alternative might be to build the
figures with "visible" set to true if osmesa is not available.

-- mike
Not really. It may be possible to do the work required for
 demonstrating the standalone modes, and even fig 15-7,
using gnuplot, but I think the time and effort could be
better spent on other plot/print enhancements.

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Daniel Sebald
In reply to this post by Mike Miller-4
On 07/27/2015 11:36 AM, Mike Miller wrote:
> On Mon, Jul 27, 2015 at 17:14:16 +0100, Michael Godfrey wrote:
>> The way I wrote the preliminary version of this, it fell back to
>> gnuplot (if available), but I am not sure that this is really a
>> good idea. Having copies of the Manual built with problems
>> may not be helpful.
>
> Agreed. Are you mostly referring to bug #42838 (black plot area with gnuplot 5)?

I think using -epsc should fix most problems.

gnuplot added a "mono" option to its terminal settings, but developers
have claimed not being sure exactly what that is supposed to mean
anymore.  I think Octave folks might think of that as being grayscale,
whereas for gnuplot I'm not sure, could be "single tone".  (Hence, any
non-white color gets mapped to black.)  I've suggested to gnuplot
developers that terminals have mono/grayscale/color options, but it may
be that gnuplot developers have concentrated more on color behavior
lately and view mono as something not very common anymore.

Also, there may have been an Octave change to make -deps mean grayscale
for compatibility reasons.

And then there is the change whereby Octave first generates EPS output
then uses some external conversion utility to create all other formats.

All of these changes seemed to happen at the same time making the
gnuplot behavior appear dodgy.

Would a gnuplot "grayscale" setting (as opposed to "mono") help?
Another approach is to always use color gnuplot options, but have Octave
gnuplot "driver" use psuedo-grayscale by making all three color channels
the same.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Rik-4
In reply to this post by bpabbott
On 07/27/2015 09:50 AM, Ben Abbott wrote:

>> On Jul 27, 2015, at 12:06 PM, Rik <[hidden email]> wrote:
>>
>> Ben, Mike,
>>
>> The scripts that generate the images are m-files in doc/interpreter.  They
>> all have a subfunction called set_graphics_toolkit() which is shown below.
>>
>> -- Start of Code --
>> ## This function no longer sets the graphics toolkit; That is now done
>> ## automatically by C++ code which will ordinarily choose 'qt', but might
>> ## choose gnuplot on older systems.  Only a complete lack of plotting is a
>> ## problem.
>> function set_graphics_toolkit ()
>>  if (isempty (available_graphics_toolkits ()))
>>    error ("no graphics toolkit available for plotting");
>>  endif
>> endfunction
>> -- End of Code --
>>
>> This could be modified to check for the presence of OSMESA and attempt to
>> use gnuplot if it is not present.
>>
>> This check works for me
>>
>> if (octave_config_info ().features.OSMESA)
>> …
>> endif
> Rik,
>
> It would be nice if a change were made to allow a build to complete when osmesa isn’t present.
>
> However, I’d also like to have print() work when the figure isn’t visible (i.e. I think the problem is broader than building the docs). What do you think of the attached patch?

Ben,

I'd rather not have print() change toolkits on the user.  The toolkits are
slightly different, although we are trying to harmonize them, but if a user
has selected a toolkit I feel that we should respect that choice.  It may
have been made for very good reasons.  For example, gnuplot supports
arbitrary text rotation so maybe a user chose gnuplot for that reason.  On
the other hand, only the OpenGL-based renderers support non-triangular 3-D
patches.  Without examining the plot in detail I couldn't say that it is
okay to swap toolkits.

It might be okay to issue a warning, but before we go too far in this
direction can we get osmesa to work on Linux, Windows, and Mac?  That would
be the simplest and best.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey


On 07/27/2015 07:49 PM, Rik wrote:
On 07/27/2015 09:50 AM, Ben Abbott wrote:
>> On Jul 27, 2015, at 12:06 PM, Rik [hidden email] wrote:
>>
>> Ben, Mike,
>>
>> The scripts that generate the images are m-files in doc/interpreter.  They
>> all have a subfunction called set_graphics_toolkit() which is shown below.
>>
>> -- Start of Code --
>> ## This function no longer sets the graphics toolkit; That is now done
>> ## automatically by C++ code which will ordinarily choose 'qt', but might
>> ## choose gnuplot on older systems.  Only a complete lack of plotting is a
>> ## problem.
>> function set_graphics_toolkit ()
>>  if (isempty (available_graphics_toolkits ()))
>>    error ("no graphics toolkit available for plotting");
>>  endif
>> endfunction
>> -- End of Code --
>>
>> This could be modified to check for the presence of OSMESA and attempt to
>> use gnuplot if it is not present.
>>
>> This check works for me
>>
>> if (octave_config_info ().features.OSMESA)
>> >> endif
> Rik,
>
> It would be nice if a change were made to allow a build to complete when osmesa isn’t present.
>
> However, I’d also like to have print() work when the figure isn’t visible (i.e. I think the problem is broader than building the docs). What do you think of the attached patch?
Ben,

I'd rather not have print() change toolkits on the user.  The toolkits are
slightly different, although we are trying to harmonize them, but if a user
has selected a toolkit I feel that we should respect that choice.  It may
have been made for very good reasons.  For example, gnuplot supports
arbitrary text rotation so maybe a user chose gnuplot for that reason.  On
the other hand, only the OpenGL-based renderers support non-triangular 3-D
patches.  Without examining the plot in detail I couldn't say that it is
okay to swap toolkits.

It might be okay to issue a warning, but before we go too far in this
direction can we get osmesa to work on Linux, Windows, and Mac?  That would
be the simplest and best.

--Rik


I very much agree with Rik. User are already not well informed about how or when
to use any of the graphics_toolkits. Nor do they know the restrictions on using
print.  Switching tool_kits within print would only add the the confusion.
One one "patch" that might be considered could be to put code within print
that tests for qt or fltk and for the visibility of the figure, then if it is visible
turn it off, generate the plot, and then turn it back on. This is already done
manually in the doc code and other places.

 The priority should be on merging gt and fltk into one Mesa-based
tookit the is fully functional, and documented. 

Michael
Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator

On Jul 27, 2015, at 5:41 PM, Michael Godfrey <[hidden email]> wrote:

On 07/27/2015 07:49 PM, Rik wrote:
On 07/27/2015 09:50 AM, Ben Abbott wrote:
>> On Jul 27, 2015, at 12:06 PM, Rik [hidden email] wrote:
>>
>> Ben, Mike,
>>
>> The scripts that generate the images are m-files in doc/interpreter.  They
>> all have a subfunction called set_graphics_toolkit() which is shown below.
>>
>> -- Start of Code --
>> ## This function no longer sets the graphics toolkit; That is now done
>> ## automatically by C++ code which will ordinarily choose 'qt', but might
>> ## choose gnuplot on older systems.  Only a complete lack of plotting is a
>> ## problem.
>> function set_graphics_toolkit ()
>>  if (isempty (available_graphics_toolkits ()))
>>    error ("no graphics toolkit available for plotting");
>>  endif
>> endfunction
>> -- End of Code --
>>
>> This could be modified to check for the presence of OSMESA and attempt to
>> use gnuplot if it is not present.
>>
>> This check works for me
>>
>> if (octave_config_info ().features.OSMESA)
>> >> endif
> Rik,
>
> It would be nice if a change were made to allow a build to complete when osmesa isn’t present.
>
> However, I’d also like to have print() work when the figure isn’t visible (i.e. I think the problem is broader than building the docs). What do you think of the attached patch?
Ben,

I'd rather not have print() change toolkits on the user.  The toolkits are
slightly different, although we are trying to harmonize them, but if a user
has selected a toolkit I feel that we should respect that choice.  It may
have been made for very good reasons.  For example, gnuplot supports
arbitrary text rotation so maybe a user chose gnuplot for that reason.  On
the other hand, only the OpenGL-based renderers support non-triangular 3-D
patches.  Without examining the plot in detail I couldn't say that it is
okay to swap toolkits.

It might be okay to issue a warning, but before we go too far in this
direction can we get osmesa to work on Linux, Windows, and Mac?  That would
be the simplest and best.

--Rik
I very much agree with Rik. User are already not well informed about how or when
to use any of the graphics_toolkits. Nor do they know the restrictions on using
print.  Switching tool_kits within print would only add the the confusion.
One one "patch" that might be considered could be to put code within print
that tests for qt or fltk and for the visibility of the figure, then if it is visible
turn it off, generate the plot, and then turn it back on. This is already done
manually in the doc code and other places.

 The priority should be on merging gt and fltk into one Mesa-based
tookit the is fully functional, and documented. 

Michael

Ok. Then I suggest we not allow the docs to be build using gnuplot. Instead, can we disable making the docs if OSMesa isn’t present? … an implicit --disable-docs?

Ben


Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey


On 07/27/2015 10:48 PM, Ben Abbott wrote:
Ok. Then I suggest we not allow the docs to be build using gnuplot. Instead, can we disable making the docs if OSMesa isn’t present? … an implicit --disable-docs?

Ben
I am quite sure that this is what happens now. After putting the "try gnuplot" code
in I realized that this was not a good idea and was happy that Rik dropped it.
So,  it just remains to do the work that I hinted at previously....

Michael

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator
In reply to this post by Rik-4

> On Jul 27, 2015, at 12:06 PM, Rik <[hidden email]> wrote:
>
> Ben, Mike,
>
> The scripts that generate the images are m-files in doc/interpreter.  They
> all have a subfunction called set_graphics_toolkit() which is shown below.
>
> -- Start of Code --
> ## This function no longer sets the graphics toolkit; That is now done
> ## automatically by C++ code which will ordinarily choose 'qt', but might
> ## choose gnuplot on older systems.  Only a complete lack of plotting is a
> ## problem.
> function set_graphics_toolkit ()
>  if (isempty (available_graphics_toolkits ()))
>    error ("no graphics toolkit available for plotting");
>  endif
> endfunction
> -- End of Code --
>
> This could be modified to check for the presence of OSMESA and attempt to
> use gnuplot if it is not present.
>
> This check works for me
>
> if (octave_config_info ().features.OSMESA)
> ...
> endif
>
Rik/Mike/Others,

Does the attached patch look ok?

Ben





backup_osmesa_with_gnuplot.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Mike Miller-4
On Sun, Aug 16, 2015 at 16:11:05 -0400, Ben Abbott wrote:
> Does the attached patch look ok?

Does it work for you? I think all that's missing is another error in
case gnuplot is not available (which is now possible).

Something like

 function set_graphics_toolkit ()
   if (isempty (available_graphics_toolkits ()))
     error ("no graphics toolkit available for plotting");
   elseif (! strcmp ("gnuplot", graphics_toolkit ()) ...
      && ! octave_config_info ().features.OSMESA)
     if (! any (strcmp ("gnuplot", available_graphics_toolkits ())))
       error ("no graphics toolkit available for offscreen plotting");
     else
       graphics_toolkit ("gnuplot");
     endif
   endif
 endfunction

look ok?

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey


On 08/16/2015 10:21 PM, Mike Miller wrote:
On Sun, Aug 16, 2015 at 16:11:05 -0400, Ben Abbott wrote:
> Does the attached patch look ok?
Does it work for you? I think all that's missing is another error in
case gnuplot is not available (which is now possible).

Something like

 function set_graphics_toolkit ()
   if (isempty (available_graphics_toolkits ()))
     error ("no graphics toolkit available for plotting");
   elseif (! strcmp ("gnuplot", graphics_toolkit ()) ...
      && ! octave_config_info ().features.OSMESA)
     if (! any (strcmp ("gnuplot", available_graphics_toolkits ())))
       error ("no graphics toolkit available for offscreen plotting");
     else
       graphics_toolkit ("gnuplot");
     endif
   endif
 endfunction

look ok?

-- mike
If gnuplot is used not all figures can be drawn.  Is this useful?

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Daniel Sebald
On 08/16/2015 04:45 PM, Michael Godfrey wrote:

>
>
> On 08/16/2015 10:21 PM, Mike Miller wrote:
>> On Sun, Aug 16, 2015 at 16:11:05 -0400, Ben Abbott wrote:
>>> >  Does the attached patch look ok?
>> Does it work for you? I think all that's missing is another error in
>> case gnuplot is not available (which is now possible).
>>
>> Something like
>>
>>   function set_graphics_toolkit ()
>>     if (isempty (available_graphics_toolkits ()))
>>       error ("no graphics toolkit available for plotting");
>>     elseif (! strcmp ("gnuplot", graphics_toolkit ()) ...
>>        &&  ! octave_config_info ().features.OSMESA)
>>       if (! any (strcmp ("gnuplot", available_graphics_toolkits ())))
>>         error ("no graphics toolkit available for offscreen plotting");
>>       else
>>         graphics_toolkit ("gnuplot");
>>       endif
>>     endif
>>   endfunction
>>
>> look ok?
>>
>> -- mike
> If gnuplot is used not all figures can be drawn.  Is this useful?

What figures can't be drawn?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey


On 08/16/2015 10:59 PM, Daniel J Sebald wrote:
> What figures can't be drawn?
>
> Dan
Besides Fig. 15-7, the Plotting section will need extensive rewrite to
document a system with gnuplot only.


Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator
> On Aug 16, 2015, at 8:19 PM, Michael Godfrey <[hidden email]> wrote:
>
> On 08/16/2015 10:59 PM, Daniel J Sebald wrote:
>> What figures can't be drawn?
>>
>> Dan
> Besides Fig. 15-7, the Plotting section will need extensive rewrite to
> document a system with gnuplot only.

I don’t think the documentation should change if only gnuplot is present … is that what you meant?

For me, the question is whether or not the documentation can be generated only using gnuplot.

Ben




Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Daniel Sebald
In reply to this post by Michael Godfrey
On 08/16/2015 07:19 PM, Michael Godfrey wrote:
>
>
> On 08/16/2015 10:59 PM, Daniel J Sebald wrote:
>> What figures can't be drawn?
>>
>> Dan
> Besides Fig. 15-7, the Plotting section will need extensive rewrite to
> document a system with gnuplot only.

Figure 15.7: Example of inclusion of text with use of -dpdflatexstandalone

pdflatexstandalone was working for me.  I just checked this bug report:

https://savannah.gnu.org/bugs/?44187

and see that Ben updated some things.  (I don't always get email for
followup savannah comments.)  I will take a look at his changes sometime
later this week when I'm free, but I don't know the Mac OS flavor of
unix so can't debug anything Apple related.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

Michael Godfrey
In reply to this post by bpabbott


On 08/17/2015 01:52 AM, Ben Abbott wrote:

>> On Aug 16, 2015, at 8:19 PM, Michael Godfrey<[hidden email]>  wrote:
>> >
>> >On 08/16/2015 10:59 PM, Daniel J Sebald wrote:
>>> >>What figures can't be drawn?
>>> >>
>>> >>Dan
>> >Besides Fig. 15-7, the Plotting section will need extensive rewrite to
>> >document a system with gnuplot only.
> I don’t think the documentation should change if only gnuplot is present … is that what you meant?
>
> For me, the question is whether or not the documentation can be generated only using gnuplot.
>
> Ben
>
>
>
It appears that I do not understand what is being proposed here. If the
indent is to
provide users of Octave with a version which only supports gnuplot for
plotting then
the current manual is not appropriate for them. There has always been an
issue due
to the fact that there has only been one version of the manual, but
Octave can be
built with or without various features.  But, the maintenance of a
single Octave
overrides this.  Note that if OpenGL is not available the gui will not
be either.

This gnuplot only system seems to be needed only in the case where users
are building Octave
from source. Most users will install a packaged Octave. If they want a
Manual they
have to obtain it from the Octave site.  The reason for including the
Manual source
files is for developers use. So, it appears that the only use for this
option is for
developers use on systems which lack any working OpenGL.  Most
developers will
need to have a system which is capable of generating a fully functional
Octave for
testing. This requires OpenGL.

If this effort is intended to provide users a new version of Octave
which does not depend on
OpenGL than this should be made explicit and agreed on through the
developers list.

The current Manual states:
> Earlier versions of Octave provided plotting through the use of
> gnuplot. This capability is
> still available. But, a newer plotting capability is provided by
> access to OpenGL. Which
> plotting system is used is controlled by the graphics_toolkit
> function. See Section 15.4.7
> [Graphics Toolkits], page 403.

I do not think that this should be changed to state something like
"versions of Octave
which lack OpenGL, and therefore lack the graphics_toolkit and the GUI
interface are
also supported. Please see the release documentation for details..."

This is what I meant to say about the Manual.

If it is decided to bring this up on the developers list, I will
indicate that I do not agree to
the introduction of  new versions of Octave which lack the current
graphics capabilities.

Michael



Reply | Threaded
Open this post in threaded view
|

Re: Choosing graphics backend for documentation

bpabbott
Administrator
In reply to this post by Daniel Sebald
> On Aug 17, 2015, at 1:17 AM, Daniel J Sebald <[hidden email]> wrote:
>
> On 08/16/2015 07:19 PM, Michael Godfrey wrote:
>>
>>
>> On 08/16/2015 10:59 PM, Daniel J Sebald wrote:
>>> What figures can't be drawn?
>>>
>>> Dan
>> Besides Fig. 15-7, the Plotting section will need extensive rewrite to
>> document a system with gnuplot only.
>
> Figure 15.7: Example of inclusion of text with use of -dpdflatexstandalone
>
> pdflatexstandalone was working for me.  I just checked this bug report:
>
> https://savannah.gnu.org/bugs/?44187
>
> and see that Ben updated some things.  (I don't always get email for followup savannah comments.)  I will take a look at his changes sometime later this week when I'm free, but I don't know the Mac OS flavor of unix so can't debug anything Apple related.
>
> Dan
>

Hi Dan,

I’m able to build on Mac OS X again! Several patches are needed (which makes development clumsy since we may not want all of them pushed). In any event, I’m happy to test a changeset for pdflatexstandalone.

Ben
12