[IPP] Comments on PWG Raster

[IPP] Comments on PWG Raster

Michael Sweet msweet at apple.com
Mon Aug 8 22:09:11 UTC 2011


Glen,

Comments inline...

On Aug 8, 2011, at 2:39 PM, Petrie, Glen wrote:
> Mike,
>  
> For EdgeEnum,  I believe this the media “feed edge”.  The keyword could be reduced to ShortEdge and LongEdge since addition of “First” does not help in the describing the data.  I might suggest the name be changed to “FeedEdgeShort” and “FeedEdgeLong”.

The keyword names come from the Semantic Model definitions, so for better or worse I'd like to keep them as-is.

> I do not understand the title MediaPosition.

Blame Adobe - this is the name as defined by Adobe for the PostScript page device dictionary. Again, since the name comes from a specific source I don't want to change it, but we can add verbiage to explain things.

> Does this mean input tray (or source tray).  So the enum is really MediaInputTrayEnum or MediaSourceEnum.  I like MediaInputTrayEnum; since it is used in a lot of other specifications.

Again, since the field is called MediaPosition I'd like to keep the name the same.

> Hagaki is not media source. 

It actually is for some printers I've worked with (as strange as that sounds), but since there is resistance to standardizing it I will remove it.

> I actually do not see that Photo is a source or tray.  I understand that you would to specify the “photo media tray”; but really, the request is use the tray with photo media.  If the actual tray is not known; then the tray is set to “auto” and Media type is to “photo”.

Many consumer inkjets have a dedicated photo input tray that only accepts photo media. You need a way to specify whether to pull from the photo tray or the main tray (which can also hold photo media...)

> 
> I compared the Media Input tray to JTAPI and found several differences I would like to discuss.
>  
> “Main” is not used in JTAPI and I believe it can be covered by “Auto”.  Thus it can be dropped.
> “Alternate” is not used in JTAPI and I believe does indicate an actual tray and can be covered by “Auto”.  Thus it can be dropped.

No, "main" and "alternate" have a specific meaning on printers with 2 input trays. Some vendors call them upper and lower, some 1 and 2, some main and alternate.

> 
> “Manual” in JTAPI is specified as “By Pass Tray” or “Insert Tray”.  

Yet "manual" is already a registered name from 2911.

> “Roll” is specified in JTAPI as “Roll”, “Roll 1”, “Roll 2”, etc. and not as main or alternate.  I suggest using the Roll 1 and Roll 2, etc you already have and drop main and alternate.

Again, some vendors refer to them this way so I would prefer to keep them.

> 
> Are there really printers with 20 input trays or 10 rolls?   These are lot of input trays!!!!  I know of finishing devices with that many trays but not the printer.

Just a bit of future-proofing so we don't need to update things just to handle adding a tray to the list.

> 
> Are the numerical values 18 and 19 supposed to be skipped?

Yes, I was leaving room for any additions; I could just as easily make tray-N start at 100 and roll-N start at 200.

> 
>  
> This is the list from JTAPI:
> ANY_SMALL_FORMAT
> ANY_LARGE_FORMAT
> AUTO_SELECT   
> BOTTOM        
> BYPASS_TRAY   
> BYPASS_TRAY_1 
> BYPASS_TRAY_2 
> BYPASS_TRAY_3 
> CONTINUOUS    
> DISC          
> DISC_1        
> DISC_2        
> DISC_3        
> ENVELOPE      
> ENVELOPE_1    
> ENVELOPE_2    
> ENVELOPE_3    
> FRONT         
> INSERT_TRAY   
> INSERT_TRAY_1 
> INSERT_TRAY_2 
> INSERT_TRAY_3 
> LARGE_CAPACITY
> LARGE_CAPACITY_1
> LARGE_CAPACITY_2
> LARGE_CAPACITY_3
> LEFT          
> MIDDLE        
> REAR          
> RIGHT          
> ROLL          
> ROLL_1        
> ROLL_2        
> ROLL_3        
> SIDE          
> TOP           
> TRAY          
> TRAY_1        
> TRAY_2        
> TRAY_3  

I'll cross-reference this with the list I have and add any missing ones.

>  
> I suggest changing “LeadingEdge” to “FeedEdge”

See above.

>  
> Can you add wording for multi-variable data on the specific order of data in the header.  Example ImageBox; I guess it Left, Top, Right, Bottom order (which is backwards from most system I know of; most are top, left, bottom and right.)

ImagingBoundingBox is Left, Bottom, Right, Top. And I thought I had (will check)

> For the Margins you have Left and Bottom while the convention is Top and Left (in that order).   Should these be changed?
> 
No, PostScript defines it thusly.

>  
> I do see the definition for “OrientationEnum” in the specification.
>  
> You use unsigned integer for most variable which make sense for C-Code implementation; however, Java does not have unsigned integers.  What would be the potential “danger” of specifying signed integers.

Incompatibility with the existing format. As for Java's limitations, I'd rather not start a language war...

> What/Where is description for “ImageBoudningBox” (not ImageBox stuff that is given in section 4.3.2.8).
> 

I'll add one, but it is the PostScript definition (left, bottom, right, top coordinates in points, origin is the bottom left corner).

>  
> I do not see a section with a descriptive paragraph (section) for Manual Feed.

I meant to remove ManualFeed from the table and leave it reserved. It is legacy cruft that it superseded by MediaPosition.

>  
> What is LSB for Media Weight? Or number of significant bits.

Media Weight in integer grams.

> I am a little confused about the term “RenderingIntent”.   Do you mean ColorMapping; that is how one maps from image color space to device color space. Example in perceptional, linear, clipped, etc.
> 

I mean the same as defined in JPS3 and ICC - AbsoluteColorimetric, RelativeColorimetric, etc.

________________________________________________________________________
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/ipp/attachments/20110808/b0b75906/attachment-0001.html>


More information about the ipp mailing list