Re: scs2pdf thoughts

On Mon, 11 Mar 2002, Scott Klement wrote:

> Actually, this same method works fine with lp5250d & scs2ascii.  I just
> posted a message with a sample config (approx 1 minute ago)

Right, I saw that.  As I mentioned earlier, I think scs2pdf is more
complete than both scs2ps and scs2ascii.  You should get more accurate
printouts with scs2pdf (and if you aren't let me know).

> I'm 99% confident that IPDS and AFP would not work in this scenario.

Why not?  Aren't IPDS and SFP documented somewhere?

> Unless...  Is there a way to get Host Print Transform to output
> PostScript?  That would make the graphics work as well.
>
> > I had planned to add IPDS type stuff to scs2pdf so that it could print
> > signatures, graphics, etc.  No reason why scs2ps couldn't do the same.
> > I don't think this could be done if it had to be converted to ASCII
> > first.
>
> If you convert it to plain ASCII text, then it couldn't do the graphic
> stuff.  If the AS/400 was able to output PostScript, however, that would
> solve the problem.

I was saying that if Host Print Transform was used to convert an IPDS
print file to ASCII then you would lose the IPDS stuff in it.

> Otherwise, you'd need something that actually understands AFP.  If your
> program could be made to understand AFP, that would be awesome!  (But
> probably a lot of work)

That is what I was suggesting.  It would be awesome, and a whole lot
cheaper than an IPDS printer.  Anyone know where AFP/IPDS print stream is
documented?

> One thing about scs2pdf that I like better than the enscript/ps2pdf thing
> is that scs2pdf runs a WHOLE LOT faster, requires a lot less system
> resources, etc.

Good to hear.  But that only makes sense:  enscript/ps2pdf is two
conversions, scs2pdf is really none.  And scs2pdf is simple code.  It
should run really fast.  I did some investigating since we use scs2pdf on
some big print files and found that the system (unix box) spends most of
its time in lp5250d, and almost none in scs2pdf.  I'm guessing that is
because lp5250d is copying data from the network socket to stdout.  Here
is what I did (not fancy at all):

1.  Sent a 7,880 page spoolfile to my (lp5250d/scs2pdf - connected) PDF
printer.
2.  top reports that lp5250d uses about 40% of CPU, scs2pdf uses about 4%
3.  Total time is about 23 minutes, load average was about 0.53 on a not
very fast P233 running gnome and mozilla.
4.  Resent the same report to scs2pdf by feeding the raw printer output
directly to scs2pdf (i.e. lp5250d outputcommand=cat > /tmp/rawfile then
put that through scs2pdf: scs2pdf < /tmp/rawfile > /tmp/outfile.pdf).
That took less than two minutes.

Now of course the first was sent over the network and the second was all
on local disk so they aren't real comparisons.  The raw print file is
41311794 bytes and the resulting PDF file is 49742066 bytes.  What is
interesting is that lp5250d/scs2pdf didn't eat more CPU, especially
considering that the CPU was partly idle.  This probably means that the
unix machine could have received and processed more data faster if it had
been available.  Processing the output from scs2ps with ps2pdf takes far
longer.

I'm not sure if I'm saturating our network capabilities with this test or
if our iSeries just can't put data on the wire any faster.  At any rate,
the box I'm working on is not the limiting factor here, and this box is
puny.  I think that I could do three simultaneous print jobs like that and
not experience any slowing due to my box.  But I can't test that since I
only have one iSeries and it is on a 16 Mbps token ring segment.  But if I
had three all on the 100 Mbps switch that I'm on I bet it would scream.

James Rich
james@eaerich.com