News as of 0.35:
11 Feb 2004
The autoconf build system has been moderized and we now use libtool for portable shared library building. Thanks to Roger Leigh for helping with that.
Also a bug with ColorSpace field was corrected, thanks to David Suffield.
News as of 0.34:
22 Apr 2002
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.
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".
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.
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).
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)