IJS 0.34
22 Apr 2002

News as of 0.34:

The source files now have official MIT license banners. Thanks to
www.opensource.org for hosting the ur-text of this license. Also
some clarifications on namespace management in the spec.

There is now an IJS website, graciously hosted by linuxprinting.org.
http://www.linuxprinting.org/ijs/

There have been some minor improvements in the makefile.

News as of 0.33:

The buffer size has been increased to 4096. It should probably be
dynamically allocated, though. Minor clarification in BitsPerSample
language in spec (thanks to Jackie Chang for pointing out the
ambiguity).

News as of 0.32:

The xres and yres fields of ph are now floats.

The example server now supports margins. A few small bugs have
been cleaned up as well.

News as of 0.31:

A number of small cleanups in the code. The example client and server
support more querying and enumeration, but not yet margins.

There is a new API for the client to query the negotiated version
number.

The ijs_exec_unix module now sets the SIGPIPE signal to ignore. This
way, if the client abnormally exits, it allows the error to propagate
through the read() or write() call to the pipe, rather than
immediately killing the client.

News as of 0.30:

It now builds as a library. Also, there is basic autoconf support (but
not automake or libtool). It's probably best to link the static
library for now. I'm open to suggestions - I'm open to drinking the
entire pitcher of auto* Kool-Aid, but we probably won't use libtool
in Ghostscript builds.

This release fixes a number of bugs and improves portability. In
particular, server errors should now bubble up to the client, and
the termination logic has been patched according to David Suffield,
who discovered a race condition there. Thanks to David and Russell
for patches.

The spec is now in a reasonable draft. See ijs_spec.sgml and
ijs_spec.pdf. Comments and suggestions are welcome.

The example client and server have _not_ yet been updated to use
the newer features of the ijs spec. Patches are welcome.

News as of 0.29:

I've added a number of things discussed on the mailing list, including
listing and enumerating parameters, as well as a job abstraction.
The client interface has changed a bit - job id's are now present
in most callbacks, colorspace is now presented only as a string, and
there are quite a few more callbacks.

I've started a skeleton of a protocol spec in DocBook.

Note, there's a potential race condition in EXIT noted by David
Suffield. The fix hasn't yet been merged in from his work.

News as of 0.2:

This version integrates set_param and get_param, and has moved the
"page header" processing to use set_param.

Also, there are both Windows (MS VC++) and Unix makefiles. Use
"make -f unix.mak" to build on Unix. Thanks to Russell Lang for
Windows portability work.


Introduction

This is an early snapshot of IJS. I expect the protocols and API's to
evolve somewhat, and things like error handling are still far from
perfect. However, I'm pretty happy that this is going in the right
direction.

I am doing this prerelease so that authors of various packages related
to raster-based printing can start thinking about how to integrate it.
Ideally, all producers of printable raster data should be able to
function as an ijs client, and all consumers should be able to
function as an ijs server. This release is about as functional as
piping pnm's, which is primitive, but the way a lot of drivers still
work.


What is IJS?

IJS is, first and foremost, a protocol for transmission of raster page
images. This snapshot provides a reference implementation of the
protocol, the design of which is still in flux. When the protocol
specification is published, it will be authoritative. Applications
should feel free to link against the library provided in this package,
adapt that code for their own needs, or roll a completely new
implementation.

The protocol is a fairly traditional client-server design. In general,
the client sends one or more page images to the server, along with
various metadata. Communication is through simple "commands", which
are essentially size-prefixed packets. The client sends a command to
the server, then waits for a response command, either ACK or NAK.

The server "speaks" IJS through stdin and stdout. One consequence of
this design decision is that the server can be invoked remotely, for
example through ssh. It's not clear yet how useful this will be, but
at least people can experiment with it.

Currently, all data goes through the stdin and stdout pipes. It is
envisioned that a shared memory transport will also be provided,
transparently. IJS will fall back to pipes if shared memory is not
available for any reason.

I'm not yet convinced that the performance win for shared memory is
significant. I would like to benchmark domain sockets as well, as they
are likely to provide better performance than pipes, and are also
highly desirable for cases where the server runs as a persistent
daemon.

This tarball provides an "IJS library" in the form of ijs, ijs_client,
and ijs_server. It also provides an example client (capable of reading
pnmraw files) and an example server (capable of generating
PostScript). I imagine that the example programs will be useful for
development and testing, but that end-users probably won't find a need
for them.

To try IJS, compile and run "./ijs_client_example -s
./ijs_server_example -pOutputFile=/tmp/tmp.ps foo.ppm". This will
invoke ./ijs_server_example, which will in turn generate a /tmp/tmp.ps
file.

The ijs_client_example takes a -p command line argument for setting
parameters, and a -r argument for setting resolution.  Here is a
typical command line:

./ijs_client_example -s ./ijs_server_example -pOutputFile=/tmp/tmp.ps \
  -r300 in.ppm

The syntax of -p is a sequence of key=value pairs, separated by
commas.  A backslash in the value escapes the next character (allowing
embedded commas in the value). Thus, '-pfoo=bar, quux=a\,b' sets the
key "foo" to the value "bar, and the key "quux" to the value "a,b".


FAQ

What does IJS stand for?

It stands for "raster printer driver architecture." It's spelled
U+30EA U+13DA, to avoid confusion, and to save space in UTF-16
encodings.

Actually, the name derives from HPIJS, which presumably stands for HP
InkJet Server. The name pays homage to HPIJS for the inspiration,
while communicating that it's not specific to HP printers.

Licensing

All source code in this distribution is released under the MIT
License. I want everybody to be able to use this.


More stuff to write:

Actual specification for the protocol (in draft).

Client spawns server, invoker invokes client and server, and
persistent server daemon modes.

Negotation of extensions (goal is interoperability between versions).
(Actually, the PING/PONG protocol as it exists negotiates version
numbers).

TODO:

Shared memory transport.

Should have an alternate mode in which the client is passed the pipe
information, rather than having to spawn the server.

wait() cleanup of invoked server.

Package library up as libijs.a, .so (partially done)