Conference 7.286::postscript_printing

What is "won't print correctly?"
Are errors generated?  Does the putput just not look the same?
Is the flaw the same from printer to printer? Does it make a difference
where the files come from and who prints them?
Can you supply an example of a file that fails so we can check it out?
(Post a POINTER to such a file so we can copy it.)

- tom]

    
    Also, has the customer attempted to print on ANY other printers besides
    QMS and Digital? HP, Apple or IBM? 
    
    Nancy
    

The output starts to print and will produce pages however the output will not
complete printing. I suspect that an error message is being proguced however it
it lost in the resulting "MESS" of output condensed into the last line of
overprinted output.

I'm finding this hard to explain so I will place the files in a directory on our
CSC node for you to copy and try for yourself.



The customer has only tried the QMS printers  to my knowlage.

The files are located on the CSC node RIPPER in the following directories 



Directory DUMPFILES:[LUCRE.ASX]

ASX_LIB.TLB;1       CONTRACT.DIR;1      FIN_ADVICE.DIR;1

Total of 3 files.

Directory DUMPFILES:[LUCRE.ASX.CONTRACT]

CONTRACT.MOD;1      CONTRACT2332.LIS;1

Total of 2 files.

Directory DUMPFILES:[LUCRE.ASX.FIN_ADVICE]

ADEFS_DATA.LIS;1    FSA_FINAL.MOD;1

Total of 2 files.

Grand total of 3 directories, 7 files.


The file ASX_LIB contains setup modules:-


Directory of TEXT library DUMPFILES:[LUCRE.ASX]ASX_LIB.TLB;1 on  3-APR-1997
11:45:23
Creation date:   3-APR-1997 11:02:18      Creator:  VAX-11 Librarian V04-00
Revision date:   3-APR-1997 11:13:59      Library format:   3.0
Number of modules:      2                 Max. key length:  39
Other entries:          0                 Preallocated index blocks:     11
Recoverable deleted blocks:      0        Total index blocks used:        1
Max. Number history records:      20      Library history records:        2

CONTRACT
FSA_FINAL

The data files that are used with the two reports are both in the directories
with the code for the setup modules. 

The problem is not that the reports will not print but with the alignment of the
output with the fields on the page.

This only appears to happen to DIGITAL printers that the customer has however
the only other printers that are used are the QMS printers.

I have tested these on printers being driven by both DCPS 1.3 and DCPS 1.4 and
the results are the same.

The alignment appears to be out but only on certain fields in the report. 

Well I hope that you will be able to make sence of all this.


Regards and thank you 

Paul Lucre

Tom 

>>What is "won't print correctly?"

The output dosn't look the same as the fields in the document do not align.

>>Is the flaw the same from printer to printer?

The output is consistant from printer to printer.

>>Does it make a difference where the files come from and who prints them?

The results are the same regardless of who prints the reports.

The difference appears to be the printers.

>>Can you supply an example of a file that fails so we can check it out?

Refer the previous note for the pointers.

Nancy

>>Also, has the customer attempted to print on ANY other printers besides
>>QMS and Digital? HP, Apple or IBM?


I have just confirmed that the customer has not tried any other printers other
than QMS and Digital.

I have tried several Digital printers in the CSC. 

These are LPS17/600 LPS20 LN17PS Declaser 3500.

All of these were using DCPS and all produced a consistant result.

Paul 

I'm having trouble recreating your problem from the files presented.

Please do a SHO QUE/ALL/FULL for the system/printer in question
and post the results here.
Also, show us your PRINT command.

Thanks....

- tom]

Tom 
As requested the printer commands and results of the SHOW queue/full for the
print jobs.

I don't have access to a LPS32 so I have had to use the LPS17 LN17PS and
DEClaser 3500 however the results of the testing are consistant with the
customers LPS32 results.

Printing the Contract report.

 print/queue=csc$lps17/setup=CONTRACT - 		         

       DUMPFILES:[LUCRE.ASX.CONTRACT]CONTRACT2332.LIS/param=data=post


Printer queue CSC$LPS17, busy, on RIPPER::"decnet/medd",
mounted form DCPS$DEFAULT (stock=DEFAULT)
  <CSC Printserver LPS17, SNO2-3>
  /BASE_PRIORITY=4 /DEFAULT=(FORM=DCPS$DEFAULT (stock=DEFAULT))
  /NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYS,SYSTEM]
  /PROCESSOR=DCPS$SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
  /SCHEDULE=(NOSIZE) /SEPARATE=(FLAG)

  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
    183  CONTRACT2332    LUCRE           390  Printing
         Submitted  4-APR-1997 13:07 /FORM=DCPS$DEFAULT (stock=DEFAULT)
         /PARAM=("DATA=POST") /PRIORITY=100
         File: _$1$DUA80:[DUMPS.LUCRE.ASX.CONTRACT]CONTRACT2332.LIS;1 (printing)
             /SETUP=(CONTRACT)

  "DCPS$CSC$LPS17_DEVCTL_CACHE" = "1"
  "DCPS$CSC$LPS17_OLD_ANSI_PAGE_SIZES" = "TRUE"
  "DCPS$CSC$LPS17_PARAMETER" = "sides=2,data=auto"





