<!-- SECTION: Specifications -->
<HEAD>
<TITLE>CUPS Raster Format</TITLE>
- <LINK REL="STYLESHEET" TYPE="test/css" HREF="../cups.css">
+ <LINK REL="STYLESHEET" TYPE="text/css" HREF="../cups-printable.css">
</HEAD>
<BODY>
-<P>CUPS raster files are device-dependent raster image files that
-contain a PostScript page device dictionary and device-dependent
-raster imagery for each page in the document. These files are
-used to transfer raster data from the PostScript and image file
-RIPs to device-dependent filters that convert the raster data to
-a printable format.</P>
+<H1 CLASS="title">CUPS Raster Format</H1>
-<P>CUPS 1.0 and 1.1 used a version 1 raster format. CUPS 1.2
-introduces version 2 (compressed) and version 3 (uncompressed)
-formats that are a superset of the version 1 format. Applications
-using the CUPS Imaging API (the cupsRaster* functions) can read
-all formats without code changes.</P>
+<P>CUPS Raster files are device-dependent raster image files that contain a PostScript page device dictionary and device-dependent raster imagery for each page in the document. These files are used to transfer raster data from the PostScript and image file RIPs to device-dependent filters that convert the raster data to a printable format.</P>
-<P>The registered MIME media type for CUPS raster files is
-<CODE>application/vnd.cups-raster</CODE>.</P>
+<P>CUPS 1.0 and 1.1 used version 1 of the raster format. CUPS 1.2 and later use version 2 (compressed) and version 3 (uncompressed) that are a superset of the version 1 raster format. All three versions of CUPS Raster are streamable formats, and applications using the CUPS Imaging API (the cupsRaster* functions) can read all formats without code changes.</P>
+
+<P>The registered MIME media type for CUPS Raster files is <CODE>application/vnd.cups-raster</CODE>.</P>
+
+
+<H2 CLASS="title"><A NAME="ORGANIZATION">Organization of a CUPS Raster File</A></H2>
+
+<P><A HREF="FILEFORMAT">Figure 1, "Raster Organization"</A>, shows the general organization of all CUPS Raster files. Each file begins with a 32-bit synchronization word followed by zero or more pages. Each page consists of a header (the PostScript page device dictionary and raster-specific values) followed by the bitmap image for the page.</P>
+
+<DIV CLASS="figure"><TABLE SUMMARY="Raster Organization">
+<CAPTION><A NAME="FILEFORMAT">Figure 1: Raster Organization</A></CAPTION>
+<TR><TD><IMG SRC="../images/raster-organization.png" WIDTH="446" HEIGHT="1056" ALT="Raster Organization"></TD></TR>
+</TABLE></DIV>
+
+<P>Each page bitmap is stored as described by the <CODE>cupsBitsPerColor</CODE>, <CODE>cupsBytesPerLine</CODE>, <CODE>cupsColorOrder</CODE>, <CODE>cupsColorSpace</CODE>, <CODE>cupsHeight</CODE>, and <CODE>cupsWidth</CODE> values in the page header. Pixels for the front side of a sheet are always stored left-to-right, top-to-bottom. When doing duplex printing, pixels for the back side of a sheet may be stored differently depending on the value of the <CODE>cupsBackSide</CODE> keyword ("Normal", "ManualTumble", "Rotated", or "Flipped") in the PPD file and the <CODE>Tumble</CODE> value ("true" or "false") in the page header. <A HREF="#PAGEBITMAPS">Figure 2, "Page Bitmaps"</A>, shows the pixel order for each combination.</P>
+
+<DIV CLASS="figure"><TABLE SUMMARY="Page Bitmaps">
+<CAPTION><A NAME="PAGEBITMAPS">Figure 2: Page Bitmaps</A></CAPTION>
+<TR><TD><IMG SRC="../images/raster.png" WIDTH="624" HEIGHT="448" ALT="Page Bitmaps"></TD></TR>
+</TABLE></DIV>
<H2 CLASS="title"><A NAME="V1">Version 1 Raster File Format</A></H2>
-<P>A version 1 raster file begins with a 32-bit synchronization
-word: 0x52615374 ("RaSt") for big-endian architectures and
-0x74536152 ("tSaR") for little-endian architectures. The writer
-of the raster file will use the native word order, and the reader
-is responsible for detecting a reversed word order file and
-swapping bytes as needed. The CUPS Imaging API raster functions
-perform this function automatically.</P>
+<P>A version 1 raster file begins with a 32-bit synchronization word: 0x52615374 ("RaSt") for big-endian architectures or 0x74536152 ("tSaR") for little-endian architectures. The writer of the raster file will use the native word order, and the reader is responsible for detecting a reversed word order file and swapping bytes as needed. The CUPS Imaging API raster functions perform this function automatically.</P>
-<P>Following the synchronization word are a series of raster
-pages. Each page starts with a page device dictionary header and
-is followed immediately by the (uncompressed, raw) raster data
-for that page.</P>
+<P>Following the synchronization word are a series of raster pages. Each page starts with a page device dictionary header and is followed immediately by the (uncompressed/raw) raster data for that page.</P>
<DIV CLASS="table"><TABLE SUMMARY="CUPS Version 1 Raster Page Device Dictionary">
<CAPTION><A NAME="TABLE1">Table 1: CUPS Version 1 Raster Page Device Dictionary</A></CAPTION>
<TD>328-331</TD>
<TD>Unsigned Integer</TD>
<TD>MediaWeight</TD>
- <TD>Media weight in grams per meter squared</TD>
+ <TD>Media weight in grams per meter squared, 0 = printer default</TD>
</TR>
<TR>
<TD>332-335</TD>
<TD>340-343</TD>
<TD>Unsigned Integer</TD>
<TD>NumCopies</TD>
- <TD>1 to 2<SUP>32</SUP> - 1</TD>
+ <TD>0 to 2<SUP>32</SUP> - 1, 0 = printer default</TD>
</TR>
<TR>
<TD>344-347</TD>
<TD>Unsigned Integer</TD>
<TD>cupsBitsPerColor</TD>
<TD>1, 2, 4, 8 bits for version 1 raster files<BR>
- 1, 2, 4, 8, and 16 bits for version 2 raster files</TD>
+ 1, 2, 4, 8, and 16 bits for version 2/3 raster files</TD>
</TR>
<TR>
<TD>388-391</TD>
<TD>Unsigned Integer</TD>
<TD>cupsBitsPerPixel</TD>
<TD>1 to 32 bits for version 1 raster files<BR>
- 1 to 64 bits for version 2 raster files</TD>
+ 1 to 240 bits for version 2/3 raster files</TD>
</TR>
<TR>
<TD>392-395</TD>
<TD>400-403</TD>
<TD>Unsigned Integer</TD>
<TD>cupsColorSpace</TD>
- <TD>0 = white (sRGB)<BR>
- 1 = RGB (sRGB)<BR>
- 2 = RGBA (sRGB)<BR>
+ <TD>0 = gray (device, typically sRGB-based)<BR>
+ 1 = RGB (device, typically sRGB)<BR>
+ 2 = RGBA (device, typically sRGB)<BR>
3 = black<BR>
4 = CMY<BR>
5 = YMC<BR>
15 = CIE XYZ<BR>
16 = CIE Lab<BR>
17 = RGBW (sRGB)<BR>
+ 18 = sGray (gray using sRGB gamma/white point)<BR>
+ 19 = sRGB<BR>
+ 20 = AdobeRGB<BR>
32 = ICC1 (CIE Lab with hint for 1 color)<BR>
33 = ICC2 (CIE Lab with hint for 2 colors)<BR>
34 = ICC3 (CIE Lab with hint for 3 colors)<BR>
44 = ICCD (CIE Lab with hint for 13 colors)<BR>
45 = ICCE (CIE Lab with hint for 14 colors)<BR>
46 = ICCF (CIE Lab with hint for 15 colors)<BR>
+ 48 = Device1 (DeviceN for 1 color)<BR>
+ 49 = Device2 (DeviceN for 2 colors)<BR>
+ 50 = Device3 (DeviceN for 3 colors)<BR>
+ 51 = Device4 (DeviceN for 4 colors)<BR>
+ 52 = Device5 (DeviceN for 5 colors)<BR>
+ 53 = Device6 (DeviceN for 6 colors)<BR>
+ 54 = Device7 (DeviceN for 7 colors)<BR>
+ 55 = Device8 (DeviceN for 8 colors)<BR>
+ 56 = Device9 (DeviceN for 9 colors)<BR>
+ 57 = DeviceA (DeviceN for 10 colors)<BR>
+ 58 = DeviceB (DeviceN for 11 colors)<BR>
+ 59 = DeviceC (DeviceN for 12 colors)<BR>
+ 60 = DeviceD (DeviceN for 13 colors)<BR>
+ 61 = DeviceE (DeviceN for 14 colors)<BR>
+ 62 = DeviceF (DeviceN for 15 colors)
</TD>
</TR>
<TR>
<H2 CLASS="title"><A NAME="V2">Version 2 Raster File Format</A></H2>
-<P>A version 2 raster file begins with a 32-bit synchronization
-word: 0x52615332 ("RaS2") for big-endian architectures and
-0x32536152 ("2SaR") for little-endian architectures. The writer
-of the raster file will use the native word order, and the reader
-is responsible for detecting a reversed word order file and
-swapping bytes as needed. The CUPS Imaging API raster functions
-perform this function automatically.</P>
+<P>A version 2 raster file begins with a 32-bit synchronization word: 0x52615332 ("RaS2") for big-endian architectures or 0x32536152 ("2SaR") for little-endian architectures. The writer of the raster file will use the native word order, and the reader is responsible for detecting a reversed word order file and swapping bytes as needed. The CUPS Imaging API raster functions perform this function automatically.</P>
-<P>Following the synchronization word are a series of raster
-pages. Each page starts with a version 2 page device dictionary
-header and is followed immediately by the compressed raster data
-for that page.</P>
+<P>Following the synchronization word are a series of raster pages. Each page starts with a version 2 page device dictionary header and is followed immediately by the compressed raster data for that page.</P>
<DIV CLASS="table"><TABLE SUMMARY="CUPS Version 2 Raster Page Device Dictionary">
<CAPTION><A NAME="TABLE2">Table 2: CUPS Version 2 Raster Page Device Dictionary</A></CAPTION>
<TD>420-423</TD>
<TD>Unsigned Integer</TD>
<TD>cupsNumColors</TD>
- <TD>1 to 6 colors</TD>
+ <TD>1 to 15 colors</TD>
</TR>
<TR>
<TD>424-427</TD>
<TD>436-451</TD>
<TD>IEEE Single Precision (4)</TD>
<TD>cupsImagingBBox</TD>
- <TD>Four floating point numbers giving the left, bottom,
- right, and top positions of the page bounding box in
- points</TD>
+ <TD>Four floating point numbers giving the left, bottom, right, and top positions of the page bounding box in points</TD>
</TR>
<TR>
<TD>452-515</TD>
<H3><A NAME="COMPRESSION">Compressed Raster Data Format</A></H3>
-<P>The version 2 raster data is compressed using a modified TIFF
-packbits algorithm. Lines are grouped into an integral number of
-color values based upon the <CODE>cupsColorOrder</CODE>
-setting:</P>
+<P>The version 2 raster data is compressed using a PackBits-like algorithm. Lines are grouped into an integral number of color values based upon the <CODE>cupsColorOrder</CODE> setting:</P>
<DIV CLASS="table"><TABLE SUMMARY="Color Value Sizes">
<CAPTION><A NAME="TABLE3">Table 3: Color Value Sizes</A></CAPTION>
</TR>
</TABLE></DIV>
-<P>Each line of raster data begins with a repetition count from 1
-to 256 that is encoded using a single byte of "count - 1".</P>
+<P>Each line of raster data begins with a repetition count from 1 to 256 that is encoded using a single byte of "count - 1".</P>
+
+<P>After the repetition count, whole color values for that line are run-length encoded using a PackBits-like run-length encoding algorithm: 1 to 128 repeated colors are encoded using an initial byte of "count - 1" followed by the color value byte(s) while 2 to 128 non-repeating colors are encoded using an initial byte of "257 - count" followed by the color value bytes.</P>
+
+<P>For example, the 8x8 24-bit sRGB image shown in <a href="#SAMPLEIMAGE">Figure 3, "Sample Image"</a>, would be encoded as the following 89 octets:</p>
+
+<PRE CLASS="example">
+%x00 %x00.FF.FF.FF %x02.FF.FF.00 %x03.FF.FF.FF
+%x00 %xFE.FF.FF.00.00.00.FF.FF.FF.00 %x02.FF.FF.FF %x00.00.FF.00 %x00.FF.FF.FF
+%x00 %x01.FF.FF.00 %x02.FF.FF.FF %x02.00.FF.00
+%x00 %x02.FF.FF.00 %x02.FF.FF.FF %x00.00.FF.00 %x00.FF.FF.FF
+%x00 %x00.FF.FF.FF %x02.FF.FF.00 %x03.FF.FF.FF
+%x00 %x07.FF.FF.FF
+%x01 %x07.FF.00.00
+</PRE>
+
+<P>The first line (%x00) contains 1 white pixel (%x00.FF.FF.FF), 3 yellow pixels (%x02.FF.FF.00), and 4 white pixels (%x03.FF.FF.FF).</P>
+
+<P>The second line (%x00) contains a sequence of yellow + blue + yellow pixels (%xFE.FF.FF.00.00.00.FF.FF.FF.00), 3 white pixels (%x02.FF.FF.FF), 1 green pixel (%x00.00.FF.00), and 1 white pixel (%x00.FF.FF.FF).</P>
-<P>After the repetition count, whole color values for that line
-are run-length encoded using the TIFF packbits algorithm. 1 to
-128 repeated colors are encoded using an initial byte of "count -
-1" followed by the color value byte(s). 2 to 128 non-repeating
-colors are encoded using an initial byte of "257 - count"
-followed by the color value bytes.</P>
+<P>The third line (%x00) contains 2 yellow pixels (%x01.FF.FF.00), 3 white pixels (%x02.FF.FF.FF), and 3 green pixels (%x02.00.FF.00)</P>
+
+<P>The fourth line (%x00) contains 3 yellow pixels (%x02.FF.FF.00), 3 white pixels (%x02.FF.FF.FF), 1 green pixel (%x00.00.FF.00), and 1 white pixel (%x00.FF.FF.FF).</P>
+
+<P>The fifth line (%x00) contains 1 white pixel (%x00.FF.FF.FF), 3 yellow pixels (%x02.FF.FF.00), and 4 white pixels (%x03.FF.FF.FF).</P>
+
+<P>The sixth line (%x00) contains 8 white pixels (%x07.FF.FF.FF).</P>
+
+<P>The seventh and eighth lines (%x01) contain 8 red pixels (%x07.FF.00.00).</P>
+
+<DIV CLASS="figure"><TABLE SUMMARY="Sample Image">
+<CAPTION><A NAME="SAMPLEIMAGE">Figure 3: Sample Image</A></CAPTION>
+<TR><TD><IMG SRC="../images/sample-image.png" WIDTH="257" HEIGHT="257" ALT="Sample Image"></TD></TR>
+</TABLE></DIV>
<H2 CLASS="title"><A NAME="V3">Version 3 Raster File Format</A></H2>
-<P>A version 3 raster file begins with a 32-bit synchronization
-word: 0x52615333 ("RaS3") for big-endian architectures and
-0x33536152 ("3SaR") for little-endian architectures. The writer
-of the raster file will use the native word order, and the reader
-is responsible for detecting a reversed word order file and
-swapping bytes as needed. The CUPS Imaging API raster functions
-perform this function automatically.</P>
+<P>A version 3 raster file begins with a 32-bit synchronization word: 0x52615333 ("RaS3") for big-endian architectures and 0x33536152 ("3SaR") for little-endian architectures. The writer of the raster file will use the native word order, and the reader is responsible for detecting a reversed word order file and swapping bytes as needed. The CUPS Imaging API raster functions perform this function automatically.</P>
-<P>Following the synchronization word are a series of raster
-pages. Each page starts with a version 2 page device dictionary
-header and is followed immediately by the uncompressed raster data
-for that page.</P>
+<P>Following the synchronization word are a series of raster pages. Each page starts with a version 2 page device dictionary header and is followed immediately by the uncompressed/raw raster data for that page.</P>
<H2 CLASS="title"><A NAME="ENCODING">Pixel Value Coding</A></H2>
-<P>The following sections describe the encoding and decoding of
-the color values in a CUPS raster file. In general, colors are
-packed into the minimum number of bytes, with special
-consideration provided for efficiency of encoding and access.
-Multi-byte values are stored in the native byte order and
-automatically swapped as needed when reading them using the CUPS
-imaging API.</P>
+<P>The following sections describe the encoding and decoding of the color values in a CUPS Raster file. In general, colors are packed into the minimum number of bytes, with special consideration provided for efficiency of encoding and access. Multi-byte values are stored in the native byte order and automatically swapped as needed when reading them using the CUPS imaging API.</P>
<H3>CUPS_ORDER_CHUNKED</H3>
-<P>The chunked order provides the pixel value packed in a single
-place. Pixel values with 8 or more bits per color are stored as
-an array of colors in order, e.g. for
-<CODE>CUPS_CSPACE_RGB</CODE> you will see 8/16-bits of red, then
-blue, then green, then red, green, blue, etc. Pixel values with
-less than 8 bits per color are packed together as shown in Table
-4. <I>Multi-byte pixel values are stored in the native word
-order, just as for 16-bit color values.</I></P>
+<P>The chunked order provides the pixel value packed in a single place. Pixel values with 8 or more bits per color are stored as an array of colors in order, e.g. for <CODE>CUPS_CSPACE_RGB</CODE> you will see 8/16-bits of red, then blue, then green, then red, green, blue, etc. Pixel values with less than 8 bits per color are packed together as shown in Table 4. <I>Multi-byte pixel values are stored in the native word order, just as for 16-bit color values.</I></P>
<DIV CLASS="table"><TABLE SUMMARY="Chunked Color Values">
<CAPTION><A NAME="TABLE4">Table 4: Chunked Color Values</A></CAPTION>
<H3>CUPS_ORDER_BANDED</H3>
-<P>The banded order provides each color as a separate line of
-data. Each color plane for a line is written in sequence, e.g.
-for the <CODE>CUPS_CSPACE_CMYK</CODE> colorspace you would see
-all of the cyan pixels for a line followed by the magenta,
-yellow, and black pixels for that line. This is repeated for all
-of the lines on the page. Color values are packed starting with
-the most-significant bit (MSB) first.</P>
+<P>The banded order provides each color as a separate line of data. Each color plane for a line is written in sequence, e.g. for the <CODE>CUPS_CSPACE_CMYK</CODE> color space you would see all of the cyan pixels for a line followed by the magenta, yellow, and black pixels for that line. This is repeated for all of the lines on the page. Color values are packed starting with the most-significant bit (MSB) first.</P>
<H3>CUPS_ORDER_PLANAR</H3>
-<P>The planar order provides each color as a separate page of
-data using a shared page header. Each color plane for a page is
-written in sequence, e.g. for the <CODE>CUPS_CSPACE_CMYK</CODE>
-colorspace you would see all of the cyan pixels for a page
-followed by the magenta, yellow, and black pixels for that page.
-Color values are packed starting with the most-significant bit
-(MSB) first. Each line starts on an 8-bit boundary.</P>
+<P>The planar order provides each color as a separate page of data using a shared page header. Each color plane for a page is written in sequence, e.g. for the <CODE>CUPS_CSPACE_CMYK</CODE> color space you would see all of the cyan pixels for a page followed by the magenta, yellow, and black pixels for that page. Color values are packed starting with the most-significant bit (MSB) first. Each line starts on an 8-bit boundary.</P>
-<H3>CUPS_CSPACE_W, CUPS_CSPACE_RGB, CUPS_CSPACE_RGBA, and
-CUPS_CSPACE_RGBW</H3>
+<H3>CUPS_CSPACE_RGBW</H3>
-<P>These colorspaces use the sRGB colorspace definition and
-whitepoint.</P>
+<P>This color space provides a dedicated black text channel and uses the sRGB color space definition and whitepoint for the RGB color channels. The white channel is 0 for text (or "true") black, otherwise it must contain the maximum color value: 1 for 1-bit, 3 for 2-bit, 15 for 4-bit, 255 for 8-bit, or 65535 for 16-bit.</P>
<H3>CUPS_CSPACE_KCMYcm</H3>
-<P>When <CODE>cupsBitsPerColor</CODE> is 1, 6 color planes are
-provided - black, cyan, magenta, yellow, light cyan, and light
-magenta. When <CODE>cupsBitsPerColor</CODE> is greater than 1, 4
-color planes are provided using the <CODE>CUPS_CSPACE_KCMY</CODE>
-colorspace instead.</P>
+<P>When <CODE>cupsBitsPerColor</CODE> is 1, 6 color planes are provided - black, cyan, magenta, yellow, light cyan, and light magenta. When <CODE>cupsBitsPerColor</CODE> is greater than 1, 4 color planes are provided using the <CODE>CUPS_CSPACE_KCMY</CODE> color space instead.</P>
-<P>When <CODE>cupsColorOrder</CODE> is
-<CODE>CUPS_ORDER_CHUNKED</CODE>, bit 5 corresponds to black and
-bit 0 corresponds to light magenta. For
-<CODE>CUPS_ORDER_BANDED</CODE> and
-<CODE>CUPS_ORDER_PLANAR</CODE>, each color plane is encoded
-separately.</P>
+<P>When <CODE>cupsColorOrder</CODE> is <CODE>CUPS_ORDER_CHUNKED</CODE>, bit 5 corresponds to black and bit 0 corresponds to light magenta. For <CODE>CUPS_ORDER_BANDED</CODE> and <CODE>CUPS_ORDER_PLANAR</CODE>, each color plane is encoded separately.</P>
<H3>CUPS_CSPACE_CIELab and CUPS_CSPACE_ICCn</H3>
-<P>These colorspaces map a CIE Lab color value with a D65
-whitepoint to either a 8- or 16-bit per color chunked
-(<CODE>CUPS_ORDER_CHUNKED</CODE>) format; the banded
-(<CODE>CUPS_ORDER_BANDED</CODE>) and planar
-(<CODE>CUPS_ORDER_PLANAR</CODE>) color orders are not
-supported.</P>
+<P>These color spaces map a CIE Lab color value with a D65 whitepoint to either a 8- or 16-bit per color chunked (<CODE>CUPS_ORDER_CHUNKED</CODE>) format; the banded (<CODE>CUPS_ORDER_BANDED</CODE>) and planar (<CODE>CUPS_ORDER_PLANAR</CODE>) color orders are not supported.</P>
-<P>The values are encoded and decoded using the following
-formulas:</P>
+<P>The values are encoded and decoded using the following formulas:</P>
<UL>
<H3>CUPS_CSPACE_CIEXYZ</H3>
-<P>These colorspaces map a CIE XYZ color value with a D65
-whitepoint to either a 8- or 16-bit per color chunked
-(<CODE>CUPS_ORDER_CHUNKED</CODE>) format; the banded
-(<CODE>CUPS_ORDER_BANDED</CODE>) and planar
-(<CODE>CUPS_ORDER_PLANAR</CODE>) color orders are not
-supported.</P>
+<P>These color spaces map a CIE XYZ color value with a D65 whitepoint to either a 8- or 16-bit per color chunked (<CODE>CUPS_ORDER_CHUNKED</CODE>) format; the banded (<CODE>CUPS_ORDER_BANDED</CODE>) and planar (<CODE>CUPS_ORDER_PLANAR</CODE>) color orders are not supported.</P>
-<P>The values are encoded and decoded using the following
-formulas:</P>
+<P>The values are encoded and decoded using the following formulas:</P>
<UL>
</UL>
-<P>The scaling factor for XYZ values is 1/1.1, or 231.8181 for
-8-bit values and 59577.2727 for 16-bit values. This allows for a
-slight overflow of XYZ values when converting from RGB, improving
-accuracy.</P>
+<P>The scaling factor for XYZ values is 1/1.1, or 231.8181 for 8-bit values and 59577.2727 for 16-bit values. This allows for a slight overflow of XYZ values when converting from RGB, improving accuracy.</P>
<H2 CLASS="title"><A NAME="HISTORY">Change History</A></H2>
+<H3>Changes in CUPS 1.4.7</H3>
+
+<ul>
+
+ <li>Greatly improved the detail and now include an example of the bitmap compression.</li>
+ <li>Added all missing cupsColorSpace values and a separate description of CUPS_CSPACE_RGBW.</li>
+
+</ul>
+
+
<H3>Changes in CUPS 1.2.2</H3>
<ul>
<li>Bumped raster version to 2</li>
- <li>Added RGBW colorspace</li>
+ <li>Added RGBW color space</li>
<li>Added 16 bit per color support</li>
- <li>Added cupsNumColors, cupsBorderlessScalingFactor,
- cupsPageSize, cupsImagingBBox, cupsInteger, cupsReal,
- cupsString, cupsMarkerType, cupsRenderingIntent, and
- cupsPageSizeName attributes to the page device
- dictionary</li>
+ <li>Added cupsNumColors, cupsBorderlessScalingFactor, cupsPageSize, cupsImagingBBox, cupsInteger, cupsReal, cupsString, cupsMarkerType, cupsRenderingIntent, and cupsPageSizeName attributes to the page device dictionary</li>
<li>Added raster data compression</li>
- <li>Added data type column to device dictionary
- documentation.</li>
+ <li>Added data type column to device dictionary documentation.</li>
</ul>
<ul>
- <li>Added ICC and CIE colorspaces.</li>
+ <li>Added ICC and CIE color spaces.</li>
</ul>
projects / thirdparty / cups.git / blobdiff