From: Mark H. <ha...@us...> - 2001-11-05 16:50:28
|
> > 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. I had a number of topics that I wanted to discuss and I thought that they would be ignored if they were all in one note. So, I picked what I thought would be a small subset and it seems that what I feared still happened. What do you think about the other proposal that I made? > 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. This is not a form of data compression at all. This is a form of optimization. The first half of the process knows that there is only drawing on the middle of the bands. It saves the second part of the process from having to look at bands of bitmaps and only find out that there is nothing to do. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ |