octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnuplot graphics toolkit bug fixes (was Re: Octave 4.0 is approaching...


From: Daniel J Sebald
Subject: gnuplot graphics toolkit bug fixes (was Re: Octave 4.0 is approaching...)
Date: Wed, 04 Feb 2015 19:29:59 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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?44187

Those 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_Release


Beyond 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]