This is probably long off your desk, but the zero top margin (^[&l0E) is the
cause of the channel skip error.
The zero top margin must cause the channel skip to be a real place on the
page available for printing. If the top margin were even ^[&l1E, one line
down, the problem would not occur.
So can we say it's a hardware problem? Only if we're the software guys!
Dano
At 06:47 PM 4/9/97 GMT, Larry Byler wrote:
>(not sure what happened to the original message, let's try again):
>
>Hi all,
>
>This is a real role reversal -- the spooler wonk is about to ask the rest
>of the world a printing question :-). My apologies in advance for the
>length.
>
>For PCL printers, the various flavors of the MPE spooler (network and
>non-network) map the %61 carriage control code into ^[&l1V (that's ell-one).
>This is a legacy escape sequence, which is supposed to make the printer
>skip to VFC Channel 1, traditionally assigned to top-of-form. I say
>"legacy" because the sequence is no longer described in any current PCL
>book I have access to, but has appeared to work. It worked fine in the
>test phase of the network printing spooler.
>
>We now have a spool file from a customer in which ^[&l1V appears not to
>work. We've examined the NMT trace file of the data stream going to the
>printer, so we know it's getting there (that is, it wasn't filtered out
>by any of the spooler's conditional-top-of-form mumbo-jumbo). But the
>printer is not ejecting a page. Instead it prints page 2 on top of page 1.
>
>This has occurred at the customer site, and on at least two printers here
>in the lab. One of the two lab printers is the one on my desk, which
>passed all my network printing VFC tests with flying colors last year.
>
>None of the spool file data changes any of the printer's VFC setting. In
>fact, the only controls in the file are pen positioning sequences
>(^[*p#x#Y) at the beginning of each page, used in conjunction with
>rectangle sequences (^[*c#a#b#P), used to draw and fill extremely narrow
>rectangles as rules. This is why the two pages print on top of each other;
>the pen is positioned there at the start of each page. There are also some
>character set selection codes, such as ^[(8U ... Once into the data, each
>record uses a CCTL code of %40, which the spooler converts to ^[&a+01R^M
>(advance one character row + <cr>).
>
>Here are excerpts from the file (as rendered by SPIFF, and edited by me
>to remove customer data content). Since some of the records in the file
>are longer than 80 bytes, I have artificially split those records with a
>"\" for display here. My comments are in brackets ([]). Also, SPIFF
>displays the <esc> character as a dot (".").
>
> 0 OP P1=$0000 P2=$0000
> 1 WR P1=$0001 P2=$0002 CC=%061 [blank page until MPEJXC1]
> 2 WR P1=$0001 P2=$0002 CC=%040 BUF/# 45= .E.9.&a0l175M.&l0e90f8D\
> .(s16.6h1p0T.(10U.&l0S
> 3 WR P1=$0001 P2=$0002 CC=%053 BUF/# 113= .*p70x2733Y.*c2425a3b0P\
> .*p70x315Y.*c3a2418b0P.*p2397x315Y.*c3a2418b0P.*p70x315Y\
> .*c2425a5b0P.*p70x503Y.*c2425a5b0P
> 4 WR P1=$0001 P2=$0002 CC=%053 BUF/# 152= .*p999x315Y.*c5a2418b0P
> .*p1250x315Y.*c5a2418b0P.*p1450x315Y.*c5a2418b0P.*p1700x315Y
> .*c5a2418b0P.*p1890x315Y.*c5a2418b0P.*p2110x315Y.*c5a2418b0P.*p70x15Y
> 5 WR P1=$0001 P2=$0002 CC=%053 BUF/# 1=
> 6 WR P1=$0001 P2=$0002 CC=%320 BUF/# 174= [all blanks]
> 7 WR P1=$0001 P2=$0002 CC=%040
> 8 WR P1=$0001 P2=$0002 CC=%040 BUF/# 26= .(10U.(s0p10h0s3b4099T
> 9 WR P1=$0001 P2=$0002 CC=%040 BUF/# 50= [user data]
> 10 WR P1=$0001 P2=$0002 CC=%040
> 11 WR P1=$0001 P2=$0002 CC=%040
> 12 WR P1=$0001 P2=$0002 CC=%040 BUF/# 76= [user data, then].(8U\
> .(s0p12h0s0b4099T
> 13 WR P1=$0001 P2=$0002 CC=%040
> 14 WR P1=$0001 P2=$0002 CC=%040
> 15 WR P1=$0001 P2=$0002 CC=%040
> 16 WR P1=$0001 P2=$0002 CC=%040 BUF/# 92= [16/79, user data]
>[...]
> 80 WR P1=$0001 P2=$0002 CC=%040 BUF/# 1=
> 81 WR P1=$0001 P2=$0002 CC=%061 [<=== resulting ^[&l1V ignored]
>[...82/91 same as 3/12...]
>[...92 to the end, second page of user data...]
>
>In an attempt to find a causal relationship between the data and lack of
>page eject, we've tried selective deleting of the rules sequences and some
>of the pen positioning sequences, all to no avail. In one experiment, we
>deleted lines 2/5 entirely. This produced a second page, but only because
>line two contains ^[&l8D (set 8 lines per inch). Without that, the 12 point
>specification in line 12 (^[(s12h) governs, and at 6 LPI, lines 7/79
>exceeded one page length. The ^[&l1V was *still* being ignored, because we
>could see the last line of page 1 customer data at the top of page 2,
>followed by all of the page 2 data.
>
>In record 2 above, the "90f" specifies a text length of 90 lines. I tried
>changing this to 60f (60 lines), on the theory that the printer's default
>VFC may extend only to 60 lines, so that channel 1 is undefined at line
>90. That didn't help either.
>
>I also tried changing all the write-on-perf's (P2=2) to the default
>(skip-perf, P2=0). It was a long shot, and didn't change a thing.
>
>I reran my VFC network printing tests. They worked fine.
>
>Finally, if we replace the ^[&l1V with ^[&l0V (which is the code for a
>conditional top-of-form *as determined by the printer*) or by a simple
>FormFeed character (0x0c), I get two distinct pages (correct output).
>
>Again, my apologies for the length, but I've never seen anything like this
>before. Anyone out there have a clue?
>
>-Larry "MPE/iX Spoolers 'R' Us" Byler-
>
>
>
>
>
____________
--------------------------------------------------------| .:. ,;''|--
Danny Compton |.:' :.:' |
Strategic Technical Alliances Manager Unison Software
phone:512/478-0611 fax:512/479-0735 811 Barton Springs Road
[log in to unmask] NASDAQ: UNSN Austin, Texas 78704 USA
--------------------------------------------------------|____________|--
Imagination is more important than knowledge - A. Einstein
|
