stripes in eps output

[Ruth Cerezo Mota]

Hi all!
I use the  Jasc Paint Shop Pro software to open
and edit my GrADs graphics, and with this
software I did not have any probles with
stripes...
cheers
Ruth Cerezo-Mota
**********************
University of Oxford
Atmospheric, Oceanic & Planetary Physics
Clarendon Laboratory
Parks Road
Oxford, OX1 3PU
U.K.
Tel (44)1865 272920
email: cerezo at atm.ox.ac.uk
***************************
> My experience has also been that EPS files
> generated from grads using
> gxps look just fine when printed in journals --
> most of my paper have
> GrADs images and I would not be using Grads if
> the images looked bad
> in print. I usually tweak and reformat graphics
> in Illustrator, which
> deals with the the lines just fine and makes
> very nice raster files
> if needed.
>
> The problem comes with looking at the EPS file
> (eg in ghostview or
> Preview) or when converting to a raster image.
> Since most images end
> up on the web as PNG, and not in print, this is
> important. Grad's
> printim does a decent job and is quick, but
> without a lot of control
> over image size and format. The solution is to
> turn of anti aliasing.
> Using +antialias in ImageMagick convert as
> Jeffery Gall suggests
> works reasonably well (convert actually calls
> gs), but then lines are
> rendered too thick and pixelated. If you specify
> a fine dpi, then
> scale down, you can get better line art while
> eliminating the
> striping. Compare these results on an eps
> generated with gxps (note
> I've added -trim to remove blank margins):
>
> convert -trim +antialias -density 150 test.eps
> test.png
> convert -trim +antialias -scale 25% -density 600
> test.eps test_scale.png
>
> <http://www.atmos.washington.edu/~salathe/Public/test.png>
> <http://www.atmos.washington.edu/~salathe/Public/test_scale.png>
>
> To do this, I use a grads script that calls a
> csh script that can
> handle any output format:
>
> Grads script saveimg in $GASCRP:
>
> function saveimg(file)
>
> * print screen to eps file specified as argument
>
>
> * first print to gx file
>
> 'enable print tmp.gx'
> 'print'
> 'disable print'
>
> * now translate to image format
>
> '! gxconvert tmp.gx ' file
> '! \rm -f tmp.gx'
>
> csh script in $PATH:
>
> #!/bin/csh
>
> if (! $#argv == 1) then
> echo "usage: gxconvert file.gx file.ext where
> ext indicates output
> format"
> exit
> endif
>
> gxps -c -i $1 -o tmp.ps > /dev/null
>
> if ($2:e == 'ps') then
> mv tmp.ps $2
> else if  ($2:e == 'eps') then
> ps2epsi tmp.ps $2
> \rm -f tmp.ps
> else
> convert +antialias -trim -scale 50% -density 300
> tmp.ps $2
> \rm -f  tmp.ps
> endif
>
> exit
>
>
> -Eric
>
> --
> Eric Salathé
> CSES Climate Impacts Group
> <salathe at washington.edu>
> University of Washington
> <http://www.atmos.washington.edu/
> ~salathe>
> 206-616-5351
>
> On Feb 8, 2007, at 12:27 PM, Matthias Munnich
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The trouble is that one of the most common
>> PostScript renderers,
>> Ghostscript (gs), is nowadays doing
>> antialiasing by default to soften
>> ragged lines and corners.  It blends
>> neighboring bit even for purely
>> horizontal lines.  This leads to the
>> pixel-width horizontal lines due
>> to the way Grads is filling contours.
>> Antialiasing can be turned of
>> with "-dGraphicsAlphaBits=1" in gs or
>> "-noantialias" in ghostview
>>
>>  I still don't  believe that hardcopy
>> publications are likely to show
>> lines.  These lines would be close to
>> invisible anyway  on a 1200dpi
>> printer .   I  suspect people are rendering
>> their graphics themselves
>> with tools like ImageMagick.  Almost any free
>> software is  using
>> Ghostscript as the rendering engine.  These
>> tools usually use default
>> Ghostscript settings and you get the lines.
>>
>> Well, Jennifer's email suggests otherwise.
>> Unfortunately  you do not
>> control how the graphic is rendered in print
>> and submitting a rendered
>> figure as suggested by Jennifer and Jeff is
>> one solution.  However,
>> you loose print quality.
>>
>> My approach would be to look through a recent
>> issues of JGR and see if
>> the figures show these lines.   I always
>> recognize grads plots -- I
>> guess I stared at too many by now.   I am
>> pretty sure it's fine to
>> submit gxeps created EPS files to JGR.   There
>> were no lines in the
>> figures of my recent GRL paper.
>>
>>
>> ... Matt
>>
>>
>>
>> Jennifer Adams wrote:
>>> Alan et al., Those horizontal stripes in the
>>> ps/eps output are a
>>> real nuisance. Potential sources of the
>>> problem start with the
>>> contouring algorithm in the GrADS graphics
>>> layer, but the presence
>>> of the stripes also seem to be influenced by
>>> gxps, gxeps, any
>>> external or internal utility that converts
>>> the .eps or .ps files to
>>> something else as they get incorporated into
>>> written documents, and
>>> the printers used by scientists and
>>> publishers also seem to be a
>>> factor. My recent experience is that it's
>>> nearly impossible to
>>> predict whether you'll get stripes or not.
>>> It's seems more likely
>>> that you'll have stripes than no stripes, and
>>> the stripes also seem
>>> to be most garish in plots with shaded
>>> contours and white space.
>>>
>>> Here at COLA, we've begun using image format
>>> files (.png and .gif)
>>> instead of vector graphic formats, simply
>>> because they're more
>>> reliable even though they don't always look
>>> as good.
>>>
>>> COLA users are being weaned from using PCs
>>> running MS Windows, but
>>> my sense is that the gv32 program allowed for
>>> conversion of GrADS
>>> metafiles into something else that did not
>>> have stripes. I can't
>>> verify that, perhaps the windows users out
>>> there can confirm or
>>> deny.
>>>
>>> Brian is planning to rework the contouring
>>> algorithm, so there's
>>> hope for the future; unfortunately, that hope
>>> doesn't help in the
>>> short term. I would see if you can get the
>>> publisher to provide a
>>> test print of your figures, and if that looks
>>> bad, see if you can
>>> use an image format instead. A .png at
>>> 850x1100 resolution, shrunk
>>> down to journal size, might not look so bad.
>>>
>>> Jennifer
>>>
>>>
>>>
>>> On Feb 8, 2007, at 11:03 AM, Alan Robock
>>> wrote:
>>>
>>>> Dear Friends,
>>>>
>>>> Has anyone found a solution to the age-old
>>>> problem of horizontal
>>>> lines between bands of color in shaded grads
>>>> output?  We have eps
>>>> files to submit for an accepted JGR paper
>>>> and are concerned about
>>>> how the final version will look.
>>>>
>>>> Is there anything we can do to the files
>>>> before we submit them to
>>>> fix the problem?
>>>>
>>>> Alan
>>>>
>>>> Alan Robock, Professor II Department of
>>>> Environmental Sciences
>>>> Phone: +1-732-932-9478 Rutgers University
>>>> Fax: +1-732-932-8644 14 College Farm Road
>>>> E-mail: robock at envsci.rutgers.edu
>>>> <mailto:robock at envsci.rutgers.edu> New
>>>> Brunswick, NJ 08901-8551
>>>> USA http://envsci.rutgers.edu/~robock
>>>>
>>>
>>> -- Jennifer M. Adams IGES/COLA 4041 Powder
>>> Mill Road, Suite 302
>>> Calverton, MD 20705 jma at cola.iges.org
>>> <mailto:jma at cola.iges.org>
>>>
>>>
>>>
>>
>>
>> - --
>> - --------------------------------
>> Matthias Munnich
>> Univ. of California, Los Angeles
>> Dept. of Atmos. and Oceanic Sc. and
>> Inst. of Geophysics and Planetary Physics
>> 3845 Slichter Hall
>> Los Angeles, CA 90095-1567
>> Phone: +1-310-794 5899
>> Fax: +1-310-206 3051
>> Email: munnich at atmos.ucla.edu
>> - --------------------------------
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2.2 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla -
>> http://enigmail.mozdev.org
>>
>> iD8DBQFFy4e7idaDTh/cfhYRAkhyAKDYrNmXqc5O4m5L+DWrypw/kvsk4QCgn2rl
>> Oo2eoszDJQ4TTyuFviUL6g0=
>> =/obd
>> -----END PGP SIGNATURE-----
>