The printout is produced however the account number in below the box for it.

The first page has the address block repeated on the bottom of the page 

The page numbers are not in the box and the date is printed below the date
heading and not in the box on the form.

The account total is not in the box but is printed below it.

The fin_advice report 


print/queue=csc$lps17/setup=FSA_FINAL -
     DUMPFILES:[LUCRE.ASX.FIN_ADVICE]ADEFS_DATA.LIS;1/param=data=post

Printer queue CSC$LPS17, busy, on RIPPER::"decnet/medd",
mounted form DCPS$DEFAULT (stock=DEFAULT)
  <CSC Printserver LPS17, SNO2-3>
  /BASE_PRIORITY=4 /DEFAULT=(FORM=DCPS$DEFAULT (stock=DEFAULT))
  /NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYS,SYSTEM]
  /PROCESSOR=DCPS$SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR
  /SCHEDULE=(NOSIZE) /SEPARATE=(FLAG)

  Entry  Jobname         Username     Blocks  Status
  -----  -------         --------     ------  ------
    198  ADEFS_DATA      LUCRE            70  Printing
         Submitted  4-APR-1997 13:26 /FORM=DCPS$DEFAULT (stock=DEFAULT)
         /PARAM=("DATA=POST") /PRIORITY=100
         File: _$1$DUA80:[DUMPS.LUCRE.ASX.FIN_ADVICE]ADEFS_DATA.LIS;1 (printing)
             /SETUP=(FSA_FINAL)


Again the printout is produced but the alignment is not correct.

I can send you a sample of the output if you give me a facsimile number.

I hope this will answer your questions and i'm confused as to why you don't see
the same results.

Thanks and regards

Paul 

Well, it does seem clear that the files do cause printing to come up in the
wrong place on the forms.
The only evidence that I can find as to a possible cause is that the data's 
position is critically related to the line ending codes in the data file.

If I edit the data file, its RMS record format changes from VFC to a 
more ordinary text file.  Using the edited file causes repositioning
and overprinting of the lines on the form, but few are in what I can 
identify as the right place.

Printers do differ in how they handle line ending codes in PostScript's
readline operation, but PrintServers are already as different 
from DEClasers as printers are likely to get in this regard.
Still, if the QMS printer (which I don't have an instance of to cross-test)
handles them differently, this may be the base of the matter.

The address block seems to be imaging twice as far down the page
from the set origin as it should.  This is consistent with line ending
codes being double-counted, as CR-LF being counted as CR and LF on separate
lines.

Do the data files have to be created as VFC files?

- tom]

Tom 

IF you can suggest a better file type that will produce the results then I will
push it with the customer. 

After all converting it from one type to another could be done with an FDL
convert in the command procedure that produces the files and then prints them.

I would welcome your suggestions as to how to proceed.

Regards

Paul 

> IF you can suggest a better file type that will produce the results then I will
> push it with the customer. 

Well, it appears that the system in place worked at one time.
Whether it had to be initially tuned to work at all with the files 
that happened to be created with VFC isn't clear.
I'm guessing that the forms application was written to support the data
application, perhaps a FORTRAN or COBOL legacy system?

The PostScript code seems sensitive to the presence of form feeds 
and the position of line ending codes, but I can't really decode it all 
to that level.

Given that it seems to work ONLY on one brand of printer, will the customer
consider a system re-write, perhaps with a real forms package?

- tom]

Tom 

The forms are generated on a PC tool called formtool. 

They have asked for our (Digital) guidlines on how to construct these forms so
that they can avoid being locked into the one brand of printer (QMS). 

If you can suggest a better way of doing this I.e. a better tools or form design
package the customer will listen.

The situation is that if we can show the customer his reports printing then he
will adopt the method that was used to produce the result.


What tools did you have in mind?

Regards 

Paul 

Well, I don't know the forms tool market all that well, but I can see
that the methods used for these files are somewhat hacky in their use
of PostScript to read preformatted data and print it as if it were ASCII.

The model in use here is to print ASCII data as if there were a preprinted 
form loaded into the printer.  Positioning of data is done with (essentially)
line feeds and leading spaces on the lin. This means that slight variations
in the printer's font can modestly corrupt the presentation, and variations
in how line ending codes are presented and interpreted can make BIG 
differences in how information is placed (the corrupt case at hand).

A more efficient to use forms model would be to integrate the placement
of data into the data to match an embedded form definition.
PostSCript level 2 (since 1990) has supported forms definitions that 
allow integrated representation of forms into a PostScript environment.
Alternatives to this customer's model exist, and if a rewrite is essential
(and I won't dispute that that would be expensive and disruptive),
more modern approaches that will better stand the test of time exist.
Unfortunately, I can't be more specific in a recommendation than that.

This is a good Digital Consulting opportunity.

- tom]

Tom 

Thankyou for the help on this problem I will talk to the customer and discus
altering the approach to the way this is done.

Your input has assisted me to understand the magnatude of the problem.

Thankyou for the assistance.


Best Regards

Paul