Previous | Contents | Index |
You can use the following resolution setup modules to temporarily change the resolution on multiple resolution printers:
Not all of these setup modules are applicable to all printers. |
The printing system can produce both job separation pages (job burst pages, job flag pages, and job trailer pages) and file separation pages. The system manager can define the job separation pages and default file separation pages for the queue. Users cannot affect the job separation pages, but can control whether to print file separation pages.
Files in a print job can be separated by:
You can control the inclusion of file flag pages using the following PRINT command qualifiers:
You can specify the default file separation behavior for all files in a print job by placing the /[NO]BURST, /[NO]FLAG, and /[NO]TRAILER qualifiers between the PRINT command and the first file specification.
For example, the following command will print a file burst page before each file:
$ PRINT/BURST FIRST.TXT, SECOND.TXT |
If you do not specify the behavior for a type of file separation page (for example, the above command does not specify flag or trailer pages), the default behavior is as specified by the queue's /DEFAULT qualifier. If /DEFAULT does not specify a particular type of separation page, then none is generated.
The negated qualifiers (for example, /NOTRAILER), are useful in
overriding a queue's default qualifier (for example, /DEFAULT=TRAILER).
16.2 Controlling File Separation Pages for Individual Files
You can alter the default file separation page behavior for individual files within a print job by placing the qualifiers after the corresponding file specifications.
For example, you can use the following command to override a queue's /DEFAULT=BURST qualifier and instead print file flag pages for all but the second file in a job:
$ PRINT/NOBURST/FLAG FIRST.TXT, SECOND/NOFLAG, THIRD |
To see the default separation pages for a queue, enter the following command:
$ SHOW QUEUE/FULL PS20$A14 |
Printer queue PS20$A14, on STAR::LPS, mounted form DCPS$DEFAULT (stock=DEFAULT) /BASE_PRIORITY=4 /DEFAULT=(FLAG,FORM=DCPS$DEFAULT (stock=DEFAULT)) /NOENABLE_GENERIC /LIBRARY=DCPS_LIB Lowercase /OWNER=[SYS,SYSTEM] /PROCESSOR=DCPS$SMB /PROTECTION=(S:E,O:RD,G,W:W) /SCHEDULE=(NOSIZE) /SEPARATE=(BURST,TRAILER) |
This display shows that the job burst pages and job trailer pages are printed for print jobs sent to this queue (/SEPARATE=(BURST,TRAILER)). File flag pages are printed by default, as indicated by /DEFAULT=FLAG, but can be overridden by PRINT command qualifiers.
The device control library includes an error handler to help debug
PostScript programs. The error handler prints the last partial page of
output, as well as information to help identify the error.
17.1 Including the Error Handler in a Print Job
The error handler is not automatically included each time a job prints (unless your system manager has changed this default). Therefore, you must explicitly invoke it, as follows:
$ PRINT/SETUP=LPS$ERRORHANDLER filename |
The error handler returns PostScript messages. You can send these messages to a file or printer by using the /PARAMETERS=MESSAGES qualifier as described in Chapter 18. For example:
$ PRINT/QUEUE=PS40$A10/PARAMETERS=MESSAGES=KEEP FILE.PS |
If you are developing PostScript applications, you can make the error
handler easier to access by defining a form to include the error
handling setup module, as described in Chapter 14.
17.2 How the Error Handler Affects the PostScript Environment
The error handler references operators from the dictionary systemdict, rather than using definitions that may have been modified by the user program.
In some cases, a program can behave differently when the error handler
is loaded. For example, executing the exit operator
outside a looping context causes an invalidexit error
if the error handler is not loaded. However, if the error handler is
loaded, the program exits without generating an error.
17.3 Error Handler Example
The sample log file in Example 17-1 is for the following PostScript program:
[/1st-level [/2nd-level [/3rd-level [/4th-level 56 ] ] ] (end)] /myproc { [ 8 8 ] 0 0 div setdash } def 100 200 moveto myproc |
The following command includes the error handler and causes a log file to be generated:
$ PRINT/PARAMETERS=MESSAGES=KEEP/SETUP=LPS$ERRORHANDLER filename |
Example 17-1 shows the error handler output that is appended to the log file when the program executes.
Example 17-1 Sample Error Handler Log File |
---|
ERROR: undefinedresult (1) OFFENDING COMMAND: div (2) OPERAND STACK: (3) 0 0 [ 8 8 ] [/1st-level [/2nd-level [/3rd-level -array- ] ] (end) ] EXECUTION STACK: (4) { setdash } GRAPHICS STATE: (5) Current Matrix: [ 4.16667 0.0 0.0 -4.16667 0.0 3298.0 ] Color: 0.0 Current position: x = 100.0, y = 200.0 Line width: 1.0 Line cap: 0 Line join: 0 Flatness: 1.0 Miter limit: 10.0 Dash pattern: [ ] 0.0 |
The array defined at the start of the example file is expanded three
levels deep. The innermost version of the array is represented simply
as --array--.
17.4 Reading Error Handler Output
When an error occurs, the error handler executes a showpagecommand to print the last partial page of output (see Example 17-1). It also gives the following information:
When you find an error in the PostScript code, you should modify the
application that produced the file, or inform the applications
programmer of the problem.
17.5 PostScript Data Output Format
PostScript data is easily identifiable, usually in the way the data appears in a PostScript source file. The error handler represents PostScript data as follows:
The PostScript language may be extended to include new data formats
that are unknown to the error handler. Data in unknown formats is
represented as two question marks followed by the name of the unknown
data format.
17.6 Determining Where the Error Occurred
It may be impossible to determine exactly where in the PostScript stream the error occurred, because the execution stack may not uniquely identify the context. In this case, you can add diagnostics information to the PostScript file. For example, if the error appears to be related to a showpage definition, modify your PostScript code as follows:
/myshowpage { (At the top of my showpage\n) print flush % some PostScript code (Just before real showpage call\n) print flush showpage } def |
This chapter describes how to interpret messages and solve problems
with printing on PostScript printers. If the problem cannot be solved
without privileged authority, see your system manager for help.
18.1 Displaying and Saving Error Messages
To detect, understand, and solve problems with print jobs, gather information about the print job as it is processed. The following list describes some ways to gather the information:
$ PRINT/PARAMETERS=MESSAGES=PRINT MYFILE.PS |
$ PRINT/PARAMETERS=MESSAGES=KEEP MYFILE.PS |
Interpreting print job messages can help you to solve print job problems and to submit more successful and efficient print jobs.
You should try to determine the source of messages. Some messages come from the PostScript code in the printer (see Section 18.2.1).
Messages often come from the DECprint Supervisor software. The file you are printing or the OpenVMS system can send messages (see Section 18.2.2).
If you print to a PrintServer printer, you can receive messages from
the PrintServer Supporting Host software (see Section 18.2.3).
18.2.1 PostScript Errors
PostScript errors can be identified by the phrase "offending command is name".
The PostScript printer contains a PostScript interpreter that translates PostScript code into mechanical functions that transfer the data onto the physical page through marking functions.
Many applications generate PostScript files, and many types of printers print in PostScript. Files and printers are not always completely compatible.
You can solve some PostScript printing problems using the techniques described in Section 6.6.
If your application generates PostScript Level 2 files, you need a printer that supports PostScript Level 2. PostScript Level 1 files can be printed on both PostScript Level 1 and Level 2 printers.
If a PostScript error is generated from printing non-PostScript files, the application that generated the files should be modified.
Virtual Memory Errors
Not all PostScript printers are capable of printing all PostScript images and documents. Depending on what type of printer you are using, certain PostScript files may or may not exceed the printer's virtual memory limitations. The success of printing these files depends largely on:
If your print job fails to print because of a virtual memory limitation, you receive the following error:
%DCPS-W-VMERROR, vmerror: PostScript virtual memory exhausted - offending command is string. |
You can do one of the following to fix the problem:
Messages from the DECprint Supervisor software start with the prefix DCPS. These messages and the actions you should take when they indicate problems, are described in Appendix A.
The OpenVMS system provides the queue manager for the OpenVMS
batch/print queuing system. When your print job stops or is terminated
by the queue manager, it sends OpenVMS messages to your terminal. When
you have enabled message notification by including /NOTIFY in your
PRINT command, you receive messages from both the OpenVMS queue manager
and the DECprint Supervisor software.
18.2.3 Solving PrintServer Software Problems
The PrintServer Software provides the management of PrintServer
printers and sends messages to indicate when print jobs encounter
problems. You can use the Remote Console facility or the Printer Status
monitor to check the current status of the printer.
18.2.4 Problems with Files Generated on a PC or Macintosh System
Files generated by PC or Macintosh applications may be incompatable
with your printer or DCPS. See Section 4.3 for more information.
18.3 Getting Help On Line
If you receive error messages about your PRINT parameters, use the HELP command to ensure that you are using valid values. You can get help about the PRINT parameters by entering the HELP PRINT_PARAMETER command.
For those parameters that control printer-specific features, the HELP file lists the acceptable parameters. Enter HELP PRINT_PARAMETER followed by the parameter name (such as INPUT_TRAY). Then enter the name of the printer model.
For example, to display a list of the input tray values for PrintServer printers, enter the following command:
$ HELP PRINT_PARAMETER INPUT_TRAY PRINTSERVER |
PRINT_Parameter INPUT_TRAY PrintServer_Printers +-------------------------------------+ | Input tray | PrintServer | | Values | 20 | 32 | 40 | 17 | +-------------------------------------+ | MANUAL_FEED | | | | X* | | NOMANUAL_FEED | | | | X* | +-------------------------------------+ | BOTTOM | X | X | | X | +-------------------------------------+ | TOP | X | X | X | X | +-------------------------------------+ | ENVELOPE_FEEDER | | | | X | +-------------------------------------+ | LCIT | X | X | X | X | +-------------------------------------+ | MIDDLE | X | X | X | | +-------------------------------------+ * With PrintServer Supporting Host V5.0 |
Previous | Next | Contents | Index |