Brian K. White wrote:
We have a number of Kyocera printers, that will do KPDL or PCL6.
Typically users will be printing from openoffice or Acrobat, and
select
the usual options - papersize, input tray, type of paper etc. The
only automated application is for billing and that produces invoices
in pdf format.
Since you say it's users printing from openoffice and acrobat, I think
the whole pcl thing doesn't apply. You said pjl which made me think
you were dealing with a local application running on the linux box
that generates pcl like a lot of legacy back end apps did.
Given what you just described, I don't know a practical way to get
what you want without either replacing a printer with one that knows
PCL5 or lower or PS so that you can modify the job on the fly without
breaking it. Several items combine to make this difficult without
changing something somewhere.
Both openoffice and acrobat exist on linux and windows and mac, and
they each print differently.
If you're talking about linux, then openoffice and acrobat generate
PS, not pcl.
Yes, I'm only talking about Linux, we're a 100% Linux-shop.
PS can be read and modified on the fly without
breaking it. I don't
know how the user could select printer features like paper source
unless it's the cups driver/ppd that knows how to do that and they are
selecting in a cups/spooler dialog, so cups is applying those
commands not the application. In that case you should be able to do
something in the filter script.
Yes, when you're in e.g. Acrobat and hit you Ctrl-P, you're presented
with the printing dialogue. The "Properties" button will show you the
list of option from the PPD.
Also, when a printer says it understands PCL6, that
may or may not
mean it also understands PCL5 or lower. PCL6 is a binary format that
you can't modify on the fly simply.
Ah. There seems to be manuals available for up to PCL5, but I can't
find anything for PCL6.
Many newer printers support PCL6
but not PCL5 or lower because it requires more cpu and ram in the
printer to support PCL5 and requires paying a license to HP for each
printer. Older laser printers and more expensive newer laser printers
often support pcl5. It's worth a shot to see if yours does.
I need to test 4 different models, I guess this is this a matter of
simply feeding the printer with some raw PCL5.
Just in case you've got an idea - why would using the forms setup not
work for me? There must be something I'm missing. I've opened a
support case with Kyocera, but I'm not holding my breath.
If it only supports pcl6, you might make sure all
desktops use the
pcl6 driver instead of the kpdl one, and then on the server you could
have the spooler read the pcl6 with ghostpdl and convert it to
something you can manipulate like pdf, and then let cups convert the
pdf to the printers native data like back to pcl6 or kpdl etc. You
_might_ be able to retain the ability for the users to do things like
select paper source IF ghostpcl can report those settings to you
somehow when it reads the pcl6. Then if you can get get ghostpcl to
tell you what options the user set, then you can possibly turn around
and tell them to cups so they get created again in the new modified
print job. I have no idea if any of that's possible.
Hmm, setting the various options will probably become moot anyway - I
still intend this to be a separate printer queue which only prints on
plain paper, size A4, with the letterhead overlay.
Or another lucky break possible, you said pjl
originally. MAYBE all
the special printer commands are done in PJL regardless if the rest of
the print job is in pcl6 or kpdl? In THAT case you might be able to
make it work. Because it's not too hard to parse the pjl and collect
it, strip it from the main job, do your graphics manipulation on the
main job by converting from pcl6 to pdf and back to pcl6, and then
re-applying the pjl to the beginning.
The printjob (when I get it in a cups filter) looks like this:
PJL stuff (encapsulated by PJL UEL markers)
postscript
PJL stuff (encapsulated by PJL UEL markers)
Sofar I have written a utility that reads the whole thing, extracts the
postscript, does the overlay with pdf+ps, then reapplies the PJL, and
passes it back to cups. It works, but it's kludgy and slow.
I'd try sending a test pcl5 job to the printer,
raw, don't let cups
try to apply any driver. If the printer prints it then that's your
easiest path, both in terms of your work and the work the server does
for each job, because you won't have to do any graphics conversions,
just inject a small amount of data.
echo -en "\033EPCL5 test \033(s3Bemphasised\033(s0B
\033(s1Sitalics\033(s0S\014\033E" |lpr -o raw -P printername
Thanks, will try that.
Failing that I'd try to figure out if the pjl idea
is true that all
the special commands are done in a pjl header.
The PJL actually looks very simple:
^[%-12345X@PJL
@PJL JOB NAME = "test4" DISPLAY = "2249 per test4"
@PJL RDYMSG DISPLAY = "2249 per test4"
@PJL SET ECONOMODE=OFF
!R!CRES;SCRN0;RGBL0,0;RGBL1,0;RGBL2,0;HUE0,0;HUE1,0;HUE2,0;HUE3,0;HUE4,0;HUE5,0;HUE6,0;LGHT0,0;LGHT1,0;SATU0;EXIT;^[%-12345X@PJL
ENTER LANGUAGE=POSTSCRIPT
--
Per Jessen, Zürich (4.7°C)
http://www.dns24.ch/ - free DNS hosting, made in Switzerland.
--
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org