[Scribus] scribus optionally use acroread to print to postscript

[Craig Ringer]

On Wed, 2004-09-01 at 15:47, Zhang Weiwu wrote:

> I checked that you are right, my printer only support PS2. However 
> ghostscript seems have difficulties producing PS2 file there. It's 
> another story though, I'll look into the problem later.

Speaking of PostScript printing issues, I seem to be running into one
myself. My printer is a Xerox DocuPrint N4025 network laser with a
licensed Adobe PostScript 3 engine. It seems to be choking on the job
I'm working on now. If I manually cat the PostScript file to the printer
(netcat is wonderful), I get the following error:

[craig at bucket craig]$ nc xerox.localnet 9100 < /tmp/ppage.ps
%%[ Error: limitcheck; OffendingCommand: filter ]%%
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%


The offending filter command may be:

/DeviceGray setcolorspace
currentfile /ASCIIHexDecode filter /FlateDecode filter /ReusableStreamDecode filter
78DAEDDD8D7A55B91125D0F3FE2F7D92AF016303FEBF92AA76ADD53D9964921E8C5455D2B62E705D00
0000000000000000000000000000000000000000000000000000000000000000000000000000000000

(large amounts of encoded binary follow).

I've uploaded the PostScript file (9.3MB) to if anybody is brave enough
to download and examine it. You can grab that here:
http://www.postnewspapers.com.au/~craig/scribus/ppage.ps.bz2
The document and all dependencies (13MB) can be found here:
http://www.postnewspapers.com.au/~craig/scribus/pdfs/post_front.tar.bz2
though you'll want the slightly newer .sla file (171KB) from here:
http://www.postnewspapers.com.au/~craig/scribus/postfront.sla (Note: My
ancient Apache seems to want to send text/plain for .sla at the moment,
so be warned).

Note that after I run the output through ps2ps (not using any extra
options) it is printed fine (well, on the wrong paper size, but that's
something to examine later and could be my printer's fault).

I also seem to be able to print out simple files (both text and shapes)
fine. I'm presently trying to produce a testcase, but thought I'd
provide this info now.


This reminds me - it would be interesting to have a print option
instructing the printer to print an error report if something goes
wrong. That's something I've made extensive use of in Quark, especially
when dealing with flakey EPS files from clients, and it can make a huge
difference when trying to identify the guilty object on a document.


Examining this PostScript file has also shown me something else that I
can really only view with delight, though it really should've been
obvious to me. Despite the fact that it rasterises them for inclusion in
direct PDF output, Scribus emits EPS files literally embedded in
PostScript output. That, of course, means that one of the bigger issues
with using Scribus at the POST for page layout has a workaround - we can
output ads as EPSs and place EPSs on the pages, then print and distill
with Acro Distiller just as we do currently. When we get supplied PDFs,
we can convert them to EPS with Acrobat - just like we do now with Quark
- and embed the EPS files.

Is it as nice as using the PDF export in Scribus? No way. Does it work -
it looks like it should work and work well, and solves the problem of
rasterised embedded EPS and PDF documents.

Also, with Scribus's EPS export, it's realistic to look at Scribus for
ad layout in the reasonably near future. Ad layout is easier since most
of our ad layout doesn't involve large bodies of text so it avoids
performance and typesetting limitations with large amounts of text.

Things are also looking better than I'd expected for use in page layout,
especially since I have that workaround for embedded PDF/EPS files being
rasterised.

While I'm often more visible for bitching about limitations, I am
_seriously_ impressed by this app.

--
Craig Ringer