Question

Locked

Blank Page Suppression with SAP and Canon Print Devices

By TechGuy 35353535 ·
Hello,

I was wondering if anyone has heard of a solution for Blank Page Suppression for CANON print devices?

I know HP has the Blank Page Suppression DIMM that kills the FF(Form Feed) code at machine level, but Canon does not...

Any other ideas? My client doesnt want to redo their SAP forms.

I need to suppress the extra page from printing

HELP! lol thanks

This conversation is currently closed to new comments.

2 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Update

by TechGuy 35353535 In reply to Blank Page Suppression wi ...

Here is all the info I have dug up... I still have to test this, but I wonder if Im on the right track? Thanks Guys

FROM: http://groups.google.com/group/intel.networking_and_communications.network_print_products/browse_thread/thread/e652f714e34be056/2e876527681e188f?lnk=st&q=print+blank+Page+SAP&rnum=2&hl=en#2e876527681e188f

"UNIX systems with extra form feeds, usually, if you have the print queue setup as
LPTx_TEXT, changing it to LPTx_PASSTHRU will get rid of the extra page."

===============================================================================================================================



FROM: http://groups.google.com/group/intel.networking_and_communications.network_print_products/browse_thread/thread/233cec7351d15fc3/36d1fddb7e14bc46?lnk=st&q=print+blank+Page+SAP&rnum=10&hl=en#

"In most situations, changing the printer queue to PASSTHRU instead of TEXT will resolve
this issue."

===============================================================================================================================



FROM: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/core/fnbe_prn_creq.mspx?mfr=true
"Print Services for Unix sets the print data type when it sends the document to the spooler. This is derived from the control command included in a print job from an LPR client. It might be necessary to change the default data type at the client to avoid processing PCL or PostScript print jobs as TEXT when they are actually RAW. For more information about the data types, see "Print Processor" earlier in this chapter.

If the control command is f or p , the data type is TEXT, and the spooler edits the document file to print correctly. If the command is l , the data type is RAW and no editing is done. If the command is o , the document is already formatted in PostScript code and is assigned the RAW data type.

Some UNIX systems usually send the f command by default, resulting in the following symptoms:

? The output includes PCL or PostScript code.

? Extended characters are printed incorrectly.

? The printer's default font is used.

? An extra page is printed at the end."



===============================================================================================================================


FROM: http://groups.google.com/group/intel.networking_and_communications.network_print_products/browse_thread/thread/ef024dd70834c45a/e4d499da0f1ffa20?lnk=gst&q=nick+lancaster&rnum=1&hl=en#e4d499da0f1ffa20
"Again, because we do not support SAP*, I am just giving you suggestions as best as
I can. In a TCP/IP environment, the print queues are setup on the hosts either by
port numbers (3001, 3002, 2501) or by queue names of <PORT>_PASSTHRU or
<PORT>_TEXT, where <PORT> is either LPT1, LPT2, or COM1. PASSTHRU usually works,
unless you need a form feed, carriage return for a dot matrix printer, etc.


For example, in Windows NT* LPR printing, when you add a printer as an LPR port,
it asks for IP address and printer queue name. The printer queue name is where we
add the LPT1_PASSTHRU. In other UNIX systems, such as HP-UX, using its SAM
utility, LPT1_PASSTHRU is added as the queue name on remote host. "

Back to Peripheral Forum
2 total posts (Page 1 of 1)  

Related Discussions

Related Forums