octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #44187] Bugs and modifications in print() with


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #44187] Bugs and modifications in print() with gnuplot graphics toolkit
Date: Sun, 08 Mar 2015 19:32:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #20, bug #44187 (project octave):

Attached is a revamped version of the patch that simplifies things and adds a
valuable demo to print() that illustrates what is available in terms of
toolkits, devices and how to use the output in an external application.

The simplification is that I removed all the code that simulates grayscale to
compensate for that missing behavior in gnuplot.  Instead, for now one just
gets what they get from gnuplot -mono or lack thereof.  Instead, I'd rather
fix gnuplot, as other Octave bug reports are coming in about rectangles
obscuring plots.  So there are several bugs to address in gnuplot and I'd
rather go the route of fixing more on the gnuplot side of things.  The
consequence is that Octave user doesn't get automatic mono conversion for a
few of the gnuplot devices, not a big loss as the user still has working color
and in the meantime can do one or two extra lines of Octave code to get
grayscale.

Other than the print demo, most everything else is bug fixes or
syntax/efficiency changes, except for these three moderate changes (which
themselves are kind of small):

1) Check for the availability of gnuplot terminal with mono/color options and
use accordingly.

2) Don't use the "png16m"/"pdfwrite" technique of generating output by
translating postscript in an external app.

3) Don't draw a rectangle behind the axes if it's color is the same as
background.  (If gnuplot is upgraded to fix these rectangle bugs, this can be
removed.  But I thought it annoying enough with current gnuplot to make this
fix for now.)

4) Use 'paperunits' and 'paperposition' properties to control the size of
gnuplot latex devices.

Regarding the last item, it seems to me that this family of properties:


>> set(gcf, 'paperunits')
[ centimeters | {inches} | normalized | points ]
>>  get(gcf, 'papersize')
ans =

    8.5000   11.0000

>>  get(gcf, 'paperposition')
ans =

   0.25000   2.50000   8.00000   6.00000



is the way to control vector- or units-based output like LaTeX rather than the
extra print option -S:


    `-SXSIZE,YSIZE'
          Plot size in pixels for EMF, GIF, JPEG, PBM, PNG, and SVG.
          For PS, EPS, PDF, and other vector formats the plot size is
          in points.  This option is equivalent to changing the size of
          the plot box associated with the "paperposition" property.
          When using the command form of the print function you must
          quote the XSIZE,YSIZE option.  For example, by writing
          "-S640,480".


The -S seems like the thing to do with pixel-based formats.

I used the paperunits/paperposition options in the "demo print" program to set
the output to 3"x5", and it seems to make sense in the processed LaTeX output.
 Without that control, the epslatex, etc. output of gnuplot was much too big
for any document.

So, please give the demo a try.  It is a good way of not only checking print
results, but also illustrating the finicky nature of qt/fltk windows and
printing with regard to program flow and cntrl-C behavior.  Type Cntrl-C at
various times (i.e., long running external postscript conversion) and check
for crashes, odd behavior, so on.  This is a realistic scenario of Octave is
used.  For example, run a simulation and display results in a plot every
iteration.

I'd appreciate help on cleaning up gnuplot quirks as well, but perhaps any
issues there can be put in new bug reports.  I've gone through most terminals,
but there are some for which my system tools are new enough to test.  For
example, the "tikz" devices really interest me, but it's too much of a hassle
to update to 2.0 or 3.0 at the moment.  (The process involves manually copying
all sorts of files into sub-libraries of texmf; there's no "install" process
for pgf/tikz.)  Here's a summary so far of gnuplot bugs I'm seeing:


gnuplot bugs:

  png terminal doesn't have mono setting and uses gnuplot's default color
palette, which doesn't match the 'qt' terminal plot
  gif    "
  jpeg   "
  jpg    "
  svg    "
  canvas "

  cairo terminal doesn't grayscale patches properly producing black for any
color
  eps       "
  epscairo  "
  pstex     "
        also, there seems to be an end missing from the TeX stream, but maybe
that is the way it is supposed to be

  tkcanvas a "-family" option is placed in the file when the font is empty,
i.e., "-font  -size 10", which results in an error.

  tikzstandalone seems correct but my versions of TeX packages are out of date
to test
  tikz             "
  pstricks         "

  cgm-to-tpic I haven't really implemented but if there is something there
someone feels useful I will do so


(file #33294)
    _______________________________________________________

Additional Item Attachment:

File name: octave-gnuplot_bugs44187_2015mar08.patch Size:28 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44187>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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