notes.tex

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

The second problem arises if ``certain other sizes'' refers to a list or range
of page sizes.
Lists can only be supported by distributing the individual sizes over several
media sources one at a time,
ranges are permissible with \gs~[gs~5.50] but not in standard PostScript.
If you want to make it possible for the user to specify lists in this
situation,
you must reserve an unlimited set of position numbers for this
special purpose.

One possible solution to both problems is therefore to let the driver interpret
all negative position numbers as meaning ``manual feed''.

In deciding how to implement your driver you should, however,
not forget that \ps{InputAttributes} only states which media are currently
available according to the user.
The driver still has to check whether the requested size is acceptable to the
printer.
This reduces the usefulness of specifying lists or ranges for manual feed.
In fact, if one uses \gs's ability to accept a range for \ps{PageSize},
a single position number with an implied manual feed is probably sufficient.
This is definitely the case if the device supports custom page sizes in such a
way that the total set of supported sizes can be expressed as a single
connected range of media extensions.

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

\subsection{Setting up Default User Space}	\label{PsUserSpace}

The PostScript language asserts that default user space is set up in a certain
manner in relation to the medium printed on.
PostScript programs may rely on this relationship.
Most printers, however, can neither control nor react to how the media have
been put into their input trays.
In what follows I assume that this is the case for the printer in question.

Concerning the extension (height and width irrespective of orientation) of
media,
the \ps{PageSize} entry in the \ps{InputAttributes} dictionary is available for
telling a PostScript interpreter about the media present in an input tray.
This is, however, not sufficient for the interpreter to correctly set up
default user space:
even assuming a sheet to be unmarked and to have indistinguishable sides
this merely reduces the 8~possibilities of putting it into the input tray to
two inequivalent ways (unless it is a square sheet).
They are usually described by reference to the feeding direction as
``short edge first'' and ``long edge first''.
Both lead to equivalent \ps{PageSize} entries in \ps{InputAttributes}.

The implementation of a PostScript output device for such a printer must
therefore be accompanied by rules stating what the ``right'' ways for putting
media into input trays are.
In order to prevent printing beyond the edges of a sheet,
the minimum is to state whether the interpreter assumes media will be fed short
edge first or long edge first.
A more detailed rule would add a description of default user space on
a sheet lying in the input tray.
This enables the user in addition to reliably position the output with respect
to matter already on the medium (e.g., a watermark).

\begin{note}
  At least three versions of the {\it PostScript Language Reference
  Supplement\/}~\cite{PSSupplement2017,PSSupplement3010,PSSupplement3011}
  impose special rules
  for the location of default user space when printing on envelopes.
  In my opinion these rules are undesirable because they require
  \textit{the program generating a PostScript page\/} to know
  whether printing will be done on envelopes or on ordinary paper
  of the same size.
  As this has nothing to do with the layout of text within the page,
  the program should not need to know this.
  But even worse, the rules are chosen such that if one requests landscape
  orientation (which is usually desired for envelopes) the standard rule
  governing the behaviour of \ps{setpagedevice} (rotate by $+90^\circ$)
  actually produces output standing on its head when applied to an envelope
  having the flap along its longer edge!
  
  If, on the other hand, a printer has particular requirements for feeding
  envelopes and this does not produce the desired result when keeping to
  PostScript's default rules,
  the output device should deal with this problem, possibly triggered by a
  page device parameter or by imposing the rule that certain page sizes are
  always interpreted as envelopes.

  My advice is therefore to ignore these rules,
  but you should form your own conclusion based on your printer's requirements.
\end{note}

All this applies only to a default state for default user space.
This state is characterized by requesting a page in portrait orientation
($\hbox{width} < \hbox{height}$)%
  \footnote{It is also assumed that the size requested is available,
    otherwise the media selection process might influence the location and
    scale of default user space (\ps{PageSize} recovery policies~3 and~4).}
and omitting requests for any of the page device parameters
\ps{LeadingEdge}, \ps{Orientation}, \ps{ImageShift},
\ps{PageOffset}, \ps{Margins}, \ps{Tumble}, \ps{MirrorPrint},
and possibly others.
The resulting structure on the sheet is sometimes called the
\d{canonical page in portrait orientation},
but you should think of this situation as the set of conditions
under which the statement about the position of default user space
on a sheet in the input tray is valid.

Most of the parameters just mentioned are defined in terms of their effect
with respect to this default orientation.
For example,
on receiving a \ps{PageSize} request for landscape orientation the interpreter
must rotate default user space 90~degrees counterclockwise with respect to
its position for portrait orientation and shift the origin into the
new lower left corner.

The parameter \ps{LeadingEdge} makes it possible for the user to tell the
interpreter that a sheet has been put into the input tray in a non-standard
way.
Note that different devices can differ in which of the 4~possibilities is the
default:
for an interpreter assuming a short-edge orientation in the input tray it will
be either~0 or~2,
while a long-edge-oriented one will have~1 or~3 as its default.
This argument can be reversed:
specifying which of these values is the default assumed by the interpreter
together with the information which side of the sheet will be printed on
uniquely selects one of the 8 possible orientations in the input tray as the
``right'' one for the default situation.

The parameter \ps{Orientation} should only be supported by devices
with media of continuously variable page sizes (printing to roll-fed media,
screen displays or file formats):
the values~1 and~3 cannot be supported on cut-sheet media,
and the user can achieve the effect of~2 by choosing a \ps{LeadingEdge} value
differing by~2 from its default.

You must decide which of these parameters will be supported by your driver.
Note that some are automatically available for every \gs\ device.

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

\subsection{Device Coordinates}

