------=_NextPart_000_000B_01BE7600.A94D8520
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
There are a number of minor problems regarding MOD and high-end printers
that use a separate RIP engine.
The RIP converts the document source from PostScript or pdf to raw image
data. Office printers with a PostScript processor usually RIP each page
just before printing it, and can RIP most office documents pretty quickly.
Documents that contain a lot of graphics may take an appreciable amount of
time to RIP, and so most high-end printing systems have a separate RIP
engine. Web printers, that print from a huge roll and chop up the output as
it emerges, cannot stop and start without wasting a few yards of paper, so
it is important that the source is RIPped before it is printed.
This means that as jobs enter the system, the printer first tries to get
them RIPped, according to priority, and in parallel to this it is trying to
ensure that the print unit is kept supplied with RIPped jobs. If the print
unit stops, because of a paper jam, or because the operator is replenishing
the consumables, the printer will still continue to RIP jobs. Conversely,
if the RIP stops because there is no more space available for image data,
the print unit will continue.
MOD 1.1 does not make any distinction between RIPping and printing, so if
the printer is engaged in either of these activities the "printer-state"
attribute is "processing". This means that the state would be "processing"
even though the actual print unit has stopped because of a paper jam, but
that contradicts 4.4.10 line 3620 which states that none of the reasons may
prevent a job from completing. If we say that the state is not "processing"
but "stopped" that will contradict line 3626 which says that the job being
RIPped must transit to the pending state.
Furthermore, when the printer is in the "processing" state, line 3619 states
that new jobs may only transit into the "processing" state when all the jobs
ahead of it have been completed, implying that there is only one job in the
processing state. The printer will be obliged to break this rule, since it
must start process jobs in parallel in order to maintain throughput. This
could break clients that only expect to find one job in the processing
state. Even if we ignore the RIP, the print path of these machines is so
long that they will start printing a new job well before the previous job
has finished, so there may be three or four jobs that are in the processing
(printing) state. The printer cannot mark these jobs as completed when the
last page of the job is started, because the printer might fail before the
job actually emerges.
The printer might just ignore the RIP process for IPP and only transit the
job to "processing" when it is actually being printed, but MOD 4.3.7 line
3119 states that a job being RIPped is in the "processing" state. 4.3.8 line
3265 states the "job-state-reason" may be "job-interpreting" or
"job-transforming" When a job has been completely RIPped, but is waiting to
be printed, the diagram on line 3180 indicates that its state should be
"processing-stopped" and that it will transit to "processing" when it is
printed. It is likely that there will be quite a number of jobs in this
state, but there is no "job-state-reason" available. It is also possible
for the operator or user to hold the job after it has been RIPped, so there
will be a transition between "pending-held" and "processing-stopped"
MOD 3.2.7 states that when a printer is paused, it must prevent jobs from
entering the "processing" state. That implies that the pause-printer
operation also stops the RIP processor, which might not be the intention.
This is an optional operation however, so a high end printer can avoid the
issue by not implementing it.
If we ignore these issues, each implementer of an IPP server for these
machine is likely to bend the rules in different ways.
Perhaps the simplest way to resolve these issues is to use the "processing"
state for physical printing only and to introduce a new optional job
attribute "job-rip-state" or "job-transform-state" with as value the enum
from "job-state" The printer would then need an attribute to indicate
whether it is RIPping or not, irrespective of the print unit status.
Regards
Anthony Porter
------=_NextPart_000_000B_01BE7600.A94D8520
Content-Type: application/octet-stream;
name="Anthony Porter.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Anthony Porter.vcf"
BEGIN:VCARD
VERSION:2.1
N:Porter;Anthony
FN:Anthony Porter
ORG:Xeikon;R&D
TITLE:Project Consultant
TEL;WORK;VOICE:+32.3.44.31.614
TEL;WORK;VOICE:075-736639
TEL;HOME;VOICE:+32.2.762.84.91
TEL;CELL;VOICE:+32.75.73.66.39
TEL;WORK;FAX:+32.3.44.31.448
TEL;HOME;FAX:+32.2.770.21.43
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Xeikon=3D0D=3D0AR&D=3D0D=3D0AVrede=
baan 72;Mortsel;;B-2640;Belgium
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Xeikon=3D0D=3D0AR&D=3D0D=3D0AVrede=
baan 72=3D0D=3D0AMortsel, B-2640=3D0D=3D0ABelgium
ADR;HOME:;;Kerkedelle 30;Brussels;;B-1200;Belgium
LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Kerkedelle 30=3D0D=3D0ABrussels, =
B-1200=3D0D=3D0ABelgium
URL:
URL:http://www.xeikon.be
EMAIL;PREF;INTERNET:anthony.porter@computer.org
REV:19990222T102415Z
END:VCARD
------=_NextPart_000_000B_01BE7600.A94D8520--