On Fri, Nov 02, 2001 at 02:51:32PM -0600, Mark Hamzy wrote:
> Hello,
>
> I think that the protocol should be generalized in the case of raster
> data transfer. This will allow other applications and rendering engines
> to talk to printer drivers.
>
> Right now, there are 3 keys that control the format of the
> raster data: NumChan, BitsPerSample, and ColorSpace. I assume that the
> size of the bitmap will be exactly the size of the printable page.
>
> There should be two modes of bitmap transfer. The first mode should be
> a series of banded bitmaps that are in the color space format that the
> printer driver wants. It should be sequential bands of the page. It
> could be either top-to-bottom or bottom-to-top. It can also have an
> optimization of not sending the starting and trailing white-space bands.
>
> The second mode should be a number of one or more bitmaps. Each bitmap
> will have it's size, color depth, and position on the page. I have
> written some code that can take the second mode and translate to the
> first mode. It is freely available in the omni driver.
>
> What do you all think?
My first reaction is no.
Basically, this is a form of data compression. Given that ijs will be
used with a shm transport, it's unclear to me that there will be _any_
performance improvement by implementing compression.
That said, I'm open to the idea of ijs being a somewhat extensible
protocol. If we want to have a parameter for data format, defaulting
to raw uncompressed bitmaps, but settable to the data compression
scheme of your choice, that's fine. The server should always be able
to return an error code if it doesn't support the mode.
Raph "Lightweight" Levien
|
