[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Should octave pass an intentionally bogus font to gnuplot? (was: 3.6.1 produces eps files that are unusable on Debian wheezy),
Mike Miller <=