Raph Levien wrote:
> 
> Hi folks (and especially Dave Suffield),
> 
>    The latest gdevijs.c snapshot is here:
> 
> http://casper.ghostscript.com/~raph/gdevijs.c

Sorry, I did not get to your gdevijs version till now. I did find on
suggestion after looking at the code. As noted in your spec, the
OutputFD should be sent before DeviceModel. The driver might support
bi-di in the future.

> 
>    You can get usable makefile diffs from gsijs.tar.gz in the same
> directory. Alternatively, you can try the version that Ralph Giles
> sent to gs-devel, which works with ijs in its own toplevel directory
> in the gs build (which is how we're going to package it).
> 
>    This version successfully detects 0.29 and adjusts itself
> accordingly (numeric Duplex parameter, passing through IjsParams as a
> single IJS parameter rather than splitting it in the client). It also
> adds a -DIjsUseOutputFD boolean flag, which selects between OutputFD
> and OutputFile. Set it in order to use the current hpijs server, which
> only works in OutputFD mode.
> 
>    The biggest outstanding issue is margins & printable area. It
> is not trivial to have the full negotiation happen when a
> setpagedevice changes parameters. For example, changing Duplex
> can affect printable area.
> 
>    Dave's client and mine handle these issues quite differently.  Dave
> sets printable area on device open, while mine (based on Russell's)
> does it at output_page time. The latter sets the PageSize correctly in
> response to a setpagedevice, but is less flexible.
> 
>    I suggested a patch of allowing put_params() to close and open the
> device. This has problems. In particular when printing to a file, it
> will close and reopen it, probably wiping out the already-printed
> pages. Thus, I think it's important to handle setpagedevice changes
> without actually closing the device.

Sounds like it needs to be fixed, but I believe this would only be an
issue when setpagedevice was issued on more than the first page.

> 
>    It looks like this will require fairly sophisticated choreography
> to make sure everything happens at the right time. I think the
> following will work:
> 
> 1. Currently ijs's prn_open calls gdev_prn_open(), which mostly does
> two things: gdev_prn_allocate_memory() to allocate the page buffer,
> and gdev_prn_open_printer(), which opens OutputFile if appropriate.
> The former needs to be done very early if IjsUseOutputFD is selected,
> so that the file handle for OutputFile is available at the time the
> server is invoked. However, this is too early for
> gdev_prn_allocate_memory(), because the page area negotiation hasn't
> happened yet. Change the gdev_prn_open() call early in
> gsijs_prn_open() to just do gdev_prn_open_printer().
> 
> 2. After the server is invoked and the DeviceManufacturer,
> DeviceModel, and Optput{FD,File} parameters have been set (ie at the
> very end of gsijs_prn_open()), do a full IJS parameter setting
> operation. This involves setting all params in IjsParams, Duplex, and
> PageArea. Then, get the printable area and margins from the
> printer. Set the GS margins based on this data (using
> gx_device_set_margins()). Finally, complete opening the device with
> a gdev_prn_allocate_memory. This does the initial allocation of the
> page size based on information in the command line and obtained
> from the server.
> 
> Note also that just before the gdev_prn_allocate_memory() would be a
> good place to query the driver's default resolution if it has not been
> set on the command line with -r#.
> 
> 3. In gsijs_put_param(), if the device is open, do the ijs set_param
> call immediately, rather than waiting for the next output_page as is
> done in the current code. After setting these parameters, again get
> the printable area and margins from the ijs server, and set the GS
> device values (using gx_device_set_margins() or friend).
> 
> Note that a change in margins does not require reallocation of the
> page buffer. For reasons that I don't fully understand, Ghostscript
> allocates the page buffer according to the PageSize (== MediaSize),
> and does not take the margins into account. Trimming this seems like
> an interesting optimization, but I'm obviously not going to do
> something like that now.
> 
> Currently, the usual IJS practice is for the page size to flow from
> the client (Ghostscript) to the server (the printer driver). This
> follows accepted PostScript practice. If we changed it so that the
> page size flowed from the server (for example, in response to an IJS
> tray selection), then the IJS negotiation _could_ require reallocation
> of the page buffer. We won't handle that case, as it adds a lot to
> the complexity - you'd need another gdev_prn_maybe_realloc_memory(),
> or somehow defer the one near the end of gdev_prn_put_params() until
> after the IJS negotiation is complete. The same holds for resolution.
> 
> 4. In gsijs_output_page(), remove the parameter negotiation. All IJS
> parameters will have been properly set by now, in the open and
> put_params methods.
> 
> Note, however, that this is too late to set the margins, as GS needs
> them.

I will try your suggestion and let you know.

> 
> Also, I'm seeing an inconsitency in both Russell's code and Dave's:
> the Raster image is set up using dev->width and dev->height, but the
> actual image data is sent according to gdev_prn_print_scan_lines()
> and gx_device_raster(). These do not necessarily coincide.

Which parameters do not match up, the width or height? I found the width
matched ok, but not the height.

The dev_print_scan_line() will be different than the dev->height after
the margins are set.

This means the ijs server does not know exactly how many raster lines
will be sent. In my version of the ijs server, the server reads data
until it receives a IJS_CMD_END_PAGE.

> One final thing: the trick of sending a white row as a zero-size data
> packet is not part of the IJS spec, and I'm not planning to add it.
> White row detection can and should be done in the server. It's
> reasonable to consider some form of data compression for raster page
> images, but I don't consider it pressing. In the meantime, hpijs 1.0.2
> will show performance problems with the current client.

Yes, I would expect a performance hit. 

dave