[Omniprint-developer] Re: [printing-discuss] Re: [Inkjet-list] IJS Protocol for bitblts

[Pete Z. <pz...@us...>]

To all,
Just for a level set.
There are a number of requirements that need to be met by a driver/renderer
architecture.
One major hot button is the ability to support higher level drivers (such
as PCL5/6) which
with the rendering a full page of raster data is not what you do.
Basically we need the ability to support device fonts among other things.
With the ability
to place text on a page in particular locations (probably speed up printing
50X+ ) there will
be the need to combine bitmaps, paths (regions) and text on the same page.
This brings
on the requirement that we need to be able to add the page location along
with other
information about the bitmap(s) into the implementation we decide upon.
We need to examine HARD the ability to extend support for accelerated
devices into the
architecture.
Yes it is nice if it is lightweight (I'm not sure that extending it will
make it fat either) but it needs to
give us the flexibility to do everything we would need to do to provide
high performance, high
function printing or is there a need for yet another architecture?
I thought we were here consolidate our efforts and cut back on additional
fragmentation of
the components that are currently in place for printing.

Thanks,

Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...


Raph Levien <ra...@le...>@freestandards.org on 11/02/2001 06:51:24 PM

Sent by:  pri...@fr...


To:   Mark Hamzy/Austin/IBM@IBMUS
cc:   Omn...@so...,
      pri...@fr..., ink...@li...
Subject:  [printing-discuss] Re: [Inkjet-list] IJS Protocol for bitblts



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


_______________________________________________
printing-discuss mailing list
pri...@fr...
http://base.freestandards.org/mailman/listinfo/printing-discuss