The rules of PostScript about the relative positioning of default user space
and the medium are intended to ensure that a PostScript program need not know
about the device coordinate system.
This information is, however, still accessible to the program:
the operator \ps{defaultmatrix}, for example,
returns the default transformation matrix for the device,
and with this information a PostScript program can unambiguously determine the
position of the device coordinate system with respect to default user space.
Hence the following discussion indeed belongs under the heading of
PostScript-visible properties of the output device.

When writing your driver you must choose a device coordinate system.
This is no problem; just do it.
However, I am not aware of any statement in PLR3 which states that the
device coordinate system is a fixed property of the output device.
``Fixed'' in this context means ``fixed with respect to the feeding direction''
or equivalently ``fixed with respect to the default of default user space''.
If you therefore wish to switch your device coordinate system if the user
requests landscape orientation or on any other occasion the user executes
\ps{setpagedevice},
this is perfectly legitimate.
You might even do it in such a manner that \ps{defaultmatrix} returns the
same value under all circumstances.
This freedom is actually desirable,
because it means that you can choose whatever convention for device coordinates
is the simplest for you to implement depending on the current set of
page device parameters.

However, if you look at the description of the \ps{PageOffset} and \ps{Margins}
parameters you'll find statements that for \ps{PageOffset}
``the repositioning is typically accomplished by altering the current
transformation matrix, although on some devices it may instead be accomplished
by device-dependent means that are independent of the graphics state
(in particular, of the CTM)''~\cite[page 415]{PostScript3} and that
for \ps{Margins} the latter case is the typical one.
(Incidentally, as both parameters have to be specified with respect to the
direction of the axes of the device coordinate system,
your driver's documentation should tell the user where these axes point to.)
If your device coordinates are fixed with respect to the default default user
space,
you will have to modify the default transformation matrix,
and conversely if you wish the influence of such parameters not to be visible
in the CTM you must shift your device coordinates.

Concerning \ps{PageOffset} and \ps{Margins} these discussions are, however,
slightly academic because \gs\ implements these parameters for all devices
and does it via modifications of the default transformation matrix
in both cases~[gs~5.50].
At least for \ps{Margins} you can easily override this behaviour but I wouldn't.

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

\subsection{Other Standard Page Device Parameters Describing Device
  Capabilities}

The following page device parameters defined in PLR3 refer to special
hardware functionality:
\begin{quote}
  \ps{InsertSheet}, \ps{ManualFeed}, \ps{TraySwitch},
  various parameters for roll-fed media,
  \ps{Duplex},
  \ps{Collate}, \ps{Jog}, \ps{OutputFaceUp},
  \ps{MaxSeparations}, \ps{SeparationColorNames}.
\end{quote}
Absence of one of these parameters indicates that the feature is not
supported by the device.
The converse is not true.
You will have to decide which of these features you can support.

In addition, there exist also position numbers for media destinations
(keys in \ps{OutputAttributes}),
similar to the numbers for media sources.
If your printer has several output destinations your driver should
support them as well.

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

\subsection{Non-Standard Page Device Parameters}

If your driver is going to offer functionality which cannot be expressed in
terms of standard page device parameters,
you will have to define new ones.

You should take some care not to choose parameter names which can collide with
other definitions.
At the least you should check the current edition of the
{\it PostScript Language Reference Supplement\/}~\cite{PSSupplement3011}
in order to find out whether there is already a semi-standard parameter
for this functionality or one having the intended name but another meaning.

%******************************************************************************

\section{General Properties of a \Gs\ Device}

Unless there is an explicit reference to a different version,
everything which follows in this and subsequent sections is based on
\gs\ version 5.50.

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

\subsection{Definitions}

A \gs\ device driver defines one or more \d{ghostscript devices}.
A ghostscript device is identified by its name (1~to~8 letters, digits or
underscores, starting with a letter~\cite{Drivers5.50}\footnote{%
  These restrictions are probably the combined result of restrictions from
  the C~language and from some file systems.
  Effectively, this means that you can ignore at least the length restriction
  on almost all platforms.}) and characterized by a
C~variable which must be called {\tt gs\_\textit{name}\_device}.
% No italic correction for "name" here; it looks worse.
This is the \d{device structure instance},
its type is the \d{device structure}.
The device structure instance is a prototype for the data structure
(\d{device instance}, sometimes also called \d{driver instance})
which is actually used when a device is installed in the graphics state.

\ifdraft
??? Forwarding device, band device,
life cycle (at which point in a multi-function open call is the device open?
Will partially opened devices be closed?)
\fi

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

\subsection{Relation to Output Devices}

There is a one-to-one correspondence between ghostscript devices and 
PostScript output devices supported by \gs.

Technically, this can be inconvenient if your driver implements lots of
different output devices and you do not wish to clutter \gs's device list
with all these names.
In that case you should introduce sub-devices based on particular parameter
values.
My \textit{hpdj\/} driver for example uses \texttt{hpdj} as the device name but
in addition selects a particular printer model with the
page device parameter \ps{Model}.
As the latter determines which process colour models and page sizes are
supported by the driver,
this parameter in fact distinguishes between output devices within one
ghostscript device.

If you choose to implement such sub-devices you should try to simulate the
behaviour of \ps{setpagedevice} for \ps{OutputDevice}
(initialization with default values)
whenever the output device is changed.
Your \prog{put\_params} implementation should therefore check for the
sub-device-changing parameters first.
However, you should only reset those parameters which the user can override.
%??? This does not apply to the resolution when set from the
% command line [gs~6.01].

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

\subsection{Device Structure}

\ifdraft
??? Dynamic memory
\fi

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

\subsubsection{Device Procedures}

Among the variables in the device structure are several dealing with functions:
\begin{itemize}