[lsb-discuss] Questions on standardizing "IJS"

Petrie, Glen glen.petrie at eitc.epson.com
Thu Aug 3 13:55:58 PDT 2006

IJS is not exclusive to or requires GhostScript.   Applications and/or
services can use an IJS client to directly communicate with IJS services.
This is true for resource limit solutions where Ghostscript would be too
large.   So I believe it is wrong to exclusively tie IJS to GhostScript. 


-----Original Message-----
From: lsb-discuss-bounces at lists.freestandards.org
[mailto:lsb-discuss-bounces at lists.freestandards.org] On Behalf Of Fujinaka,
Sent: Thursday, August 03, 2006 10:23 AM
To: lsb-discuss at freestandards.org
Subject: [lsb-discuss] Questions on standardizing "IJS"

IJS is a transfer protocol for raster page images. Currently it's used
as a way to get data out of ghostscript. (Ghostscript is basically a
data converter that takes in Postscript or PDF and outputs various other
formats.) IJS is a standard that developed out of an HP transfer
protocol for printing, and is used by HP, as well as foomatic and other
raster printing implementations.

I'm trying to figure out what "we're adding IJS to the LSB" means
technically. IJS is currently available on major distros because it's
implemented in ghostscript, and I can write a test program to make sure
ghostscript outputs the proper data to an IJS "server". So does that
mean we're requiring ghostscript? IJS uses pipes and stdin/stdout, so
there's no way to query a server for a generic implementation.

I'm thinking opvp is in the same boat.

My only suggestion is that I write a test that exercises ghostscript to
make sure it can handle ijs and opvp output, and would like to hear if
that's a valid solution.


lsb-discuss mailing list
lsb-discuss at lists.freestandards.org

More information about the lsb-discuss mailing list