On Tue, 20 Nov 2007, Scott Klement wrote:

IMHO, the stuff related to parsing SCS should remain in the SCS
programs. Remember: SCS is not the only printer language that the
system supports. We'll want to support AFP, IPDS, USER-ASCII, etc in
the long run.

Plus, I think it's really handy for debugging and development to be able
to dump the SCS data to a file and be able to analyze that file, and run
it through other tools like scs2ascii or scs2pdf later on.

I agree on both points.

Can scs2pdf simply save the settings it needs into a file on disk?

I thought about this. I just don't think it is a very elegant solution. The problems I see with this are:

1. What happens if the file is deleted between print jobs?
2. What security implications are there? Specifically, how do we avoid creating a file that someone has cleverly linked to an important system file, ownerships, etc.

This solution does provide for repeatability when piping raw SCS output to scs2pdf without using lp5250d during debugging sessions like you mention.

Personally, I would prefer that lp5250d remembered the settings. Then is could invoke the scs2* programs with command line arguments such as --pagewidth=X etc. This also provides for repeatability when debugging. But I can't come up with a nice way to do that. So barring some brilliant stroke of genius, I'll hack up a save to file method.

James Rich

It's not the software that's free; it's you.
- billyskank on Groklaw

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].