Re: 3.6.1 produces eps files that are unusable on Debian wheezy

[Daniel J Sebald]

On 03/02/2012 07:23 AM, Mike Miller wrote:
> I've been unable to display or convert eps files produced by print (to
> gnuplot) with 3.6.1 on my Debian testing (wheezy) system, same result
> on dev branch.  If I take these files to an older RHEL5 system, files
> display fine.  This is most likely a problem with something else on my
> system, but I'm trying to understand the difference so I know where to
> look next.
>
> I've put some time into comparing the results with different versions
> of Octave and Ghostscript.  By diffing and manually editing the
> intermediate files I'm pretty sure I've narrowed the problem down to
> the font description for the plot axis tickmarks.
>
> Octave 3.2.4 passes commands like the following to gnuplot:
>
>      set xtics border in scale  1.4 mirror  font ",12";
>
> which gnuplot turns into this snippet in the resulting eps file:
>
>      [ [(Helvetica) 120.0 0.0 true true 0 (0.5)]
>
> Octave 3.6.1 and dev both do the following instead:
>
>      set xtics border in scale  1.4 mirror  font "{},20";
>
> which passes through gnuplot into the eps file as:
>
>      [ [({}) 200.0 0.0 true true 0 (0.5)]
>
> Is this correct so far?  What is the meaning of the "{}" in a font
> declaration like this?  At which stage is it supposed to be
> interpreted into a valid font?  I'm not a PostScript expert, is this
> supposed to be valid PostScript and there's a problem with my versions
> of gs and evince?
>
> Every program available on Debian fails to render the eps files with
> "{}", for example gs 9.05 fails with "Error: /limitcheck in
> /findfont".  However, as I said at the start, if I move the files to
> RHEL5 with gs 8.15.2, no problem.  Or if I replace the {} with
> Helvetica, no problem.
>
> Any insight or tips on where to look next?

I just looked up the code for gnuplot.  If the font name consists of 
only ' ' or '-' gnuplot will use the current default font name.  So '{}' 
has no meaning as far as gnuplot is concerned other than it is expected 
to be some valid font name to the PostScript interpreter.

Therefore, Octave shouldn't be sending a '{}'.  My guess is that in 
updating the Octave code, perhaps cells of strings are now used and 
maybe the '{}' is coming about because of an empty cell.  Perhaps a 
conditional test was forgotten on an empty cell.  Just a guess.

I'm using a slightly older version of Octave, but the lines that deal 
with font are in __go_draw_axes__.m.

function fontspec = create_fontspec (f, s, gp_term)
  if (strcmp (f, "*"))
    fontspec = sprintf ("font \",%d\"", s);
  else
    fontspec = sprintf ("font \"%s,%d\"", f, s);
  endif
endfunction

As I say, I'm out of date, but I assume that hunk of code is still in 
the latest version somewhere.

I went to the latest code and browsed for how things are set up now. 
Here appears to be the hunk of code that constructs the string 
specification that ends up going to gnuplot:

opts_str = sprintf ("%s font \"%s,%d\"", opts_str,
    get (0, "defaultaxesfontname"),
    get (0, "defaultaxesfontsize") / 1.5);

Apparently plot '0' represents default.  On your system, please check at 
the Octave command line:

get (0, "defaultaxesfontname")
get (0, "defaultaxesfontsize")

I would guess that you should see '*' or a string of some font name.  If 
otherwise, please let us know what you see.  If there are errors, simply do

get (0)

and browse the entries for something pertinent.

Dan