Re: Continuing Octave graphics problems

[Sebastian]

Dear Vic,

I looked again at your files but I cannot help you. Sorry. I am not involved in 
the routines for exporting images from qt. Both, mac and windows version seem 
to have issues with your image. For compparison, I attach a screenshot (on the 
Mac) and the the pdfs that I have obtained using gnuplot and qt on mac/windows. 
I suggest that you open a bug report at savannah.

On my Mac pdf-export of gnuplot looks nicely, so this seems to be a good 
workaround for the moment.

Bye
Sebastian

P.S.: you should initialize the random generator in such test cases, otherwise 
the result might be always (slightly) different.

export_gnuplot_mac.pdf
Description: Adobe PDF document

export_gnuplot_win.pdf
Description: Adobe PDF document

export_qt_mac.pdf
Description: Adobe PDF document

export_qt_win.pdf
Description: Adobe PDF document

qtbug.m
Description: Binary data

QTBUG.mat
Description: Binary data

On 2016-07-29, Vic Norton <address@hidden> wrote:
> 
> Hi Sebastian,
> 
> Sorry to trouble you again. But, really, Octave graphics are a big
> bother to me. I can get presentable graphics from Octave
> in only one way. By setting
>   octave> graphics_toolkit gnuplot
>   octave> setenv GNUTERM qt
> and then by saving the graphics to a PDF file from the gnuplot_qt
> window. All other graphics routes produce nothing but a mess.
> 
> As you know I have complained about this problem before, on the Octave
> Maintainers list, but, after a brief flurry of activity, nothing has
> changed. Most Octave renderings of my work continue to be terrible.
> I am wondering, is it worth pointing out these problems again, or
> should I just let sleeping dogs lie? (to use a common American
> expression)
> 
> As I mentioned earlier, I am trying to write up my New Markowitz
> package: a package to aid in financial portfolio selection.
> 
>    ABSTRACT
>    We present a GNU Octave package to aid in financial
>    portfolio selection, with examples of its use on 2014
>    data. Our minnormy function, at the core of the package,
>    is a variation on Harry Markowitz’s critical line
>    algorithm.
> 
> I include example Octave scripts as part of my package. Unfortunately,
> of all the Octave graphic options available, only
>  octave> graphics_toolkit gnuplot
>  octave> setenv GNUTERM qt
> can produce reasonable output from my scripts, and this output can
> be saved in good form only if it is saved from the gnuplot_qt window.
> (No "print” command will work.)
> 
> I'd like some advice, Sebastian. I can't do anything about Octave's
> graphics problems other than to point them out. I know how to make good
> pictures with Octave, so I have no problems there. But I will be pushing
> graphics code to people who are not as familiar with Octave's
> idiosyncrasies as I am. It would be nice if they could also produce
> reasonable pictures from my code.
> 
> So what should I do? What is your advice, Sebastian? Should I just
> forget this problem and try to describe appropriate Octave fixes to my
> readers? Or is there someone who might be able to fix these problems?
> 
> Regards,
> 
> Vic
> 
> P.S. I am attaching the code I used to make the following pictures. The
> 5 KB "qt.m" file was extracted from the Octave scripts I present
> in my paper.
> 
> <octave-graphics-problems.tar.gz>
> 
> Here are the pictures.
> 
> 
> The first picture is the good one that I present in my paper. It was
> produced by
>  octave> graphics_toolkit gnuplot
>  octave> setenv GNUTERM qt
> and saved from the gnuplot_qt window. It takes up 128 KB.
> 
> 
> <octave-gnu_qt-saved_from_gnuplot_qt_window.pdf>
> 
> 
> 
> Here is exactly the same picture but saved with the Octave print command.
> It weighs 122 KB and is clearly neither understandable nor publishable.
> 
> <octave-gnu_qt-saved_with_print_command.pdf>
> 
> 
> 
> This picture was produced by
>  octave> graphics_toolkit qt
>  octave> qtbug
>  octave> print octave-qt-saved_with_print_command.pdf;
> It weighs 293 KB, and it is a mess.
> 
> <octave-qt-saved_with_print_command.pdf>