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

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

[Octave-bug-tracker] [bug #53737] printing to svg gives error and no plo


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53737] printing to svg gives error and no plot with gnuplot 5.2
Date: Tue, 24 Apr 2018 15:33:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #19, bug #53737 (project octave):

@Rik: I noticed all your recent posts after the submitted changeset.  There
certainly could be condensation of the 

function f = font_spec (opts, varargin)

since the 


    case "pdf"
      if (! isempty (opts.font) && ! isempty (opts.fontsize))
        f = sprintf ('font "%s,%d"', opts.font, opts.fontsize);
      elseif (! isempty (opts.font))
        f = sprintf ('font "%s"', opts.font);
      elseif (! isempty (opts.fontsize))
        f = sprintf ('font ",%d"', opts.fontsize);
      endif


gets rather repetitive.  However, some of them scale opts.fontsize, and so on.
 To allow for possible tweaking, perhaps it is best to just leave them in
groups of similar terminals rather than going for the most condensed code. 
Doesn't matter to me much, but I think aiming for the most dense code might
introduce a few bugs and a big long list of terminals in a case statement.

Also, not sure if you noticed, but the "background" warning shows up quite a
bit, so in the patch I removed "background" whenever it was causing a warning
when I tested all terminals.  The thing that has me wondering is that no
matter what the figure "color" is set to the values reported to
__gnuplot_print__.m are always #ffffff, i.e., white.  Is there some upstream
code that is always forcing white when printing?  I'll guess that maybe Matlab
is putting some non-white background on by default (maybe a light grey?) but
when it comes time to print Matlab takes that color away.  However, as Octave
is doing this, it means one can't specify a color for the background at print
time.  Not a major concern, but one wonders why even have the background color
option sent to the __print_command__.m if all it is ever going to be is
(1,1,1)?  Would it make sense for 'color' to have some additional option?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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