[Cloud] Google's Cloud Device Description (Semantic Capabilities)

[Cloud] Google's Cloud Device Description (Semantic Capabilities)

[Cloud] Google's Cloud Device Description (Semantic Capabilities)

K.D. Lucas kdlucas at gmail.com
Wed Feb 6 17:15:22 UTC 2013


*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>


More information about the cloud mailing list