Re: [LINUX5250] Re: lp5250d print transform question

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Wed, 27 Mar 2002 elmars.ositis@Vereinsbank.lv wrote:
>
> Today I tried some alternate methods...
>
> 1 - dump the printstream to a text file using outputcommand='scs2ascii >
> /tmp/testfile.txt'
>
> The output in the testfile had incorrect column spacing. when I did the same
> with the mfrtypmdl setting, the column spacing was correct but control codes
> were thrown into various places in the text.

Sounds like a bug in scs2ascii.  Could you send me some SCS output that
I could use to reproduce the problem?  Just do 'outputcommand=cat - >
/tmp/testfile.scs'?   Send the file to me privately, not to the mailing
list.

If you want to use the mfrtypmdl without the extra control codes, you
might try something like this:

printer {
     host = as400.example.com
     env.DEVNAME = PRT01
     env.IBMMFRTYPMDL = *WSCST
     env.WSCSTNAME = QWPDEFAULT
     env.WSCSTLIB = *LIBL
     outputcommand=scs2ascii>/tmp/testfile.txt
}

The output in testfile.txt here should just be plain text.  QWPDEFAULT
is an IBM-supplied object, so you shouldn't need to create anything.

>
> 2 - use scs2ps > /tmp/testfile.ps
>
> the result of this was a properly spaced ps file which I could print to a 
>laser
> printer or view with ghostscript. I did not need to enable any mfrtypmdl for
> this to work properly. Unfortunately I can't use this as I cannot print this 
>to
> the line printer, and laserprinting a few thousand pages per day is just a
> little short of expensive, and difficult to manage large groups of reports for
> storage. I tried printing the ps file to the line printer, producing somewhat
> nice results, but at 30 seconds per page on a 1200 line per minute printer...
> see above.

If speed is critical, fixing scs2ascii is your best bet.

>
> Does anyone have an idea where in the scs2ascii code I could find the
> error? or has anyone run accross this before and patched it?
>

scs2ascii isn't very big.  The way I would approach this is to output the
SCS data to a file (i.e. 'outputcommand = cat - > /tmp/testfile.scs') and
then insert some fprintf's into scs2ascii to see what scs2ascii is doing
at the point where the column spacing is getting messed up.   Most likely,
there is an SCS operation that we're ignoring instead of handling.
Alternatively, you could use gdb(1), to step through the code as it's
running...

Or send me the SCS data, and I'll take a look.