drivers.htm

GhostScript的源代码

<ul>
<li><b><tt>sdata</tt></b>, <b><tt>sourcex</tt></b>,
<b><tt>sraster</tt></b>, and <b><tt>id</tt></b> arguments are as for
<b><tt>copy_mono</tt></b> or <b><tt>copy_color</tt></b>
(<b><tt>data</tt></b>, <b><tt>data_x</tt></b>, <b><tt>raster</tt></b>,
<b><tt>id</tt></b>), and specify a source pixmap whose depth is the same as
the depth of the destination.

<li><b><tt>scolors</tt></b> is <b><tt>NULL</tt></b>.
</ul>

<p>
Note that if the source is a bitmap with background=0 and foreground=1, and
the destination is 1 bit deep, then the source can be treated as a pixmap
(scolors=<b><tt>NULL</tt></b>).

<h3><a name="T_spec"></a>The texture specification T</h3>

<p>
Similar to the source, the texture <b>T</b> may be a solid color, a bitmap,
or a pixmap.  If <b>T</b> is a solid color:

<ul>
<li>The texture pointer is irrelevant.

<li><b><tt>tcolors</tt></b> points to two <b><tt>gx_color_index</tt></b>
values; <b><tt>tcolors[0]</tt></b> = <b><tt>tcolors[1]</tt></b> = the
color.
</ul>

<p>
If <b>T</b> is a bitmap:

<ul>
<li>The texture argument points to a <b><tt>gx_tile_bitmap</tt></b>, as for
the <b><tt>tile_rectangle</tt></b> procedure.  Similarly,
<b><tt>phase_x</tt></b> and <b><tt>phase_y</tt></b> specify the offset of
the texture relative to the device coordinate system origin, again as for
<b><tt>tile_rectangle</tt></b>.  The tile is a bitmap (1 bit per pixel).

<li><b><tt>tcolors</tt></b> points to two <b><tt>gx_color_index</tt></b>
values; <b><tt>tcolors[0]</tt></b> is the background color (the color
corresponding to 0-bits in the bitmap), <b><tt>tcolors[1]</tt></b> is the
foreground color (the color corresponding to 1-bits in the bitmap).
</ul>

<p>
If <b>T</b> is a pixmap:

<ul>
<li>The texture argument points to a <b><tt>gx_tile_bitmap</tt></b> whose
depth is the same as the depth of the destination.

<li>tcolors is <b><tt>NULL</tt></b>.
</ul>

<p>
Again, if the texture is a bitmap with background=0 and foreground=1, and
the destination depth is 1, the texture bitmap can be treated as a pixmap
(tcolors=<b><tt>NULL</tt></b>).

<p>
Note that while a source bitmap or pixmap has the same width and height as
the destination, a texture bitmap or pixmap has its own width and height
specified in the <b><tt>gx_tile_bitmap</tt></b> structure, and is
replicated or clipped as needed.

<h3><a name="F_spec"></a>The function specification f</h3>

<p>
"Command" indicates the raster operation and transparency as follows:

<blockquote><table cellpadding=0 cellspacing=0>
<tr valign=bottom>
	<th>Bits
	<td>&nbsp;
	<td>&nbsp;
<tr valign=top>	<td>7-0
	<td>&nbsp;
	<td>raster op
<tr valign=top>	<td>8
	<td>&nbsp;
	<td>0 if source opaque, 1 if source transparent
<tr valign=top>	<td>9
	<td>&nbsp;
	<td>0 if texture opaque, 1 if texture transparent
<tr valign=top>	<td>?-10
	<td>&nbsp;
	<td>unused, must be 0
</table></blockquote>

<p>
The raster operation follows the Microsoft and H-P specification.  It is an
8-element truth table that specifies the output value for each of the
possible 2&times;2&times;2 input values as follows:

<blockquote><table cellpadding=0 cellspacing=0>
<tr valign=bottom>
	<th>Bit
	<td>&nbsp;
	<th>Texture
	<td>&nbsp;
	<th>Source
	<td>&nbsp;
	<th>Destination
<tr>	<td colspan=7><hr>
<tr valign=top>	<td align=center>7
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>1
<tr valign=top>	<td align=center>6
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>0
<tr valign=top>	<td align=center>5
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>1
<tr valign=top>	<td align=center>4
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>0
<tr valign=top>	<td align=center>3
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>1
<tr valign=top>	<td align=center>2
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>1
	<td>&nbsp;
	<td align=center>0
