Link to home
Start Free TrialLog in
Avatar of KNBsysteembeheer01
KNBsysteembeheer01

asked on

Printing from Exact Financials to Xerox ColorQube not working correctly

Dear experts,

I've been busting my head lately because of this problem.
What I try to achieve is to print the invoices from Exact financials to the Xerox machine.

Everything seems fine when I print only one invoice.  I can get it to print to the machine, tray 2 and a nice invoice comes out.

But when I try to print for example 20 invoices, the address on each invoice is moving up a little. I thought it must be something in the INIT-string but I've tried several things but nothing is working.

In the attachments you'll find a screenshot of the settings that are working fine except when I print more than 1 invoice.

Thanks in advance,

Len
Exact-universal.PNG
SOLUTION
Avatar of DansDadUK
DansDadUK
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of hdhondt
You did not specify which model ColorQube you have. They cover quite a range of different printers.

Xerox do provide PCL manuals for their products. They may help you trace the cause of the problem. Some of the manuals are at the following links:

CQ 8700/8900:
download.support.xerox.com/pub/docs/CQ8700/userdocs/any-os/en_GB/ColorQube_8700-8900_PDL_Guide.pdf

CQ 9201/9202
www.office.xerox.com/support/dctips/dc09cc0451.pdf

These manuals are very hard to find on Xerox' website. The easiest way to find them via Google. I found these by searching for:
pcl command site:xerox.com colorqube
With the information provided so far, we're just guessing at the reason for the reported symptoms.

What would be better (IF your application allows it) would be to provide a 'capture' of the output of a multi-invoice sample (using 'sanitised' data), like that provided by the 'Print to file' option in the Print dialogue of standard Windows applications.

Analysis of the resultant .prn file may very well show what the problem is.

You could post it here, or do the analysis yourself, using the PRN File Analyse tool in the PCL Paraphernalia application, available via http://www.pclparaphernalia.eu
Avatar of KNBsysteembeheer01
KNBsysteembeheer01

ASKER

here you find a capture with the use of print to file.
exactcs.txt
Not sure just what you've captured; a few comments based on (attached) analysis:

The captured data starts with an odd control-code character: Device-Control-2 - decimal code 18, hexadecimal 12, usually referred to as <DC2>.
The captured data shows no sign of the sequences defined in your 'init' or 'end' strings.
The data contains (once on each page) invalid PCL sequences (<Esc>*(s3B) which should probably have been <Esc>(s3B, intended to select a Bold variant of the current Primary font (whatever that is).
The text 'KOPIE FACTUUR' on each page is preceded by an orphan Escape character (decimal code 27, hexadecimal 1b), usually referred to as <Esc>
The pages are separated by Form Feed control-code characters (decimal code 12, hexadecimal 0c), usually referred to as <FF>.
Vertical spacing is achieved via use of multiple Line Feed control-code characters (decimal code 10, hexadecimal 0a), usually referred to as <LF>.
Horizontal left-edge is achieved via use of Carriage Return control-code characters (decimal code 13, hexadecimal 0d), usually referred to as <CR>; this will move the PCL cursor to the current left-margin (whatever that is set to) on the current line.

If I send the contents of the file to my local LaserJet 1320n printer (which holds A4 paper (physical size 297 x 210 mm, printable area is usually about 4-6 mm less than this all round):

Pairs of pages are printed.
The first page of each pair contains data (with the 'KOPIE FACTUUR' line in the same relative horizontal and vertical position on each page; some data on the right-hand edge is missing, as A4 paper is only 210mm wide.
The second page of each pair is blank; i think this is because the number of lines (including trailing blank Line Feed  lines on each input page moves the PCL cursor past the bottom of the paper (or past the perforation-skip limit).

What paper size is the report designed for?
... and what paper size is in use on your printer?

It's possible (I don't know) that the (unexpected) <DC2> character at the start is being interpreted (on your printer) as data, and pushing the head of page down (on the first page only)?
exactcs.prn-analysis.txt
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I've found it myself by experimenting with several drivers for the machine.