Kelly,
On 2013-01-28, at 12:38 AM, "K.D. Lucas" <kdlucas at gmail.com> wrote:
> ...
> Since I know this group has thought about Cloud Printing for quite some time, and has significant experience with the issues around Cloud Printing, we welcome any feedback or comments you might have. I've attached the specification as a PDF file.
>> I won't be around to make your next face-to-face meeting, but I've been reading some of the emails regarding this meeting.
I hope you are able to attend future meetings, as I believe that such participation will help us both...
That said, some quick comments/constructive criticism on this draft of the CDD:
1. There is a LOT of existing work in this space; from the PWG alone we have Universal Printer Description Format (UPDF) and PWG Print Job Ticket (PJT) that can be used to provide everything you have here and more. UPDF has never seen widespread adoption but was meant as a replacement for things like MSPS (what you call XPS) and PPD. PJT is pulled directly from the semantic model and IPP so it is widely deployed and is our official, recommended format for job tickets and printer capabilities:
UPDF: ftp://ftp.pwg.org/pub/pwg/candidates/cs-upd10-20040526-5101.4.pdf
PJT: ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-pjt10-20120801-5108.07.pdf
2. I noticed you lumped manual duplex into the Duplex Type enumeration, however manual duplex is a separate animal that supports both long and short edge handling (just a matter of print data or media orientation for the second pass...) And I'm not sure how you plan on supporting manual duplex in GCP, but it seems like this is insufficient information for you to do so...
3. For typed values, you may find it useful to adopt the notion of enumerated strings (keywords) over enumerated integers. In particular, you'll find this used extensively in IPP for media size and type names, where it is relatively easy to generate UI automatically from the capabilities that are listed.
4. For the Margins Type values, you might want to add DUPLEX since many popular inkjet printers with duplexer accessories enforce really large top/bottom margins when that accessory is used.
5. For the FitToPage Type values, I don't see a "fill" enumeration - this would typically be used for borderless printing of photos where the image and media do not usually have the same aspect ratio (so you scale to fill, losing the extreme edges of the picture)
6. For the Color Type values, I don't see an "AUTOMATIC" enumeration value. This has performance benefits and was added to IPP's print-color-mode by popular request.
7. For the MediaSize Type values, I'll reiterate my comment in #3. Also, if you are going to list the larger ISO A sizes you should probably also list the corresponding larger US/architectural sizes (C, D, E, and F) since the same class of device that supports those sizes will support the C/D/E/F sizes as well.
8. For the MediaSize custom media size support, you have the max values but not the minimum values allowed...
9. The way you are expressing PwgRasterConfig values seems unnecessarily complex - there are 4 keyword values (enumerated strings) in IPP and PWG PJT for this, and you have 5 separate properties that can represent 48 different values (when only 4 combinations are even allowed by the spec...)
10. I don't see a way to specify the media source/input tray.
11. I don't see a way to specify the media type.
12. I don't see a way to get the loaded (ready) media.
13. I don't see a way to get a list of constraints between options, or how to resolve them.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/20130129/a026b509/attachment-0002.html>