Re: axis text do not plot

Nicholas Jankowski <[email protected]>
Newsgroups gmane.comp.gnu.octave.general
Message-ID <CABNpfR-qra=Fh=mzts8c+HrjvifmDmcj_Hj9rpb0ezfEQ3xzuA@mail.gmail.com>
On Mon, May 3, 2021 at 10:58 AM Nicholas Jankowski <[email protected]>
wrote:

> On Mon, May 3, 2021 at 9:00 AM Bjørn Kvamme <[email protected]> wrote:
>
>> Thank you very much for the reply Nicholas
>>
>> Here is the datafile enclosed
>>
>>
>  and the results regarding your versions and the results of
> graphics_toolkit and trying other toolkits?
>
>
ok, absent any more details about what is actually happening on your end,
here's my guess:

Octave seems to not currently support the facecolor option passed to meshc
in this way.  It may be a bug, not sure.  Matlab seems to allow it and the
color gets passed to the underlying surface object as the help suggests it
should. Octave seems to try to assign that property to the 'property group'
that meshc creates, and a group doesn't get a facecolor.  in any case, even
in matlab setting the facecolor of the underlying surface object doesn't
seem to change appearance at all.

in any case, you failed to mention whether you get an error when running
the meshc command, which I now see. it appears that this error interrupts
proper handling of the graphics properties.  subsequent calls to xlabel,
etc. are then unpredictable.  when running gnuplot as your graphics toolkit
(which is again my best guess of what you're doing) this appears to break
the ability to do follow-on labels, etc., altogether. with qt or fltk, I'm
still able to apply labels.

best immediate fix:  switch from gnuplot to qt, and drop the facecolor
statement. i'll see if it warrants a bug report on the facecolor issue.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.