[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
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy