Re: Choosing graphics backend for documentation

[Rik]

On 07/27/2015 09:50 AM, Ben Abbott wrote:
>> On Jul 27, 2015, at 12:06 PM, Rik <address@hidden> 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