[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: printing problems because of memory consumption of gs
From: |
Philip Nienhuis |
Subject: |
Re: printing problems because of memory consumption of gs |
Date: |
Tue, 13 Jan 2015 10:54:01 -0800 (PST) |
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.