notes.tex

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

%******************************************************************************
% File:     @(#)$Id: notes.tex,v 1.11 2001/02/24 06:00:16 Martin Rel $
% Contents: Notes an writing a ghostscript device driver
%	    This is a TeX file using the LaTeX package.
% Author:   Martin Lottermoser, Greifswaldstrasse 28, 38124 Braunschweig,
%           Germany. E-mail: [e-mail].
%
%******************************************************************************
%
%	Copyright (C) 2000, 2001 by Martin Lottermoser
%	All rights reserved
%
%******************************************************************************

\documentclass[twoside,a4paper]{article}

% Macros to extract RCS information
\def\RCScontents$#1:#2 ${\ignorespaces#2}
\def\RCSDate$#1: #2/#3/#4 #5${#2--#3--#4}

% Extracted RCS information.
\setbox0=\hbox{\RCScontents$Locker:  $}
\ifdim\wd0=0pt
  \edef\Revision{\RCScontents$Revision: 1.11 $}
  \edef\Date{\RCSDate$Date: 2001/02/24 06:00:16 $}
  \def\BottomInfo{Version \Revision}
\else
  \edef\Revision{\RCScontents$Revision: 1.11 $+}
  \def\Date{\today}
  \def\BottomInfo{Version of \Date}
  \def\draft{}
\fi

% Title page information
\author{Martin Lottermoser\cr
  {\tt [e-mail]}\cr
  Greifswaldstra{\ss}e 28\cr
  38124 Braunschweig\cr
  Germany}
\title{Notes on Writing a {\it Ghostscript\/} Device Driver for Printers}
\date{Version \Revision\ (\Date)}

% 25mm margins for A4
\textwidth=160truemm
\evensidemargin=-0.4truemm \oddsidemargin=\evensidemargin
\topmargin=-0.4truemm
\textheight=247truemm
\advance\textheight by -\headheight
\advance\textheight by -\headsep
\advance\textheight by -\footskip

% Page layout
\pagestyle{myheadings}
\makeatletter
\markboth{\@title}{\@title}
\def\@oddfoot{{\tiny\sl \BottomInfo\/}\hfil}
\makeatother

% Paragraph layout
\setlength{\parindent}{0mm }
\setlength{\parskip}{1.5mm plus 0.5mm minus 0.5mm }

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

% Normal underscore
\catcode`\_=\active
\newcommand{\normalUS}{\catcode`\_=\active \def_{\char`\_}}
\catcode`\_=8

% My version of LaTeX does not know that cmtt has braces and substitutes them
% from cmsy.
\newcommand{\lb}{\char"7B}
\newcommand{\rb}{\char"7D}

% Abbreviations
\newcommand{\gs}{\textit{ghostscript\/}}
\newcommand{\Gs}{\textit{Ghostscript\/}}

% Markup
\newenvironment{note}{\begin{quote}\small}{\end{quote}}
\newenvironment{program}{\begin{quote}
    \normalUS\ttfamily\obeylines\obeyspaces\parskip=0mm \parindent=0mm }%
  {\end{quote}}
\newcommand{\ps}[1]{{\sffamily\bfseries #1}}	% PostScript names in the text
\renewcommand{\d}[1]{{\bfseries #1}}	% definition of a concept or name
\newcommand{\prog}[1]{\texttt{#1}}
\newcommand{\file}[1]{\texttt{#1}}	% file names

\bibliographystyle{plain}

\hyphenation{ghost-script}

\newif\ifdraft \draftfalse
\expandafter\ifx\csname draft\endcsname\relax\else \drafttrue \fi

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

\begin{document}
\maketitle

\tableofcontents

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

\section{Introduction}

This document contains remarks which I consider useful for persons implementing
a \gs\ device driver for printers.
It is based on my experiences and in particular the mistakes I made in
implementing the \textit{hpdj/pcl3\/} driver~\cite{hpdj,pcl3}.
And yes, I have made lots of mistakes,
and I do not guarantee anything about the accuracy of this document either.

The topics covered in this document can be arranged in the following
categories:
\begin{itemize}
  \item Suggestions on how to approach the implementation of a \gs\ device
    driver
  \item Information which is in my opinion necessary for properly implementing
    a driver but which I could not find in \gs's documentation
  \item Information I have collected for convenience
  \item Parts which logically belong into the design documentation for
    the \textit{hpdj/pcl3\/} driver but which have wider applicability
\end{itemize}

As the title indicates,
this is not an exhaustive introduction on how to write a \gs\ device driver.
You will need to access other documentation as well
(and, of course, do some thinking of your own),
preferably before reading this paper.

This document is still largely incomplete.	%???

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

\subsection{The Most Important Advice on Writing a \Gs\ Device Driver}

\begin{center}
  \bigskip
  \begin{picture}(120, 30)
    \put(60,15){\oval(120,30)}
    \put(60,15){\makebox(0,0){\hfil\Large\em Don't do it!\/\hfil}}
  \end{picture}
  \bigskip
\end{center}

You should disregard this advice only if all of the following conditions are
true:
\begin{itemize}
  \item You are prepared to spend a substantial amount of time on this task.
  \item You have or are prepared to acquire sufficient knowledge of PostScript
    to find relevant information in the
    {\it PostScript Language Reference\/}~\cite{PostScript3},
    hereafter abbreviated as ``PLR3''.
    You must know chapters~6 and~7 (excluding sections~6.3 and~7.1) pretty well.
  \item You either know \gs's internal APIs (in particular~\cite{Drivers6.01})
    and programming conventions or are prepared to learn them.
    (Obvious, of course, but I still thought I'd better mention it.)
  \item You can read large amounts\footnote{%
      % Aladdin gs 5.50: 243089 lines for *.c and *.h, 32914 for *.ps.
      % loc gave 168705 NLOC for *.c and *.h.
      \Gs\ has roughly 250,000~lines of C and 33,000~lines of PostScript
      code~[gs~5.50].}
    of source code (C and PostScript) written by another person and
    locate and understand those sections which are relevant to a problem you
    have encountered.
    If you wish to write a reliable driver,
    you will have to do this much more often than you expect.
  \item In view of in particular the amount of time you will have to spend and
    the amount of frustration you will experience,
    the driver you have in mind will offer new functionality which is worth
    this effort.
    I would not expect this to be the case unless you have a sufficiently large
    group of users.
\end{itemize}
If you conclude from this that my own experiences in writing \gs\ device
drivers were not entirely pleasant, you are right.
In particular,
I have serious doubts about whether the result justifies the effort I put into
it.
This document is an attempt to improve the result-to-effort ratio by making
my experience available to others.

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

\subsection{Restrictions}

This document concerns itself only with printer drivers.
By this I mean devices with the following properties:
\begin{itemize}
  \item From the point of view of PostScript, we are dealing with a page device.
  \item Processing in the driver can be split into two phases:
  \begin{itemize}
    \item creating a rasterized representation (pixmap) of the entire page in
      memory,
    \item converting it into another format appropriate for a particular kind
      of hardware or software external to \gs, and
      sending the converted data to a file.
  \end{itemize}
  \item From the point of view of \gs, we are dealing with a device derived
    from the {\it prn\/} device.
\end{itemize}

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

\subsection{Conventions}

A word or group of words \d{in this type} has a special meaning.
The meaning is sometimes explained at the point where the term is denoted in
this manner,
but the main purpose is to alert the reader to the existence of a special
meaning connected with these words in the context of PostScript or \gs.

A reference like ``[gs~$n.m$]'' accompanying a statement means that I have
checked this statement to be true for \gs\ version~$n.m$.
These are typically statements about bugs in \gs\ or
information I could not find in \gs's documentation
but which I obtained from the source code or by experiment.

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

\section{General Approach}

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

\subsection{PostScript First}

You should base your implementation on those properties of your driver which
will be visible in PostScript.

One reason is that \gs\ is changing fairly rapidly.
Although some effort is made to remain backward-compatible,
you cannot expect this to be always possible.
If you base your design on PostScript concepts,
the result is much more likely to be able to adapt easily to changes in \gs.
The same applies in areas where \gs\ does not yet correctly or entirely support
the PostScript language definition.

The second reason is that the PostScript language is well documented and offers
a reasonably broad range of concepts for you to use.
A description of similar coverage at the level of \gs's driver API does not
exist.
You will have to fill conceptual gaps in the latter from the former.

Finally, you should not dismiss the possibility that you might later want to
write a similar driver for another PostScript interpreter.
Everything which depends on PostScript only could then be reused unchanged,
although I would expect this to happen more on the level of structure and
concepts then with actual lines of code.

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

\subsection{Architecture}

It is almost certain that you'll find that a large part of what you need to
implement is entirely independent of the printer you wish to drive
and could be used for other drivers as well.
This is due to a gap between the functionality offered by the \gs\ kernel and
the functionality needed by most printer drivers.
This gap is only partly closed by the abstract \textit{prn\/} device
and this has led to a certain amount of duplicated code in \gs\ drivers.

One solution to this problem is to reuse code from another driver.
This is easiest to do if this functionality has been implemented in terms of an
abstract \gs\ device derived from the \textit{prn\/} device.
Your driver can then use this device instead of \textit{prn\/} as its base
device.
The \textit{pcl3\/} driver contains such an intermediate component in the
\textit{eprn\/} (``extended \textit{prn\/}'') device.
Its implementation has about
4700~brutto and 2400~netto lines of code.	% pcl3 3.0.2
This gives you an impression of the size of the functionality gap you would
otherwise have to bridge on your own,
although admittedly not everything implemented in \textit{eprn\/} is
absolutely essential for every printer driver.

Independent of whether \textit{eprn\/} suits your needs or not,
you should always implement the universal part of your functionality
in a reusable form.

At the other end of your implementation you should consider encapsulating
printer-specific routines in a form which is largely independent of \gs.
This also makes it easier to reuse this code in other contexts.
The correct level of abstraction for this API is almost certainly near the
point where your driver has obtained a pixmap for the page to be printed and
has to convert it into the printer's language.

If you introduce these two layers of functionality,
the ``real'' driver will just be the intermediate layer connecting these two.
\begin{note}
  In the implementation of my \textit{pcl3\/} driver about
  47~\% of the code belongs to the high-level \textit{eprn\/} device,
  21~\% can be found in the printer-specific backend,
  and 32~\% are contained in the intermediate layer.
  % This is based on NLOCs. BLOC-based values are even better: 49%, 24%, and
  % 27%. This reflects the more extensive documentation I've provided in the
  % reusable parts.
  % (BLOC, NLOC) as of pcl3 3.0.2: (4658, 2361), (2263, 1084), (2620, 1616).
  This means that roughly two thirds of the code could be reused
  in other contexts!
\end{note}

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

\section{Properties of an Output Device in PostScript}

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