Subject: [IPP] Another question on IPP/CUPS/PWG Raster

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 25 Mar 2011 09:08:26 -0700

Mike

During a discussion yesterday, I was asked "Does the IPP Raster stream
data differently for printer with different feed directions?".  The
width and height definition did not clarify the issue.   Assuming the
feed-direction is provided in the PPD (or some other similar document);
then, does the IPP raster data get "streamed-in" in the feed direction?
If not, can a note be added to the width/height definition? Since data
part is compressed first "within a line" and then compress "by lines";
the feed direction represents compressed "by lines" and the print (head)
direction is represented by the "within a line".  So I would proposed
that 

Width  = compression "within a line"  = (head) print direction

Height = compression "by lines"        = feed direction

This is not related to Portrait / Landscape but the physical feed
direction of the printer.

If the PPD file does not state the feed direction; then the default
would be short direction equals width which equals the compression
"within a line"

Glen

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Mar 2011 09:37:56 -0700

On Mar 25, 2011, at 9:08 AM, Petrie, Glen wrote:
> Mike
>  
> During a discussion yesterday, I was asked “Does the IPP Raster stream data differently for printer with different feed directions?”.  The width and height definition did not clarify the issue.   Assuming the feed-direction is provided in the PPD (or some other similar document); then, does the IPP raster data get “streamed-in” in the feed direction?  If not, can a note be added to the width/height definition? Since data part is compressed first “within a line” and then compress “by lines”; the feed direction represents compressed “by lines” and the print (head) direction is represented by the “within a line”.  So I would proposed that
>  
> Width  = compression “within a line”  = (head) print direction
> Height = compression “by lines”        = feed direction
>  
> This is not related to Portrait / Landscape but the physical feed direction of the printer.
>  
> If the PPD file does not state the feed direction; then the default would be short direction equals width which equals the compression “within a line”

The original CUPS Raster format just assumes that the PPD file will define the correct orientation for pages (e.g. 11x8.5 vs. 8.5x11 for US Letter), so the width is the cross-feed dimension and height is the feed dimension. CUPS Raster also includes a LeadingEdge (top, right, bottom, left) field in the page header that specifies the bitmap feed orientation, and I can document that for PWG Raster (0 = top, which is by far the most common value...)

I can see a need for a client to discover the feed orientation since the standard media names are portrait orientation and it could be confusing to deal with both "oe_letter_11x8.5in" and "na_letter_8.5x11in" in client UI. JPS2 defines a "feed-orientation" attribute that can be used for this purpose, and combined with JPS3's xxx-preferred and coloring mechanisms would allow a client to discover the correct/best PWG raster orientation for a given job ticket. I'll make "feed-orientation" conditionally required for printers that need landscape bitmaps, and include a mapping for LeadingEdge in the page header.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair