[gs-bugs] [Bug 688318] Several bugs in gsnup

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Mon Jul 27 06:52:28 PDT 2009


------- Additional Comments From masaki.ushizaka at artifex.com  2009-07-27 06:52 -------
Gsnup.ps has many limitations by its nature.  Basic idea is to employ BeginPage/EndPage, so if a job 
replaces one or both of these, it will not work.  For example, a print job generated using HP's PPD files 
may contain original EndPage definition, and in that case it does not work with gsnup.ps.
Gsnup.ps do not directly work with PDF/EPS files.  Because Ghostscript's special way to treat those file 
types conflicts with BeginPage/EndPage.  And, I don't think there is much BeginPage/EndPage can do 
about it.
However, there are workaround for these.
To gsnup PDF files,  you can:

  (cat lib/gsnup.ps; pdf2ps examples/annots.pdf -) | gs -sDEVICE=ppmraw -o x-%d.ppm -

And, to gsnup EPS files, you can:

  cat lib/gsnup.ps examples/golfer.eps examples/golfer.eps examples/golfer.eps | gs -
sDEVICE=ppmraw -o x-%d.ppm -

(Well, tiger.eps still has a problem from clippath, see below.)

Gsnup.ps does not clip current subpages to its subpage area.  This is a limitation inherited from 
previous versions.  I agree gsnup should clip its subpages, but this is not the only problem regarding to 
subpage positioning as original reporter described in issue #5.  And I intentionally left untouched #5 
this time.
Because it lacks clipping subpages, a job employs clippath most likely not to work correctly.  For files in 
examples folder, snowflak.ps, tiger.eps, vasarely.ps and waterefal.ps uses clippath and do not work 
with gsnup.ps.

There is also a possible Ghostscript problem when switching paper sizes between subpages, which I am 
working on to open a new bug about it.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the gs-bugs mailing list