<tr valign=top>	<td align=center>1
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>1
<tr valign=top>	<td align=center>0
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>0
	<td>&nbsp;
	<td align=center>0
</table></blockquote>

<p>
Transparency affects the output in the following way.  A source or texture
pixel is considered transparent if its value is all 1s (for instance, 1 for
bitmaps, <tt>0xffffff</tt> for 24-bit RGB pixmaps) <b><em>and</em></b> the
corresponding transparency bit is set in the command.  For each pixel, the
result of the Boolean operation is written into the destination iff neither
the source nor the texture pixel is transparent.  (Note that the H-P
RasterOp specification, on which this is based, specifies that if the
source and texture are both all 1s and the command specifies transparent
source and opaque texture, the result <b><em>should</em></b> be written in
the output.  We think this is an error in the documentation.)

<h3><a name="Notes"></a>Notes</h3>

<p>
<b><tt>copy_rop</tt></b> is defined to operate on pixels in RGB space,
again following the H-P and Microsoft specification.  For devices that
don't use RGB (or gray-scale with black = 0, white = all 1s) as their
native color representation, the implementation of <b><tt>copy_rop</tt></b>
must convert to RGB or gray space, do the operation, and convert back (or
do the equivalent of this).  Here are the <b><tt>copy_rop</tt></b>
equivalents of the most important previous imaging calls.  We assume the
declaration:

<blockquote><b><tt>
static const gx_color_index white2[2] = { 1, 1 };
</tt></b></blockquote>

<p>
Note that <b><tt>rop3_S</tt></b> may be replaced by any other Boolean operation.
For monobit devices, we assume that black = 1.

<blockquote><font size="-1">
<pre>/* For all devices: */
(*fill_rectangle)(dev, x, y, w, h, color) ==&gt;

        { gx_color_index colors[2];
          colors[0] = colors[1] = color;
          (*dev_proc(dev, copy_rop))(dev, NULL, 0, 0, gx_no_bitmap_id, colors,
                                     NULL, colors /*irrelevant*/,
                                     x, y, w, h, 0, 0, rop3_S);
        }

/* For black-and-white devices only: */
(*copy_mono)(dev, base, sourcex, sraster, id,
             x, y, w, h, (gx_color_index)0, (gx_color_index)1) ==&gt;

        (*dev_proc(dev, copy_rop))(dev, base, sourcex, sraster, id, NULL,
                                   NULL, white2 /*irrelevant*/,
                                   x, y, w, h, 0, 0, rop3_S);

/* For color devices, where neither color0 nor color1 is gx_no_color_index: */
(*copy_mono)(dev, base, sourcex, sraster, id,
             x, y, w, h, color0, color1) ==&gt;

        { gx_color_index colors[2];
          colors[0] = color0, colors[1] = color1;
          (*dev_proc(dev, copy_rop))(dev, base, sourcex, sraster, id, colors,
                                     NULL, white2 /*irrelevant*/,
                                     x, y, w, h, 0, 0, rop3_S);
        }

/* For black-and-white devices only: */
(*copy_mono)(dev, base, sourcex, sraster, id,
             x, y, w, h, gx_no_color_index, (gx_color_index)1) ==&gt;

        (*dev_proc(dev, copy_rop))(dev, base, sourcex, sraster, id, NULL,
                                   NULL, white2 /*irrelevant*/,
                                   x, y, w, h, 0, 0,
                                   rop3_S | lop_S_transparent);

/* For all devices: */
(*copy_color)(dev, base, sourcex, sraster, id,
              x, y, w, h) ==&gt; [same as first copy_mono above]

/* For black-and-white devices only: */
(*tile_rectangle)(dev, tile, x, y, w, h,
                  (gx_color_index)0, (gx_color_index)1, px, py) ==&gt;

        (*dev_proc(dev, copy_rop))(dev, NULL, 0, 0, gx_no_bitmap_id,
                                   white2 /*irrelevant*/,
                                   tile, NULL,
                                   x, y, w, h, px, py, rop3_T)</pre>
</font></blockquote>

<h2><a name="Polygons"></a>Polygons</h2>

