DPS

File Release Notes and Changelog

Release Name: 0.0.0

Notes:
                        A Free DPS/X Extension

                          Juliusz Chroboczek
                     <Juliusz.Chroboczek@ens.fr>


Introduction
************

The two tarballs `dpsx-0.0.0.tar.gz' and `dpsi-0.0.0.tar.gz' contain
very preliminary code for a DPS/X extension for XFree86 based on Peter
Deutsch's `GhostScript' PostScript interpreter.

This code is currently not likely to be useful to anyone.  If you have
an urgent need for a DPS implementation, the `dgs' implementation from
GNUStep might serve your needs better (www.gnustep.org).

In particular, the PostScript interpreter currently does not
time-slice.  This means that most applications will cause your X
server to freeze.  Please do not use this code unless you know how to
deal with a hung X server.

Please keep in mind that the performance and functionality of this
alpha is in no way indicative of what it may become if all goes well.


Known problems
**************

Here are known problems with this alpha, in approximate decreasing
order of severity.  I do not include random crashes that I haven't
been able to trace down.

1. The interpreter doesn't time-slice.  This means that while a
PostScript program is running, the X server is hung, which makes this
code perfectly useless.

2. There is a bug in the `gdevdps' driver which causes halftones
(stipples) and fonts to fail to display sometimes.  I strongly suspect
this to be due to GhostScript clipping us out of existence.

3. Only one context may exist at a time.  If you try to run two DPS
clients simultaneously, or run a client that opens multiple contexts,
you will receive a BadImplementation error.  The inter-context
synchronisation primitives are not implemented.

4. Swapped dispatch and some of the more exotic DPS requests are not
implemented.  You will not be able to run DPS clients from your Sun
machine on a server running on Intel.

5. When a window is resised, the device space origin is not adjusted
to be at a constant position with respect to the window gravity;
instead, it remains at a constant position with respect to the
north-west corner.

6. There are no input devices (you can only use currentfile).  %stdout
is properly implemented.

7. Non-cubic colour cubes are not supported.  You cannot run the
extension in depth 16 (use depth 15 instead).

8. When no GC or drawable is assigned to the context, the context uses
a DPS device that doesn't draw.  I suspect that the Adobe
implementation uses nulldevice in this case; I don't know whether the
difference can be detected by user code.  What is more, our
implementation creates a new DPS device on every invocation of
setXgcdrawablecolor and friends; Adobe probably use a single device,
and hold the X-specific data in the gstate.


Design
******

