Re: printing problems because of memory consumption of gs

[Philip Nienhuis]

Doug Stewart-4 wrote
> On Mon, Jan 12, 2015 at 1:45 PM, Torsten <

> ttl@

> > wrote:
> 
>> On 04.01.2015 16:40, Torsten wrote:
>> > With a recent build from the gui-release branch I encounter the problem
>> > that printing a figure (gnuplot) starts a gs-process that consumes up
>> to
>> > 2 GB of memory. This makes it nearly impossible to build the docs on a
>> > computer with only 2 GB. Plotting directly in gnuplot with an eps-,
>> pdf-
>> > or png-terminal is no problem. Is anyone else seeing this issue?
>> >
>>
>> If someone else runs into this: I found the reason and a workaround for
>> the issue described in my previous post. The problem bulding the docs
>> seems to be that the produced eps-files (voronoi.eps, triplot.eps, etc.)
>> have text entries of the form
>>
>>   [ [({}) 200.0 0.0 true true 0 (0.2)]
>>   ] -66.7 MRshow
>>
>> with a font '{}'. Debugging gs shows that gs can not find font '{}' and
>> then queries all system fonts. This action then consumes much resources.
>> This can be avoided by
>>
>>   export GS_OPTIONS='-dNONATIVEFONTMAP -sSUBSTFONT=Helvetica'
>>
>> which prevents using native fonts and replace all unknown fonts by
>> Helvetica.
>>
>> Torsten
>>
>>
>  Thanks
> 
> This fixed the problem I was having since early Dec.
> 
> How can we make this automatic?

Q&D solution:

setenv ("GS_OPTIONS", "-dNONATIVEFONTMAP -sSUBSTFONT=Helvetica");

in .octaverc ?

That is one way I adapt PATH and other environment settings (on Windows, but
works on *nix as well).

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/printing-problems-because-of-memory-consumption-of-gs-tp4667988p4668120.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.