<p>
In addition to the lowest-level drawing operations that take integer device
coordinates and pure device colors, the driver interface includes
higher-level operations that draw polygons using fixed-point coordinates,
possibly halftoned colors, and possibly a non-default logical operation.

<p>
The <b><tt>fill_</tt></b>* drawing operations all use the center-of-pixel
rule: a pixel is colored iff its center falls within the polygonal region
being filled.  If a pixel center <em>(X+0.5,Y+0.5)</em> falls exactly on
the boundary, the pixel is filled iff the boundary is horizontal and the
filled region is above it, or the boundary is not horizontal and the filled
region is to the right of it.

<dl>
<dt><b><tt>int (*fill_trapezoid)(P10(gx_device&nbsp;*dev,
fixed&nbsp;fx0, fixed&nbsp;fw0, fixed&nbsp;fy0, fixed&nbsp;fx1,
fixed&nbsp;fw1, fixed&nbsp;fh, bool&nbsp;swap_axes,
const&nbsp;gx_drawing_color&nbsp;*pdcolor,
gs_logical_operation_t&nbsp;lop))</tt></b> <b><em>[OPTIONAL]</em></b>
<dd>Fill a trapezoid whose parallel sides are parallel to a coordinate
axis.  The corners are <em>(fx0,fy0)</em>, <em>(fx0+fw0,fy0)</em>,
<em>(fx1,fy0+fh)</em>, and <em>(fx1+fw1,fy0+fy)</em>.  We require
<b><tt>fw0</tt></b>&nbsp;&gt;=&nbsp;0,
<b><tt>fw1</tt></b>&nbsp;&gt;=&nbsp;0, and
<b><tt>fh</tt></b>&nbsp;&gt;=&nbsp;0; if <b><tt>fw0</tt></b>&nbsp;=&nbsp;0
or <b><tt>fw1</tt></b>&nbsp;=&nbsp;0, the trapezoid is actually a triangle.
If <b><tt>swap_axes</tt></b> is set, the meanings of X and Y are
interchanged.
</dl>

<dl>
<dt><b><tt>int (*fill_parallelogram)(P9(gx_device&nbsp;*dev,
fixed&nbsp;px, fixed&nbsp;py, fixed&nbsp;ax, fixed&nbsp;ay, fixed&nbsp;bx,
fixed&nbsp;by, const&nbsp;gx_drawing_color&nbsp;*pdcolor,
gs_logical_operation_t&nbsp;lop))</tt></b> <b><em>[OPTIONAL]</em></b>
<dd>Fill a parallelogram whose corners are <em>(px,py)</em>,
<em>(px+ax,py+ay)</em>, <em>(px+bx,py+by)</em>, and
<em>(px+ax+bx,py+ay+by)</em>.  There are no constraints on the values of
any of the parameters, so the parallelogram may have any orientation
relative to the coordinate axes.
</dl>

<dl>
<dt><b><tt>int (*fill_triangle)(P9(gx_device&nbsp;*dev, fixed&nbsp;px,
fixed&nbsp;py, fixed&nbsp;ax, fixed&nbsp;ay, fixed&nbsp;bx, fixed&nbsp;by,
const&nbsp;gx_drawing_color&nbsp;*pdcolor,
gs_logical_operation_t&nbsp;lop))</tt></b> <b><em>[OPTIONAL]</em></b>
<dd>Fill a triangle whose corners are <em>(px,py)</em>,
<em>(px+ax,py+ay)</em>, and <em>(px+bx,py+by)</em>.
</dl>

<dl>
<dt><b><tt>int (*draw_thin_line)(P7(gx_device&nbsp;*dev,
fixed&nbsp;fx0, fixed&nbsp;fy0, fixed&nbsp;fx1, fixed&nbsp;fy1,
const&nbsp;gx_drawing_color&nbsp;*pdcolor,
gs_logical_operation_t&nbsp;lop))</tt></b> <b><em>[OPTIONAL]</em></b>
<dd>Draw a one-pixel-wide line from <em>(fx0,fy0)</em> to
<em>(fx1,fy1)</em>.  This replaces the older <b><tt>draw_line</tt></b>
procedure, which required integer coordinates, a pure color, and no logical
operation.
</dl>

<h2><a name="High_level_drawing"></a>High-level drawing<