Re: D3/Linux Printer Misbehavin'


I don't need the hold file. I'm looking at the raw binary data that the
printer is receiving. The hold file will only show me what the job looks
like before it gets mangled by lppick and/or LPRng. The printer data, at the
printer, is not botched at all, which leads me to believe that there is a
printing engine problem or the memory is flakey. lppick has been known to
mess up LPR print jobs, but in this case the data is squeaky clean. That
makes this a whole lot harder to troubleshoot. It's time for hardware
support.

Glen

"Joe" <nobody@xxxxxxxx> wrote in message
news:Xns977AD201C781Fnospamforme@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx:


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@xxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx

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









.

Relevant Pages

  • Re: D3/Linux Printer Misbehavin
    ... I forgot to mention that the orientation change happns after a page feed, ... top-of-form command cleared the page setup. ... I have a feeling that it may be a printing engine problem. ... It's just a few specific reports that are doing this. ...
    (comp.databases.pick)
  • Re: question aoubt printing an image on a form
    ... Printing in Access is easiest done via Reports. ... Image Control and use DoCmd.OpenReport... ... > Which command should I use to print an image on a form? ...
    (microsoft.public.access.formscoding)
  • Re: Printing question
    ... The Printing part is easy enough. ... Extensible XML-serializable business classes that can do the printing ... "PrintElements" that are at the top of the page. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: Image Help
    ... Improvements in Access 2007 eliminate the bloat with OLE Objects, ... If you are printing the images in reports, to avoid memory leakage, you ... the Access formatting process prior to being spooled to the Printer Driver. ... Memory" error that can popup when printing image intensive reports. ...
    (microsoft.public.access.forms)
  • Re: load linked image in forms
    ... If you are printing the images in reports, to avoid memory leakage, you ... PrintFailure.zip is an Access97 MDB containing a report that fails during ... the Access formatting process prior to being spooled to the Printer Driver. ... Memory" error that can popup when printing image intensive reports. ...
    (microsoft.public.access.forms)
Loading