octave-maintainers
[Top][All Lists]
Advanced

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

Should octave pass an intentionally bogus font to gnuplot? (was: 3.6.1 p


From: Mike Miller
Subject: Should octave pass an intentionally bogus font to gnuplot? (was: 3.6.1 produces eps files that are unusable on Debian wheezy)
Date: Thu, 8 Mar 2012 08:32:07 -0500

On Sun, Mar 4, 2012 at 11:23 PM, Daniel J Sebald <address@hidden> wrote:
> On 03/04/2012 03:10 PM, Mike Miller wrote:
>>
>> I have found a resolution for why my ghostscript is failing with the
>> same file that works for everyone else.  Here is the gs command that
>> finally works for me with the original eps files:
>>
>> gs -sDEVICE=x11 -dNONATIVEFONTMAP<file>
>> [cut]
>
> My guess would be that Debian uses different compile switches and options
> than others.
>
> You say you aren't seeing "Substituting font Courier for {}."  Is
> ghostscript failing on the search for {}?  Perhaps since it is a rather
> meaningless font, ghostscript is searching and searching for a suitable
> font.

I've nailed down this part of the problem and, for those that are
interested in the details, reported it at [1].  It will not affect
RH/Fedora systems because they disable fontconfig support in their
ghostscript build.  I've uninstalled the problem font and gs is
working fine for me now.  I plan to investigate this further, but it
is clearly not octave-related, contact me off list if interested.

>> To me it seems like gnuplot is working correctly, I'd still like to
>> know the reason for the "{}" font name in octave in the first place,
>> but the real problem for me is back to ghostscript.  If someone sent
>> me a postscript file using a font that I don't have, I would get the
>> same error.
>>
>> Thanks for the help... still can't build from hg because of this though :)
>
>
> Why can't you build?  Is there some part of the process that creates an EPS
> file and tests whether it is valid?  Is there a build option to disable such
> a test?  One thing you could do after unpacking and before building is touch
> up your file so that

Yes, I could build either with --disable-docs or by uninstalling the
problem font.  I was more focused on testing the build with no
workarounds than just getting to a working state.

So the question for octave maintainers is still should octave be
passing a font name of {} to gnuplot?  What is the desired outcome of
this that is different from its previous behavior of passing an empty
string?  The only effective difference I see is that empty string is
turned into Helvetica immediately by gnuplot while {} is replaced with
Courier later by ghostscript (or user's choice with SUBSTFONT [2]).

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662892
[2] http://www.ghostscript.com/doc/current/Use.htm#Font_related_parameters

-- 
mike


reply via email to

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