notes.tex

openmeetings组件之GS openmeetings组件之GS openmeetings组件之GS

\subsection{Definition}

A PostScript interpreter may support several \d{output devices}.
A \d{page device} is a special kind of output device.
Its state is characterized by \d{page device parameters}.

The \d{current (output) device} is part of the graphics state and can be
inspected with \ps{currentpagedevice}.
A new page device can be selected by calling \ps{setpagedevice}%
  \footnote{%
    For devices which are not page devices, other methods have to be
    employed.
    The null device, for example, is installed by calling \ps{nulldevice}.}
and passing the device name as a value for the \ps{OutputDevice} page device
parameter.%
  \footnote{%
    This does work with \gs\ but it produces a drastically reduced page device
    dictionary without, e.g., \ps{HWResolution}~[gs~5.50, gs~6.50].
    The official \gs\ interface for switching output devices from PostScript
    is via the non-standard \ps{selectdevice} operator~\cite{Use5.50}.}
This resets all page device parameters to the default values appropriate for
the new device.

%==============================================================================

\subsection{Identity and Basic Properties}

An output device is identified by its name.
If the interpreter supports several output devices,
the \ps{OutputDevice} resource category should contain an entry for each device,
indexed by its name and listing the associated properties in an
\d{output device dictionary}.%
  \footnote{\Gs\ does not list its available devices in the \ps{OutputDevice}
    resource category~[gs~5.50, gs~6.50].
    Furthermore, although defining an output device dictionary as an external
    resource makes it visible to \ps{resourcestatus} and \ps{findresource},
    \gs\ versions before~6.50 will not list it with \ps{resourceforall} unless
    you execute \ps{findresource} first~[gs~5.50, gs~6.01].
    This makes \ps{resourceforall} useless.
    However, you can obtain the list of supported devices from \gs's
    non-standard \ps{devicenames} operator.
  }
Section~6.4 of PLR3 contains a list of these properties:
\begin{itemize}
  \item media classes
  \item page sizes
  \item resolutions
  \item process colour models
  \item trapping details dictionary types
\end{itemize}
It is possible (but there is no corresponding statement in PLR3)
that a PostScript program relies on the assumption that,
if a value is listed as supported,
it is supported independent of the values chosen for other parameters
unless the meaning of the property in question restricts it explicitly to a
particular situation (this is only the case for \ps{DeviceN}).
This is a possible rule for separating output devices.

Therefore, if you have constraints among the values you wish to support
(e.g., \ps{DeviceGray} can be used at 600\,ppi but \ps{DeviceCMYK} is only
possible at 300\,ppi),
you should consider implementing these groups of unconstrained values
in different output devices.
This might be inconvenient, though,
and I myself have usually disregarded this advice.

%==============================================================================

\subsection{Process Colour Models}

PostScript defines six \d{process colour models}:
\begin{quote}
  \ps{DeviceGray},
  \ps{DeviceRGB}, \ps{DeviceRGBK},
  \ps{DeviceCMY}, \ps{DeviceCMYK},
  \ps{DeviceN}.
\end{quote}
A process colour model defines the \d{colorants} used by a device.
\ps{DeviceN} is a parameterized process colour model which has to be
supplemented by an explicit list of colorants (page device parameter
\ps{SeparationColorNames}).
Normally each device has one \d{native process colour model},
but it may support others.\footnote{
  For example, a monochrome device capable of producing separations might
  support the process colour model
  \ps{DeviceCMYK}~\cite[page~424]{PostScript3}.}

Each process colour model has an underlying \d{native colour space}.
Because some process colour models are based on the same colour space
only the following four colour spaces act as native colour spaces:
\begin{quote}
  \ps{DeviceGray},
  \ps{DeviceRGB},
  \ps{DeviceCMYK},
  \ps{DeviceN}.
\end{quote}
The colour spaces \ps{DeviceGray}, \ps{DeviceRGB}, and \ps{DeviceCMYK} are
called \d{device colour spaces}.
The colour space \ps{DeviceN} is \emph{not\/} a device colour space
but one of the \d{special colour spaces}.

