Re: scs2pdf thoughts

On Mon, 11 Mar 2002, James Rich 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?

Actually, I was agreeing that if you used host print transform that you'd
lose the AFP stuff.  I was agreeing with you.

> > 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.

Parsing the 5250 data stream, and creating debugging info are probably the
biggest bottlenecks in lp5250d.   You could eliminate the debugging part
by compiling it with "NDEBUG" defined, but then you wouldn't be able to
create trace files or anything like that, so I discourage that :)

At any rate, lp5250d will always require more work than scs2pdf, since
it's considerably more complicated.

> 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.

Converted from 5250 to SCS.   From EBCDIC to ASCII.   From SCS to plain
text.  From plain text to postscript, and from postscript to PDF...
yeah, I can see why that's not the most efficient thing on earth :)

The difference while printing is noticble for me, tho I didn't benchmark
it as you did.  I've got an old P100 (but it's not running X or gnome or
mozilla) that's downloading this stuff.   I am using scs2ascii | enscript
| ps2pdf. Takes (very roughly) 1 second per page.

With scs2pdf, I don't even see it... once the report is released, it's
done.  Blam.   (Tho, I didn't do it with a report larger than 20 pages,
but still good I think)