[Printing-architecture] Re: [printing-japan] Questions on the Vector Driver API

[Osamu MIHARA <mihara.osamu@fxpsc.co.jp>]

Thank you, Glen!

I will invesitage your comments and reply later.

on 2004/04/20 2:35 Petrie, Glen said the following:
> 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/
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> printing-japan mailing list
> printing-japan@mail.freestandards.org
> http://mail.freestandards.org/mailman/listinfo/printing-japan