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

[Daniel J Sebald]

On 03/03/2012 03:59 PM, Mike Miller wrote:
> Dmitri, thanks for testing this.
[snip]
> I don't get the "substituting Courier for {}", my ghostscript just
> dies.  Which is the right way?  Maybe I'll try gs 9.04 or other
> versions, or see if it's how gs is configured for Debian.
>
> > So from one hand perhaps it is not a good idea to write postscript file
> > with the fonts named "{}", but from the other hand I am not convinced that
> > resulting postscript is "illegal". What if you asked for the font that just not
> > available on your system?
>
> Good point.  I get the same ghoscript error if I set an unknown font
> name in octave first.

I see what you are saying, Mike's version of ghostscript is not very 
robust.  I'm not sure, but perhaps there is some configuration switch to 
allow or disallow font substitution.


> > But I do think that octave should setup some reasonable default.
>
> Definitely, otherwise octave cannot build docs from a clean hg source
> on my system.  This is how I first ran into this problem, part of the
> build uses octave to generate png files for the docs, that stage of
> the build is continually failing for me, I have to "make -i" in the
> doc directory to finish the build.

I second that sentiment.  There's no such font as {} and a PostScript 
file should be self-consistent.

I think the easiest thing for Mike to do right now, until a fix works it 
way through upgrades, is to simply add a line like:

set(0, 'defaultaxesfontname', 'Helvetica')

inside his Octave startup script file, using the font of his choice for 
consistency with the rest of the text.  That should produce EPS files 
without missing fonts (if you have the specified font on your system).

The other matter is why Octave is doing this, as Mike did find the hunk 
of code responsible.  I'm guessing David put that in there because 
gnuplot has an enhanced text mode in which fonts can be chosen locally 
and that has some bracketed sort of syntax.  But in the case of axes 
fonts, the syntax is different:

set xtics { font "name{,<size>}" }

where the brackets aren't literally present but signify an option vs.

{/[fontname][=fontsize | *fontscale] text}

inside the font string in which case "{}" would mean nothing or default 
I suppose.

David, what were you thinking when you made this change?  Is an 
inconsistency in font selection for axes text and label text a 
complicating issue?  If so, it would be nice if gnuplot were more 
consistent regardless of the Octave fix.

Dan