Note that a designation like ``\ps{DeviceRGB}'' can therefore denote a
colour space, a native colour space or a process colour model.
You have to find out which before you will be able to correctly understand
the statement containing such a name.

%==============================================================================

\subsection{Media Selection}

\subsubsection{Media Sources}

PostScript assumes the output device to have several \d{media sources},
each identified by an integer (\d{position number}).
You will have to decide how to associate these numbers with input trays or
whatever your printer supports.

Properties of the media currently present in a tray can be stored in the
\ps{InputAttributes} dictionary in the page device dictionary and are
accessed during \d{media selection}.

If the printer is capable of providing information on the properties of media
currently available in its input trays,
\ps{InputAttributes} should therefore be initialized appropriately
by the driver.

%------------------------------------------------------------------------------

\subsubsection{The Process}

PostScript's media selection process composes an \d{input media request} from
those among the page device parameters
\ps{PageSize}, \ps{MediaColor}, \ps{MediaWeight}, \ps{MediaType},
\ps{MediaClass}, and \ps{InsertSheet}
which are not \ps{null} (some devices may add others) and
tries to find a matching entry in \ps{InputAttributes}.
Apart from \ps{MatchAll}, only those parameters which a device
considers for inclusion in a media request should appear in an
\ps{InputAttributes} entry.

An entry in \ps{InputAttributes} \d{matches} the request if
\begin{itemize}
  \item it contains matching entries (equal values, in the case of
    \ps{PageSize} with a tolerance of 5~bp) for all parameters in the
    request and
  \item either
    \begin{itemize}
      \item does not have a \ps{MatchAll} entry which is \ps{true} or
      \item does have a \ps{MatchAll} entry which is \ps{true} and
	does not contain any entries in addition to \ps{MatchAll} and those
	present in the media request.
    \end{itemize}
\end{itemize}
Formally, you can define a relation ``$\leq$'' between two media requests or
\ps{InputAttributes} entries $a$ and~$b$ as follows:
\begin{displaymath}
  a \leq b \quad :\Longleftrightarrow \quad
  \vtop{\advance\hsize by -4cm
    All parameters present in $a$ (except for \ps{MatchAll} in an
    \ps{InputAttributes} entry) are also present in~$b$ and have matching
    values.}
\end{displaymath}
The match rule can then be rephrased in the following manner:
\begin{quote}
  An \ps{InputAttributes} entry~$e$ matches the input media request~$r$
  if and only if $r \leq e$
  except when \ps{MatchAll} is defined and \ps{true} in~$e$.
  In the latter case one needs $r = e$.
\end{quote}
A media request is therefore a set of minimal requirements a media source must
satisfy in order for the document to be printed from that source.

Exceptions are possible if no match is found,
the \ps{Policies} dictionary permits ignoring at least one parameter in the
request,
and a matching request $r' < r$ can be formed.
PLR3 demands that in this case the interpreter must set the ignored
page device parameters to \ps{null}\footnote{%
  \Gs\ does not currently do it [gs~6.01].}.
The only exception is \ps{PageSize} which will be set to the value present
in the \ps{InputAttributes} entry selected.
The state of the device thus becomes as if the document had originally
requested~$r'$.

%------------------------------------------------------------------------------

\subsubsection{Selection Parameters Which are also Configuration Parameters}

Let a ``configuration parameter'' be a page device parameter which influences
the way the output device adapts to the medium,
while a ``selection parameter'' is a parameter considered for inclusion in a
media request.
The 6~standard selection parameters can then be classified as follows:
\begin{itemize}
  \item
    also a configuration parameter:
      \ps{PageSize},
      \ps{MediaClass},
      % Explicitly defined to be an "arbitrary string representing attributes
      % of the medium that may require special action by the output device"
      % (PLR3 p. 402).
  \item
    not a configuration parameter:
      \ps{InsertSheet},
      \ps{MediaType},
  \item
    possibly a configuration parameter:
      \ps{MediaColor} (probably not),
      \ps{MediaWeight} (probably yes).
