All,
A thought on things we need to address.
Below is a discussion (most likely the first of many) of functionality
that was handled by "drivers" in the past but must now be handled by
"clients" in the new world of driver-less printing. The cloud group
may want to identify items like this to ensure the information is
correctly represented in the printer "capability" data. Client will
have to know how to format the content to achieve the user print intent.
glen
________________________________
From: gcp-developers at googlegroups.com
[mailto:gcp-developers at googlegroups.com] On Behalf Of Somasundaram
Meiyappan
Sent: Tuesday, July 12, 2011 12:47 AM
To: gcp-developers at googlegroups.com
Subject: Re: pwg-raster and duplex
Hi Paolo,
My thoughts on this topic of duplexing below:
1. The page-order for duplex will definitely vary from printers to
printers. Laser printers can have complex page-ordering scheme depending
upon their paper-path and also because they output face-down. Lower-end
laser printers (say, mono printers used in home or SOHO) may still need
pages in 2-1-4-3 when duplexing. Some laser printers may need them
ordered a little more deeply although I would believe that those
printers are likely to have more memory that they may perform the
page-order and rotation themselves. Inkjet printers will mostly need
pages in 1-2-3-4 as their outputs face-up.
2. Your description of the paper-path sounds correct for most consumer
grade printers that I know of. (I am not speaking for all here). In
other words, a 180 degree rotation alternating page's raster data is
mostly sufficient to achieve long-edge duplex.
3. I believe that the determination of which page should be rotated
depends upon whether the printer has an output finishing unit or not.
Finishing units can be a binder, stapler, etc... If nothing is
specified, I believe that the default assumption can be that the even
page needs to be rotated 180 degree for long-edge duplex. In fact, if a
printer does not have a finishing unit or if you assume that those
printers with finishing unit will use PDF, then you can ignore some
implementation options like you mentioned in your most recent email.
This is a request, once again related to duplexing:
When sending simplex jobs, more implementation options may be enabled
for printer manufacturers if you could provide the numberOfPages
information especially when printing last-page-first especially when it
comes to the printer providing an option to print all jobs duplex. Many
laser printers have such a front-panel setting. One can imagine that
this can also be done by making a particular duplex option sticky using
the /update command. But, there may be periods where a printer has been
off-the-internet for a while during which several new jobs have been
submitted (and their print ticket confirmed) after which the user
enables the 'Print all jobs in Duplex' option in the control panel.
Without numberOfPages support, when the printer gets back onto the
internet and expects that the new options will be in-effect, the user
would see that print-jobs that have been queued before the change still
print simplex because the queued jobs probably make use of the older
default values/capabilities. This numberOfPages (esp when printing
last-page-first) can be used to determine if a dummy pass through duplex
is required for before contents of page N in an N page source document
(even if it is a HTML) is printed with N mod 2 ==1. If you can provide
this information for all document types when the /fetch interfaces
returns info about all jobs, it will be ideal.
Thanks and Regards,
Somasundaram.
On Tue, Jul 12, 2011 at 10:05 AM, Paolo Ferraris <paolof at google.com>
wrote:
Printer manufacturers,
in addition to the questions below, we are thinking about never
sending pages in PWG-raster in reverse order when duplex is enabled (the
ticket will never have reverse order set.)
Reverse printing for duplex doesn't seem to me as important as for
nonduplex printing. If you see it as a necessary feature let me know,
and also please tell me
how the page order should be: in case of 4 pages, should I send them in
order 4-3-2-1 or 3-4-1-2 ?
Thanks,
Paolo
On Mon, Jul 11, 2011 at 2:27 PM, Paolo Ferraris <paolof at google.com>
wrote:
Printer manufacturers,
can I assume the following about PWG-raster printers with duplexers that
need to print on the fly (i.e.: not enough memory to rotate images):
- duplexing unit flips sheets of paper around the feeding edge of the
paper (i.e., for papers fed from the short edge, the top becomes bottom
and vice versa), and
- after page flipping, the paper is moved inside the printer for back
page printing in the same direction as for the front page. (As a result,
the back page starts printing in the corner that is not the same corner
of the front page).
If I don't hear back, I'll just assume them.
Thanks,
Paolo
On Fri, Jul 8, 2011 at 2:10 PM, Paolo Ferraris <paolof at google.com>
wrote:
Hi Mike,
On Fri, Jul 8, 2011 at 12:44 PM, Michael Sweet
<michael.r.sweet at gmail.com> wrote:
On Jul 8, 2011, at 2:47 AM, Paolo Ferraris wrote:
Hello gcp-developers,
I'm implementing some modifications to the pwg-raster page
generation based on ticket capabilities. Pages will not only be
generated based on dpi and page size, but also on document orientation,
duplexing and page ordering (from last to first rather than from first
to last). XPS support will be first, and it will be followed by PPD.
Regarding duplexing, I haven't start looking at PPD
specifications yet but we will only support what XPS allows. That is, we
will possibly rotate even pages by 180 degrees based on document
orientation and whether the page is reverted top-down or left-right by
the duplexing unit. We will not support, for instance, anything similar
to the options "rotated" and "flipped" of attribute pwg-raster-back-side
defined in the PWG-raster document. (See
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327.pdf section 5.1
and figure 3.)
Um, I'm pretty sure "rotated" is what XPS allows, and "flip" is
generally what a printer uses. There is a reason why PWG Raster (and
CUPS Raster) support multiple back-side coordinate systems...
You are actually right about XPS. I don't know the exact definition of
two-sided-short-edge/long-edge in the PWG raster document (can you point
me at it?), but if it is the same as for the duplexing option in XPS
then XPS printing seems to correspond to the "rotated" option in
PWG-raster (instead of manual-tumble as I incorrectly thought that.)
About real printers, it seems to me that if a printer needs "flipped" if
the page is fed back to the printer in the opposite direction. (Say, in
a "traditional" vertical feed, the front page is fed top-down, but,
after rotation, the paper is fed bottom-up.) If the paper is fed in the
same direction the printing seems to need to be printed rotated. Am I
missing anything?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20110712/d9d6d3ef/attachment-0001.html>