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