[Printing-architecture] Questions on the Vector Driver API

Petrie, Glen glen.petrie at eitc.epson.com
Mon Apr 19 10:35:36 PDT 2004


Hello,

 

I have reviewed the vector driver specification in detail and have some
questions.

 

General Comments

 

1.        All API specifications must work on/from Mobile/IA Devices,
Desktop, Office and/to Production printing solutions.  Mobile/IA solutions
places memory constraints not considered in higher-end solution; however, I
believe and it has been the general consensus that APIs should take
Mobile/IA memory constraints into consideration in their design.

2.        To avoid the overhead associated with floating point; it has
generally been accepted that the API's not contain floating point numbers. 

 

Specific comments

 

1.        It appears that the API comprehends only a single job at a time.
This means the higher level systems must hold and manage jobs or you are
instantiating a new instance of the driver for each job. This bring ups the
issue of . . . 

a.    Based on general comment 1. above, multiple instantiations is not
advisable.  I believe the solution is to have the driver API support
multiple Job across the API with a single instantiation of the driver.  To
do this, the first argument of each function call is not printerContext but
JobId.   A JobId structure (i.e. the job) would then contain the
printerContext for the job.  There would be an API call to set and get the
printerContext for the job.

2.        Again based on the general comment 1. above, the issue of memory
does not really support an API that "only" has string transfer of job,
document and page key/value attributes.  This even more significant since
the Steering Committee has asked that the driver key/value be aligned the
with Job-Ticket list which is richer that the current Driver API list.

a.    I suggest that the US driver group investigate this as we extend the
Japanese Vector Driver API for Raster support.

3.        There appears to be some inconsistency between the Color Spaces
listed on Page 9 and Page 45.

a.    Shouldn't there be just one Color Space list

4.        What is the "Fix" data type?

5.        Based on general comment 2. above, I would like to suggest
changing the SetAlphaConstant and GetAlphaConstant from using a float value
to an integer that is 10 times or 100 times the need alpha constant.  For
example Alpha of 0.89 would be 89 in the API.

6.        Several of the US teams have adopted a stricter data sizing by
using a data type naming convention for simple types; for example, do not
use "int" since it has no specific size and in API's where data size may
matter, the use of "int" in not recommended.  I would like to suggest the
#define be made for the following basic types which are resolved at
development time.

a.    BIT8

b.    INT8

c.    BIT16

d.    INT16

e.    BIT32

f.    INT32

g.    BIT64

h.    INT64

7.        In the TransferRasterData call the data to be transferred is typed
as "unsigned char".  The size of "char" is not technically defined in C
(most people take it to be 8 bits) and I have worked on platforms where a
char is 32-bit in length - not 8-bit.   I suggest the type for "data" be
changed to BIT8.

8.        There appears to be some inconsistency in naming convention.
Sometime two word variable names have the second work capitalized and
sometimes not.  Sometime arguments that are pointers start with a "p" and
sometimes not. 

 

 

 

Rgds, 
Glen W. Petrie 
Epson Imaging Technology Center 
150 River Oaks Parkway, Suite 200 
San Jose, CA, 95134 
Voice: 408.576.4131  Fax: 408.474.0511 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20040419/1d3124ce/attachment.htm


More information about the Printing-architecture mailing list