The DPS/X extension consists of three interdependent pieces of code:
the extension, in directory `dpsx', XFree86 module `dps'; the
PostScript interpreter, in directory `dpsx/dpsi', XFree86 module
`dpsi'; and the rendering library, which currently consists of the
single file `dpsx/dpsrender.c'.  The plan is that ultimately the
rendering library will be split into a separate module which should be
shared by the DPS/X extension and other rendering extensions.

The three components communicate through well-defined interfaces.  The
extension doesn't know about the interpreter; it just uses the
interface defined in `dpsx/dpsi.h' (implemented in
`dpsx/dpsi/dpsgs.c').  The interpreter can use both the data
structures of the extension (`dpsx/dpsext.h') and the rendering
library (`dpsx/dpsrender.h'); however, interpreter dependencies on the
extension should be minimised.  Finally, the rendering library doesn't
know about either the extension or the interpreter, and only uses DIX
interfaces (we hope to have DDX support for the rendering code at some
point).


Licensing issues
****************

Note that the DPS extension consists of code under two distinct
licenses.  All the code written by me comes under the X11 license,
which roughly speaking allows you to do anything with it except
claiming that you wrote it.  Aladdin GhostScript, the PostScript
interpreter that we use, comes under the `Aladdin Free Public License'
(AFPL), a license that forbids commercial redistribution, mandates
dating and commenting all modifications, but, as far as I can see,
doesn't seem to constrain linking in any way.

Peter Deutsch, the author, maintainer, and copyright holder of
GhostScript, has assured me (informally) that this version of
GhostScript will be re-released under the GNU Public License (GPL) in
roughly a year's time.  Whether or not the GPL is suitable for our
needs remains to be seen, but Mr. Deutsch appears to be fairly
sympathetic to licensing suggestions that don't break his business
model, so I am not overly worried about licensing issues.

This heterogeneous licensing means that we must be very careful about
separating our code from GhostScript code.  All code that is suitable
for inclusion in the XFree86 source tree must go in the extension code
or the rendering library, and carry a suitable copyright notice.
Rendering code, in particular, we are likely to want to reuse for
other pieces of XFree86.


Building and installation
*************************

The following instructions assume that you have

  * an XFree86 3.9.16e source tree in $SRC/xc; other version of 3.9
    should work just fine;
  * the GhostScript 5.94 beta sources in $SRC/gs5.94; this is
    available from www.cs.indiana.edu/~ghost (see `testers');
  * the DPS client library sources, dated 3 June 1996, in $SRC/DPS.

1. Patch your XFree86 3.9.* source tree with `xfree86-dps.patch', and
rebuild the core server.  The patch is against 3.9.16e, and is needed
for all versions of XFree86 up to and including 3.9.16f.  It has been
submitted for inclusion in XFree86, and will hopefully no longer be
needed in later versions.

2. Create a directory `$SRC/xc/include/DPS' and copy into it the files
`XDPS.h' and `XDPSproto.h' from `$SRC/DPS/include/DPS'.  Note that
this might or might not be needed in future versions of XFree86 (which
might or might not include the DPS client libraries).

3. Untar the `dpsx' taball in $SRC.  This will create a directory
`$SRC/dpsx' which contains the extension code, and prepare a directory
`$SRC/dpsx/dpsi' for the interpreter.

4. Copy the contents of the `$SRC/gs/src' directory into
`$SRC/dpsx/dpsi'.

5. Untar the `dpsi' tarball in $SRC.  This will add some more files to
`$SRC/dpsx/dpsi'.

6. In the directory `$SRC', apply `gs-dpsi.patch'.  You might need to
edit the files `gconfigv.h', `gconf.h' and `arch.h' for your
installation (in the future, this will be handled automatically).

7. Copy the files `$SRC/gs/lib/gs_*.ps' into
`/usr/X11R6/lib/X11/ghostscript/5.94/lib/' (this can be configured by
editing `$SRC/dpsx/dpsi/Imakefile').  Apply `gs_init.patch' to these
files.

8. Make the DPS/X makefiles.  First, modify the Imakefiles to point to
your XFree86 tree.  Then, in `$SRC/dpsx', type

  xmkmf -a

Hack the Imakefiles until it works.

9. Build the extension modules and install them.  In `$SRC/dpsx', type

  make
  su -c 'make install'

10. To the "Module" section of your `XF86Config' file, add the line

  Load "dps"

and restart your X server.

11. Build the DPS client library.  You might need to patch it with
`DPS.patch' to get it to compile and run.


Further work
************

Most urgent is making proper preemptive scheduling work.  I have
written most of the scheduler, but it doesn't work; in order to try it
out, change line 243 in the file `dpsi/dpsgs.c' from

    gs_enable_scheduling = 0;

to

    gs_enable_scheduling = 1;


We also need to fix the bug in the rendering.  Just run your server in
depth 8, and fill a non-rectangular area with an impure colour; you
will notice that no halftoning is done.

The single-context limitation is tricky.  Multiple `safe' contexts
(contexts that share neither local nor global VM) should not be
difficult -- we just need to split the interpreter initialisation code
into main instance and per-context code.  It should also not be too
difficult to implement shared contexts (`fork'), and in theory the
extension code properly manages contexts that are not X resources.

The problem is with unsafe unshared contexts -- contexts that share
local but not global VM.  According to Mr. Deutsch, the garbage
collector doesn't handle such situations, and there is a
synchronisation problem with synchronisation of oparrays
(pseudo-operators written in PostScript rather than C).

We need to implement the swapping of requests.  It is not difficult,
just tedious.  We also need to rewrite `arch.h' to use X11
configuration mechanisms, and to implement the input devices (so that
`executive' works properly).

Finally, feel free to extend the rendering library with optimised or
accelerated code for some of GhostScript's graphic primitives (see the
bottom of `dpsx/dpsi/gdevdps.c'); the most important are copy_color
and copy_mono, which should not be difficult to accelerate.  Be very
careful, though: GhostScript definitions of geometric figures might be
different from those of X (I am worried, in particular, about lines,
both thin and thick).  And remember -- all rendering code goes into
`dpsx', not `dpsx/dpsi'.


Changes: