octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Mike Miller
Subject: Re: 3.6.1 produces eps files that are unusable on Debian wheezy
Date: Sat, 3 Mar 2012 16:59:27 -0500

Dmitri, thanks for testing this.

On Sat, Mar 3, 2012 at 3:05 PM, Dmitri A. Sergatskov
<address@hidden> wrote:
> So now if I run gs 9.04:
>
> gs -sDEVICE=x11 miketest.eps
> GPL Ghostscript 9.04 (2011-08-05)
> Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.04/Resource/Font/StandardSymL.
> Can't find (or can't open) font file StandardSymL.
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.04/Resource/Font/StandardSymL.
> Can't find (or can't open) font file StandardSymL.
> Querying operating system for font files...
> Loading StandardSymL font from
> /usr/share/fonts/default/Type1/s050000l.pfb... 4065536 2745164 7891688
> 3779413 2 done.
> Loading NimbusSanL-Regu font from
> /usr/share/fonts/default/Type1/n019003l.pfb... 4209192 2800915 7891688
> 3469507 2 done.
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.04/Resource/Font/{}.
> Can't find (or can't open) font file {}.
> Didn't find this font on the system!
> Substituting font Courier for {}.
> Loading NimbusMonL-Regu font from
> /usr/share/fonts/default/Type1/n022003l.pfb... 4353056 2945640 7891688
> 3503298 2 done.
>>>showpage, press <return> to continue<<
>
> And it display the picture just fine.

So we get the same postscript results, just my system can't view them.
 Here's my full gs error output.

GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading StandardSymL font from
/usr/share/fonts/type1/gsfonts/s050000l.pfb... 3527720 2097367 4560096
3173614 2 done.
Loading NimbusSanL-Regu font from
/usr/share/fonts/type1/gsfonts/n019003l.pfb... 3590640 2231992 4620648
3233988 2 done.
Can't find (or can't open) font file
/usr/share/ghostscript/9.05/Resource/Font/{}.
Can't find (or can't open) font file {}.
Querying operating system for font files...
Error: /limitcheck in /findfont
Operand stack:
   -66.7   --nostringval--   0   --nostringval--   --nostringval--   {}
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--
--nostringval--   --nostringval--   false   1   %stopped_push   1910
1   3   %oparray_pop   1909   1   3   %oparray_pop   --nostringval--
1893   1   3   %oparray_pop   1787   1   3   %oparray_pop
--nostringval--   %errorexec_pop   .runexec2   --nostringval--
--nostringval--   --nostringval--   2   %stopped_push
--nostringval--   --nostringval--   --nostringval--   --nostringval--
 %array_continue   --nostringval--   1868   6   4   %oparray_pop
Dictionary stack:
   --dict:1161/1684(ro)(G)--   --dict:0/20(G)--   --dict:82/200(L)--
--dict:192/256(L)--
Current allocation mode is local
Current file position is 20791
GPL Ghostscript 9.05: Unrecoverable error, exit code 1

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.

> 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.

> May be it is up to binary packages maintainers to choose which one.

That would be fine too, but does not help with building the
documentation which runs octave out of the build directory without any
system configuration in place yet.

-- 
mike


reply via email to

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