alter a few more places in the documentation to say 'vector' instead ofPJL_pdfwrite_config

or as well as 'high level'

2 files changed, 11 insertions, 10 deletions

diff --git a/doc/Drivers.htm b/doc/Drivers.htm
index 9f72555c3..8bfdda921 100644
--- a/doc/Drivers.htm
+++ b/doc/Drivers.htm
@@ -65,7 +65,7 @@
     <li><a href="#Paths">Paths</a>
     <li><a href="#Images">Images</a> [<a href="#Images_notes">Notes</a>]
     <li><a href="#Text">Text</a> [<a href="#Text_notes">Notes</a>]
-    <li><a href="#Unicode">Unicode support for high level devices</a>
+    <li><a href="#Unicode">Unicode support for high level (vector) devices</a>
 </ul>
   <li><a href="#Reading_bits_back">Reading bits back</a>
   <li><a href="#Parameters">Parameters</a>
@@ -2359,7 +2359,7 @@ In addition to the lower-level drawing operations described above, the
 driver interface provides a set of high-level operations.  Normally these
 will have their default implementation, which converts the high-level
 operation to the low-level ones just described; however, drivers that
-generate high-level output formats such as pdfwrite, or communicate with devices
+generate high-level (vector) output formats such as pdfwrite, or communicate with devices
 that have firmware for higher-level operations such as polygon fills, may
 implement these high-level operations directly.  For more details, please
 consult the source code, specifically:
@@ -2934,10 +2934,10 @@ return an enumerator.  Furthermore, the implementation of the
 anything, even if it doesn't want to draw anything on the output.  See the
 comments in <a href="../base/gxtext.h">gxtext.h</a> for details.
 
-<h4><a name="Unicode"></a>Unicode support for high level devices</h4>
+<h4><a name="Unicode"></a>Unicode support for high level (vector) devices</h4>
 
 <p>
-<p>Implementing a new high level device, one may need to translate <code>Postscript</code>
+<p>Implementing a new high level (also known as vector) device, one may need to translate <code>Postscript</code>
 character codes into <code>Unicode</code>. This can be done pretty simply.
 
 <p>For translating a <code>Postscript</code> text you need to inplement the device
@@ -3211,18 +3211,19 @@ will occur.
 <h4><a name="Device parameters affecting interpretation"></a>Device parameters affecting interpretation</h4>
 
 <p>
-Some parameters have been defined for high level device drivers which affect
+Some parameters have been defined for high level (vector) device drivers which affect
 the operation of the interpreter. These are documented here so that other devices
 requiring the same behaviour can use these parameters.
 
 <blockquote><dl>
 <dt><b><em>/HighLevelDevice</em></b>
-<dd>True if the device is a high level device. Currently this controls haltone emission
+<dd>True if the device is a high level (vector) device. Currently this controls haltone emission
 during setpagedevice. Normally setpagdevice resets the halftone to a default value, which is
 unfortunate for high-level devices such as ps2write and pdfwrite, as they are unable to tell
 that this is caused by setpagdevice rather than a halftone set by the input file. In order to prevent 
 spurious default halftones being embedded in the output, if /HighLevelDevice is present and
 true in the device paramters, then the default halftone will not be set during setpagedevice.
+Also prevents interpolation of imagemasks during PDF interpretation.
 </dd>
 
 <dt><b><em>/AllowIncrementalCFF</em></b>
@@ -3262,7 +3263,7 @@ for devices which can handle PDF text rendering modes directly.
 
 <dt><b><em>/WantsToUnicode</em></b>
 <dd>In general, Unicode values are not of interest to rendering devices, but
-for high level devices, they can be extremely valuable. If this parameter is
+for high level (aka vector) devices, they can be extremely valuable. If this parameter is
 defined as true then ToUnicode CMaps and GlyphName2Unicode tables will be
 processed and stored.
 </dd>
diff --git a/doc/Use.htm b/doc/Use.htm
index 08bfb55f2..853f28304 100644
--- a/doc/Use.htm
+++ b/doc/Use.htm
@@ -2660,7 +2660,7 @@ of using the normal intelligent substitution algorithm.  Also, in this
 case, the font returned by <code>findfont</code> is the actual font
 named <em>fontname</em>, not a copy of the font with its
 <code>FontName</code> changed to the requested one.
-THIS OPTION SHOULD NOT BE USED WITH HIGH LEVEL DEVICES, such as
+THIS OPTION SHOULD NOT BE USED WITH HIGH LEVEL (VECTOR) DEVICES, such as
 <code>pdfwrite</code>, because it prevents such devices from
 providing the original font names in the output document. The
 font specified (<em>fontname</em>) will be embedded instead,
@@ -3429,7 +3429,7 @@ memory. For example, to allow use of 30Mb of extra RAM use:
 <p>
     <code>-c&nbsp;30000000&nbsp;setvmthreshold&nbsp;-f</code>.
 <p>This can also be useful in processing large documents when using a
-high-level output device (like pdfwrite) that maintains significant internal
+high-level (vector) output device (like pdfwrite) that maintains significant internal
 state.  In fact, the <a href="Language.htm#.setpdfwrite"><tt>.setpdfwrite</tt></a>
 operator used by the ps2pdf script and others sets a vmthreshold value of
 3&nbsp;MB to account for this.
@@ -3682,7 +3682,7 @@ usage.
 <dt><code>'</code><dd>contexts, create/destroy
 <dt>&nbsp;&nbsp;&nbsp;<code>"</code><dd>contexts, every operation
 <dt><code>^</code><dd>reference counting
-<dt><code>_</code><dd>high-level output
+<dt><code>_</code><dd>high-level (vector) output
 <dt><code>!</code><dd>Postscript operator names (this option is available only
 when Ghostscript is compiled with a predefined macro DEBUG_TRACE_PS_OPERATORS)
 <dt><code>|</code><dd>(reserved for experimental code)