On 02/02/2015 11:14 AM, Rik wrote:
> The Octave Team is beginning the release cycle for Octave version 4.0.
> This is a major release which will include a GUI as the default interface,
> support for object oriented programming techniques using classdef syntax,
> and pre-built and tested binaries for the Windows operating system.
>
> But we can't get there without your help! We will need assistance in
> finding, reporting, and fixing bugs;
I've fixed some bugs in the gnuplot graphics toolkit which should make
the printed files much nicer for use in documents:
https://savannah.gnu.org/bugs/index.php?44187Those who have been working on gnuplot-related issues as of recent,
please review. I think this should be a 4.0 item and added to this list:
http://wiki.octave.org/Bug_Fix_List_-_4.0_ReleaseBeyond that, here are some gnuplot graphics toolkit issues that I'll
raise--some worth considering and some perhaps pie-in-the-sky.
1) I see use of "mono" and "color" in the graphics code. Of course,
"mono" stands for "monochrome", and that's what it means, correct? I
just want to confirm that users aren't expecting "mono" to mean grayscale.
2) Currently conflicting options are allowed for the print function, e.g.,
print ('footest-conflict-cairo.png', '-dpngcairo', '-mono', '-color');
works. Should it work or declare some type of error?
3) In the pipe dream category, would it make sense to somehow parse
gnuplot output with regard to terminal features? For example, gnuplot
command "help term" lists the available terminals. "help termxyz" will
show syntax which could be searched for "mono" and "color". Not the
easiest sort/search, and using gnuplot's help as a reference isn't the
most reliable, but it is pretty good. The advantage is not having to
modify code for added gnuplot terminals and some terminals which are
optional builds depending upon what libraries are on the user's system.
Disadvantage is programming headache.
4) Could we move the aliasing function:
function aliases = gs_aliases ();
## Aliases for other devices: "bmp", "png", "tiff", "tiffn", "pdf",
## "ps", "ps2", "psc", "psc2"
##
## eps, epsc, eps2, epsc2 are not included here because those are
## are generated by the graphics toolkit.
aliases.bmp = "bmp32b";
aliases.pdf = "pdfwrite";
aliases.png = "png16m";
aliases.ps = "ps2write";
aliases.ps2 = "ps2write";
aliases.psc = "ps2write";
aliases.psc2 = "ps2write";
aliases.tiff = "tiff24nc";
aliases.tiffn = "tiff24nc";
endfunction
and the place it is used to somewhere else, say specific to the graphics
toolkit? I'd much rather have the (gnuplot) graphics toolkit create PNG
if available, for example, and I've in fact done that in the bug-fix
changeset mentioned above (same for -dpdf). However, from an
organizational standpoint, this method of using EPS files through a
conversion utility, although creative, shouldn't be the norm.
5) Currently, the print() function does not allow multiple options
specification in one string. Multiple options have to be multiple
arguments to print(). E.g.,
% Doesn't work: print ('footest-color.png', '-dpng -color');
6) Looking at the help for print(), I think we should probably clean
that up a bit, or more like organize, and maybe do so for 4.0. The
issue is that there are descriptions of "-dpdf", "-dpng", and other
common terminals. But internal to the m-script files are many terminals
that aren't mentioned in help because they are, let's say, "non
standard". I'm thinking "-dpdfcairo", and so on. Notice that these are
defined in __print_parse_opts__.m, which would be at a level higher than
the graphics toolkit.
Should these terminals, especially the non-standard ones, be described
in documentation associate more with the graphics toolkit? How could we
get such documentation into the help dynamically? Or, could we mention
in the help for print() that to get a full list of terminals, see "help
graphics_toolkit_{name}" where {name} is described by one of the terms
of available_graphics_toolkits? Then we could have script files like
graphics_toolkit_gnuplot.m which only contain help information and no
functionality. Or there is always something like "graphics_toolkit()"
listing the available file formats/terminals that can be used with print().
Dan
Locked
