[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: printing problems because of memory consumption of gs
From: |
Torsten |
Subject: |
Re: printing problems because of memory consumption of gs |
Date: |
Tue, 13 Jan 2015 07:07:56 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 12.01.2015 23:32, Doug Stewart wrote:
>
>
> On Mon, Jan 12, 2015 at 1:45 PM, Torsten <address@hidden
> <mailto:address@hidden>> 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?
>
This seems to be more a problem with gs on our systems (ubuntu 14.04 in
my case). Why does gs need 2 GB of memory when querying the available
system fonts? gnuplot itself includes the font into the generated
eps-file when plotting a diagram with eps terminal.
When using -FHelvetica in the print command, everything works as expected.
Torsten