\end{itemize}

If a particular selection parameter is also a configuration parameter,
it must be set correctly for the medium chosen by the media selection process.
Assuming the correct value to be non-null and disregarding the
\ps{PageSize} parameter,
this is the case if and only if the parameter is correctly specified in the
\ps{InputAttributes} entry \emph{and\/} the documents requests the same value:
\begin{itemize}
  \item
    If the parameter is not specified in \ps{InputAttributes} and a match
    results, the value in the page device dictionary will be \ps{null}.
  \item
    If the parameter is not correctly specified in \ps{InputAttributes},
    the parameter's value in the page device dictionary will either be this
    incorrect value or \ps{null}.
  \item
    If the parameter is correctly specified in \ps{InputAttributes},
    the document requests a different value,
    and a match results,
    the value will also become \ps{null}.
\end{itemize}
The \ps{PageSize} parameter is different because instead of being set to
\ps{null} when the request cannot be satisfied it is set to the value
belonging to the \ps{InputAttributes} entry chosen.
In my opinion this behaviour would have been desirable for all
configuration parameters considered for selection.

I wish to draw two conclusions from this dicussion:
\begin{itemize}
  \item
    If the output device uses a selection parameter for configuration,
    the interpreter should be configured such that the \ps{InputAttributes}
    entries contain the correct values
    and the \ps{Policies} dictionary should not permit the request to be
    ignored.
  \item
    As already mentioned in a footnote,
    \gs's behaviour with respect to non-matching parameters is not
    currently~[gs~6.01] PostScript-conforming,
    hence the preceding discussion does not really apply.
    However, I am not aware of any statement in the documentation that this
    was a deliberate implementation decision,
    hence this behaviour cannot be relied upon.

    Therefore I still conclude that
    a \gs\ device should not use selection parameters for configuration
    unless the driver can sense these media properties.

    The reason is that the typical execution environment for \gs\ is a
    single-user PC with a dedicated printer completely controlled by the user.
    If this user inserts media with properties the driver needs to know,
    it is unreasonable to require the parameter to be set in two places.
\end{itemize}

%------------------------------------------------------------------------------

\subsubsection{User Interaction via \ps{Policies}}

The user may set a policy code of~2 in the \ps{Policies} dictionary.
This indicates that a mismatch should result in some kind of device-specific
interaction with an external entity,
for example asking a human operator to insert media of the size requested and
waiting for confirmation.
This is not supported by \gs\ and results in a
\ps{configurationerror}~[gs~5.50] just as for a policy value of~0.
Should it be implemented one day, this will hopefully be independent of
the \gs\ device in question.
You should therefore ignore this feature.

%------------------------------------------------------------------------------

\subsubsection{Automatic Switch to Manual Feed}

A user might wish to tell the interpreter something like the following:
``I have put A4 sheets into the input tray where they can be fed automatically,
but I am prepared to feed certain other sizes manually''.
The second part of this statement cannot be easily expressed in
\ps{InputAttributes} for two reasons.

The first and more important one is that you cannot request additional actions
(like setting \ps{ManualFeed} to \ps{true}) to be performed automatically if a
particular media source is selected and certain conditions are met.\footnote{%
  One might consider (mis)using the \ps{Install} procedure for this purpose
  provided it can determine which source has been selected.
  However, there is no standard way for that,
  and in addition PLR3 does not say whether it is permitted for
  \ps{Install} to call \ps{setpagedevice}.
  This is a problem because the latter calls \ps{Install} again.}
The only choices I see are
to make manual feed implicit in the media source by convention or
to provoke a \ps{PageSize} mismatch.
The first possibility must be supported by the driver,
the second requires the user to choose a \ps{PageSize} recovery policy of~2,
possibly combined with a \ps{PolicyReport} procedure setting \ps{ManualFeed} to
\ps{true}.