Re: D3/Linux Printer Misbehavin'

#1

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in
news:s5mdnUqRh-xoQJjZRVn-qg (AT) giganews (DOT) com:

Quote:

CDPers,

I'm at a loss for thought here. I have a couple of reports
(PROC/AQL
based) that are forgetting the fact they were landscape reports, in
the middle of printing. The change in rotation happens in random
places and only when printing to a Kyocera printer. I have other
similar landscape reports printing just fine on the Kyocera printer.
However, the screwy reports come out OK on our Canon ImageRUNNER. They
are all served by LPRng using "JetDirect-style" TCP printing. The
Kyocera and Canon both fully support PCL6, PS3, ASCII, IBM ProPrinter,
and Epson. The issue isn't with the emulation or the printing system.
If it was a specific printer issue, then it would happen on all the
long landscape reports. Besides a D3 SHP printing issue, can anyone
think of how a 132-width report can change to 80-width in the middle
of a job? I will look at the KPDL programming guide and see if there
is a page orientation command that might be getting misinterpreted by
the printer. Typically, you have to send a rather odd sequence of
characters to put the printer into KPDL mode, once it's in another
emulation. The default is PCL6 for this one, but it will auto-detect
job language on each new job.

Thanks!
Glen

Embedded control codes in the data, perhaps? I've seen it happen
before..

Regards,
Joe

#2

Quote:

Embedded control codes in the data, perhaps? I've seen it happen
before..

Although it shouldn't before EOJ, I have seen those weird cases too.
Pipe 'er through hexdump and put on your tedious glasses?

#3

"Joe" wrote

Quote:

"Glen B" wrote

CDPers,

I'm at a loss for thought here. I have a couple of reports
(PROC/AQL
based) that are forgetting the fact they were landscape reports, in
the middle of printing. The change in rotation happens in random
places and only when printing to a Kyocera printer. I have other
similar landscape reports printing just fine on the Kyocera printer.
snip

Thanks!
Glen

Embedded control codes in the data, perhaps? I've seen it happen
before..

Regards,
Joe

The way to tell is to "hold" the output in the spooler. If it fails, dump
those spooler frames until you get to where the change happens. You should
be able to see something screwy in the data, if it's there.

Mark Brown

#4

There is always the (remote) possibility of network collissions
(garbled data) or a high-level memory fault in the printer (let me
guess, the report that is failing is not a 1 page job, with a lot of
"dense" printing beforehand)

I'm also assming that the report IS streaming - no waits as far as the
printer is concerned.

Do you have other Kyocera printers? Is this "constant", or just on this
one device?

I can see a few trees may die trying to "solve" this one ... happy
hunting!

#5

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Quote:

There is always the (remote) possibility of network collissions
(garbled data) or a high-level memory fault in the printer (let me
guess, the report that is failing is not a 1 page job, with a lot of
"dense" printing beforehand)

I'm also assming that the report IS streaming - no waits as far as the
printer is concerned.

Do you have other Kyocera printers? Is this "constant", or just on this
one device?

I can see a few trees may die trying to "solve" this one ... happy
hunting!

Yikes! Might check for a more generic 'reset' sequence rather than an
explicit orientation change. Just a thought...

BFaux

#6

I have to agree with Mark on this one. Whenever I get a difficult
(screwy) printer problem I send it to a hold file, find the frame where
it fails/changes, and look at the data. This almost always turns up
the problem.

Cliff

#7

Glen, using Mark's idea, can you just snip the few pages from the hold
file where the orientation changes? Maybe the page before and the page
after? Just send that to the Kyocera and see what flies...

Regards,
Joe

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in
news:TeOdnQtR64gACZrZnZ2dnUVZ_t2dnZ2d (AT) giganews (DOT) com:

Quote:

I forgot to mention that the orientation change happns after a page
feed,
so the entire next page is rotated. It doesn't happen in the middle of
a page. I have seen this happen on HP printers before, when a reset
command or top-of-form command cleared the page setup. Each page had
to have the form settings sent before each new page in a job. That is
not the problem here or all of the pages would be portrait.

Glen

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in message
news:2N6dne2wMYQXDprZnZ2dnUVZ_tKdnZ2d (AT) giganews (DOT) com...

I hex dumped 90% of the report using the hex print feature of the
printer and went through the offending page(s) char by char. The hex
dump feature is exactly what comes in the port, before any processing
is done. There is nothing even close to either a PCL or PRESCRIBE
orientation command on the last good page or the first bad page.
There also isn't any kind of printer reset command. The emulation
setting on this specific printer is set to KPDL auto-detect, which
means it will print PS3 natively, but it'll switch to *1* alternate
emulation when commands are recognized for it. In such a case, my
alternate setting for PCL6 works fine. It is recognizing PCL4 page
and font settings just fine on this report. However, the printer is
changing orientation all by itself in the middle of the job. It does
it on every 3800 series Kyocera we have in the building. It prints
just fine on the Canon IR3200 we have. *pulling hair*. I have a
feeling that it may be a printing engine problem. What I don't
understand, though, is the fact that other, longer, landscape reports
print just fine. It's just a few specific reports that are doing
this.

