All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Petrie, Glen" <glen.petrie@eitc.epson.com>
To: printing-architecture@lists.linux-foundation.org,
	Till Kamppeter <till.kamppeter@gmail.com>,
	Ira McDonald <blueroofmusic@gmail.com>
Cc: "Petrie, Glen" <glen.petrie@eitc.epson.com>
Subject: [Printing-architecture] Final comments on OPVP
Date: Tue, 14 Sep 2010 15:24:21 -0700	[thread overview]
Message-ID: <ED4094DE5E8ACD4BBDACA6AD398E608F540335@EEAEX03.us.epson.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

While I have identified a few grammar and related errors; they would in no way change the meaning or use of the OPVP.  However, the comments below, I believe may be unclear or change the meaning.  Please accepts these comments as recommendations and not mandatory.

 

1.	Page 11, line 21

	a.	Change "The caller may.." to "The caller MAY..." and 

2.	Page 11, line 22

	a.	Change "SHOULD" to "MUST"

3.	Page 12, line 4

	a.	Change "SHOULD" to "MUST"

4.	Page 13, line 28.

	a.	I would like to very strongly recommend that there is no such thing as a "default print job properties".   If you must have a "default", then this document should specify the values.  Let any kind of "default print job properties" be the responsibility of the caller (i.e. the OS, the App) and not the driver.

5.	Page 14, line 17

	a.	Change "If a caller calls the opvpEndJob()...." To "If a caller calls the opvpEndJob(), opvpEndPage(), and/or opvpEndDoc() ...."

6.	Page 14, line 36

	a.	Unless there is another way to set document properties; change "The caller can set document..." to "The caller [MUST] sets document ..."

7.	Page 19, Iine 5 to line 6

	a.	I do no understand the line beginning with "Supported..."

8.	Page 26, line 37

	a.	There is an inconsistency between section 3.1 and all of the APIs that specify "caller coordinate system units".   Section 3.1 states that "Units of the coordinate system are based on the device resolution."   (Note, through out the document, the words "device" and "driver" are used interchangeably.)    I suggest changing Section 3.1 to state "Units of coordinate for the caller and driver are independent and are related through a Coordinate Transformation Matrix (CTM)."  
	b.	Note; thus far, I have not found any incorrect use of caller or driver units and, in fact, it has been clearly stated what is required.

 

Finally, I would like to very strongly recommend removing the Optional calling of StartDoc and EndDoc if there is only one document.   All jobs have documents and all documents have pages; so making a clear and distinct startJob, startDoc, start Page,....endPage, endDoc, endJob sequence make both the caller and driver clearer.

 

 

Glen






[-- Attachment #2: Type: text/html, Size: 8438 bytes --]

                 reply	other threads:[~2010-09-14 22:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ED4094DE5E8ACD4BBDACA6AD398E608F540335@EEAEX03.us.epson.net \
    --to=glen.petrie@eitc.epson.com \
    --cc=blueroofmusic@gmail.com \
    --cc=printing-architecture@lists.linux-foundation.org \
    --cc=till.kamppeter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.