*Thanks to everyone who contributed feedback to our Cloud Device
Description(CDD) of printer capabilities. We appreciate your
experience and the
thoughtfulness which you’ve put into reviewing our draft, and have made
adjustments to it (as well as added clarifications) below.
The draft we shared was initially written for developers and not as a
complete design document. Consequently, it omitted some details around the
scope and purpose of CDD which we’ll tried to clarify here:
*
*
1. CDD is in some ways different from UPDF, in that it's not meant to be
implemented in a full-fledged printer driver. In Google Cloud Print, the
traditional driver responsibilities are shared between printer and cloud
server. For example, page feed direction for a particular media type are
not relevant to a user, and would only need to be interpreted by the
firmware running on the cloud-aware printer.
2. CDD is not intended to fully describe a UI, just provide a simple
data model for generating one. Resulting UIs may look entirely different
depending on the client. As a result, UPDF sections describing UI layout or
locale are not included in CDD.
*
3. *The PwgRasterConfig section has been rewritten to be a list of
transformations that are applied to the pages of the print job:
// Configuration of how printer should receive PWG raster images.
message PwgRasterConfig {
// Transformation to apply to pages during PWG rasterization.
message Transformation {
// Types of transformation operations to apply.
enum Operation {
// Rotate pages 180 degrees.
ROTATE_180 = 0;
// Flip pages along the long edge of the paper.
FLIP_ON_LONG_EDGE = 1;
// Flip pages along the short edge of the paper.
FLIP_ON_SHORT_EDGE = 2;
}
// Selectors of which pages to apply the transformation to.
enum Operand {
// Apply transformation to all pages.
ALL_PAGES = 0;
// Apply transformation to even pages only when duplexing.
ONLY_DUPLEXED_EVEN_PAGES = 1;
// Apply transformation to odd pages only when duplexing.
ONLY_DUPLEXED_ODD_PAGES = 2;
}
required Operation operation = 1;
required Operand operand = 2;
}
// What transformations to apply to pages in the print job.
repeated Transformation transformation = 1;
}
1. The initial draft of CDD intentionally omits Media Type and Tray, as
semantically understanding these capabilities would mean also providing a
language for expressing cross-capability constraints. We will
probably add
this in the future, but not in this version (and we haven’t
enforced these
constraints historically for Google Cloud Print).
2. Changing capabilities will initially be addressed by the printer
updating the Google Cloud Print server with a new CDD (e.g., if a duplex
unit is installed, the printer firmware will send an updated CDD to GCP
with the duplex capability initialized). Temporary printer and job states
like offline, paper jam, etc will be not be handled by CDD.
3. The CDD specification makes use of protocol buffers to describe
various objects. In practice, however, CDDs will be sent to and from the
GCP server in JSON format. Printer manufacturers can choose to
store their
CDD representation in JSON on the device if desired. Firmware will not be
required to deal with protocol buffers.
4. Critically, CDD is intended to describe the capabilities of any
device - not just printers. Its protobuf specification shows the
beginnings
of this by separating capability fields of printers and scanners.
CDD will draw most of its capabilities from PWG’s Semantic Model (where
appropriate). However, CDD is intended to be a simple, strongly typed
format and will differ from the flexibility of the Semantic Model in cases
where this conflicts. It appears the existing Semantic Model is
sufficiently general that most of the semantic capabilities defined in CDD
will conform to the Semantic Model, though.
Though we won’t be able to send a representative to your meeting on Feb
6-7, we’re hoping this note will clarify the aspects of CDD that raised the
most questions. We’ll provide updates to PWG on CDD’s progress as we
implement the specification over the coming months, and are always
receptive to feedback.
While the Google Cloud Print team doesn’t have the resources needed to
become heavily involved in ongoing PWG processes at this point, we’d like
to continue to exchange ideas and feedback on new developments in printing.
We look forward to continuing to contribute where we’re able, and to
understanding the efforts of PWG moving forward.
Again, thanks for the feedback! If you prefer to contact me at my
corporate address, feel free to use kdlucas at google.com.*
Regards,
Kelly
kdLucas
--
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/20130206/7b067195/attachment-0002.html>