Glen

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in message
news:s5mdnUqRh-xoQJjZRVn-qg (AT) giganews (DOT) com...

CDPers,

I'm at a loss for thought here. I have a couple of reports
(PROC/AQL
based) that are forgetting the fact they were landscape reports, in
the middle of printing. The change in rotation happens in random
places and only when printing to a Kyocera printer. I have other
similar landscape reports printing just fine on the Kyocera printer.
However, the screwy reports come out OK on our Canon ImageRUNNER.
They are all served by LPRng using "JetDirect-style" TCP printing.
The Kyocera and Canon both fully support PCL6, PS3, ASCII, IBM
ProPrinter, and Epson. The issue isn't with the emulation or the
printing system. If it was a specific printer issue, then it would
happen on all the long landscape reports. Besides a D3 SHP printing
issue, can anyone think of how a 132-width report can change to
80-width in the middle of a job? I will look at the KPDL programming
guide and see if there is a page orientation command that might be
getting misinterpreted by the printer. Typically, you have to send a
rather odd sequence of characters to put the printer into KPDL mode,
once it's in another emulation. The default is PCL6 for this one,
but it will auto-detect job language on each new job.

Thanks!
Glen

#8

Glen:

Just a thought... On occasion I've had data include quotes which messed up
formatting (included them in text rather than allowing interpretation by
printer. Maybe, after reviewing the spooler entry you might notice specific
data missing and will find the data to be the cause.

Bill

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote

Quote:

CDPers,

I'm at a loss for thought here. I have a couple of reports (PROC/AQL
based) that are forgetting the fact they were landscape reports, in the
middle of printing. The change in rotation happens in random places and
only when printing to a Kyocera printer. I have other similar landscape
reports printing just fine on the Kyocera printer. However, the screwy
reports come out OK on our Canon ImageRUNNER. They are all served by LPRng
using "JetDirect-style" TCP printing. The Kyocera and Canon both fully
support PCL6, PS3, ASCII, IBM ProPrinter, and Epson. The issue isn't with
the emulation or the printing system. If it was a specific printer issue,
then it would happen on all the long landscape reports. Besides a D3 SHP
printing issue, can anyone think of how a 132-width report can change to
80-width in the middle of a job? I will look at the KPDL programming guide
and see if there is a page orientation command that might be getting
misinterpreted by the printer. Typically, you have to send a rather odd
sequence of characters to put the printer into KPDL mode, once it's in
another emulation. The default is PCL6 for this one, but it will
auto-detect job language on each new job.

Thanks!
Glen

#9

Alright Glen you have my curiosity up. You say it is random
but only happens between pages.

1. Is the printer setup as a RAW printer (in *nix)? If not what?
2. Can you redirect to a FILE printer hanging off of a workstation
and read the results of the file. Remember the File printer would
have to be RAW as well or Windoz will insert <CR>s into it.
2. If you send it to a hold entry and print from the spooler and
then print it a second time do you get the same results. This would
make the print job the issue.

3. Does the job get generated from different ports with these bad
results. What does the TERM statement look like when it is bad.

4. Are these new reports? If not then what changed?

Patrick <;=)

Glen B wrote:

Quote:

CDPers,

I'm at a loss for thought here. I have a couple of reports (PROC/AQL
based) that are forgetting the fact they were landscape reports, in the
middle of printing. The change in rotation happens in random places and only
when printing to a Kyocera printer. I have other similar landscape reports
printing just fine on the Kyocera printer. However, the screwy reports come
out OK on our Canon ImageRUNNER. They are all served by LPRng using
"JetDirect-style" TCP printing. The Kyocera and Canon both fully support
PCL6, PS3, ASCII, IBM ProPrinter, and Epson. The issue isn't with the
emulation or the printing system. If it was a specific printer issue, then
it would happen on all the long landscape reports. Besides a D3 SHP printing
issue, can anyone think of how a 132-width report can change to 80-width in
the middle of a job? I will look at the KPDL programming guide and see if
there is a page orientation command that might be getting misinterpreted by
the printer. Typically, you have to send a rather odd sequence of characters
to put the printer into KPDL mode, once it's in another emulation. The
default is PCL6 for this one, but it will auto-detect job language on each
new job.

Thanks!
Glen

#10

OK, it is time to show our community spirit.

I propose that we initiate a project to find Glen's errant bits. It
should be modeled after a project my brother who works for NASA pointed
me to:
http://stardustathome.ssl.berkeley.edu/

Glen, get to work coding and we can all get our microscopes going!