[Omniprint-developer] Re: [Inkjet-list] Re: Taking a step back

[Raph L. <ra...@ca...>]

On Wed, Dec 26, 2001 at 03:16:52PM -0600, Mark Hamzy wrote:
> First, I would like to point out that I am not an IBM spokesperson.  Don't
> take my views as "IBM says you should do this." I am just someone who has
> worked with printer drivers on multiple operating systems for ten years.

Understood.

> Second, this group came together to work on standards for Linux in the area
> of printing.  No one person should control it and everyone should come
> together in agreement for what direction Linux should take.  At this stage,
> proposals should be announced.  It shouldn't be one or another.  We should
> look at existing solutions and if they do not provide what we need, then we
> should take the best ideas from everyone and create something new.

I basically agree here. However, if creating something new means
incompatibility with IJS, or reinventing most of IPP, I'm not sure
that's a good thing.

> IPP has looked at and standardized on many things that relate to printing.
> However, they look at it from the view point of the physical printer
> instead
> of from the software printer driver.  I need to reread all the IPP
> documentation.  However, if each printer driver is an IPP server, can it
> handle that?  Also, it defines the contents of the job as a block of binary
> data.  There are many steps in going from high level calls to the printer
> control language that a printer driver and operating system need.

Yes. I think IPP was designed to handle a number of scenarios, including
physical devices implementing IPP and also print servers of various
flavors. Certainly, the protocol emphasizes very different things than
the IJS work. There is no doubt nontrivial work remaining to "profile"
IPP to be most useful in Linux frameworks. The experience of the CUPS
project will no doubt be extremely useful towards this goal.

> I think that there are many different areas that make up a printer driver.
> It is not just a filter to translate raster bitmap data into printer
> control
> language.  For example, there is another subgroup that is talking about
> printer capabilities.  That should be included in what makes up a printer
> driver.  Also, drivers need to have translatable resources such as form
> names that can be used to build a graphical representation of itself.
> Should there be many different pieces of software to install or protocols
> to
> speak to be able to handle each of these?

Bingo! This is the _real_ question. What is a printer driver?
Presumably, in this context, most printer drivers will be shipped as
RPM packages for some subset of Linux distributions. What should be in
this package? I think we have very strong consensus that _one_ of the
components should be an executable that does the raster to escape code
translation, speaking some kind of IPC protocol with the module that
actually provides the raster data.

I think the questions about how to package the _other_ components of
the printer driver are much more challenging. Perhaps we should try to
pile as much of it into the IPC protocol as possible. I personally
don't think this is the best solution. I believe there are some needed
features that can't be implemented entirely within the IPC protocol
(such as discovering the most appropriate driver for the printer), and
others that would be better implemented using a combination of static
data with IPC protocol assist for the parts that need to dynamic
(capabilities and UI pieces).

> All of the things that are considered as "the Omni group" put into PDC
> should not be viewed as proprietary extensions.  These are some of the
> things
> that I think are necessary as paradigms of common printer driver
> information and setup.  I have tried to design this to be as easy as
> possible for other printer drivers to implement.  There should be as much
> information and routines as possible to be common for the best user
> experience.
> 
> Now that that was said, let me move on to the differences between PDC and
> IJS.

Thanks very much for this. I think it's extremely helpful for
resolving the remaining technical issues.

> Printer Capabilities
> --------------------
> 
> The capabilities subgroup needs to query the printer driver at runtime and
> not though a static file (like a PPD).  Also, I believe that applications
> will want to be able to select between different print paths based on
> the printer's capabilities.

I agree that dynamic printer capability reporting is important. That's
why IJS contains support for enumerating and querying parameters. Some
capabilities, such as duplexing and color support, are defined in the
base IJS spec. Others will need to be defined as extensions.

The latest rev of the spec also imports the PPD namespace for finishing
options (the Finishing: prefix), and also reserves space for other
PPD parameters.

> Translatable Resources
> ----------------------
> 
> A GUI application will need to query the printer driver for its strings as
> well as hints as to how to display the information.

I agree. However, I rather strongly believe that the rasterizer <->
driver IPC connection is the wrong place for it.

For one, as far as I can determine, all of this information can be
provided statically. Even in the case of dynamic capabilities, the
strings and icons to represent these capabilities can be static.

Second, GUI _applications_ should not be talking directly to the
printer driver through an IPC channel. It is clear that another
layer is needed. I don't see the value in having the rasterizer
simply pass this information through.

Third, not having the UI bits in the driver IPC protocol makes life
easier for people packaging up printer drivers. In particular, it's
possible to add strings, icons, etc., without having to mess with
the driver executable itself.

Lastly, coming up with a good standard for UI bits usable for all of
the Linux desktop platforms is a formidable challenge. Perhaps it's
one the Printing Working Group is willing to take on. It's not one
I'm willing to take on with IJS.

> High Level Device Acceleration
> ------------------------------
> 
> While inkjets may not need acceleration, there are other printers that do.
> It is much more efficient to transfer a high level call like drawing a
> rounded box than it is to transfer a bitmap image of that box.  Some
> examples of high level languages are: HP-GL/2, PCL6, and even Postscript.
> Should there be two different code paths for printing to an inkjet printer
> vs printing to a Postscript printer?

This is a good question, and I think the answer is "yes".

That said, the current IJS proposal is in no way limited to raster
data. I added the PageImageFormat parameter explicitly to allow
compressed and higher level formats.

Characterizing the command set of a printer is hard. PCL printers
have notoriously wide variation in the exact PCL dialect implemented.
I don't think the major/minor/micro version number is adequate.

> Device Fonts
> ------------
> 
> One example of reducing data that is sent to the printer driver is to use
> device fonts that are resident in the printer.  To achieve WYSIWYG
> printing,
> an application will have to query the printer driver for its font metrics.

I believe that _accurately_ characterizing the fonts available on
the printer to the client is a big giant can of worms. To get this
right, you have to deal with font metrics, glyph complement, and
encoding.

That said, there's no reason why the IJS wire protocol can't accommodate
this kind of information.

> Constraints
> -----------
> 
> In order to prevent printing duplex on transparencies, the application
> should be told by the printer driver that this will cause a problem.  A
> printer driver writer will know what are the constraints that the device
> places on the coder but there is no way to let an application know.

IJS actually provides a way to address this: the server can make
the Duplex enumeration report no duplexing when transparencies are
selected.

> Job id vs New Instance of Communications
> ----------------------------------------
> 
> I believe that making the client allocate and keep track of job ids causes
> extra complexity without any benefit.  It is easier to start another
> communications session to the printer driver.  This way, the printer driver
> does not have to keep track that id X is in page Y and band Z while id X'
> has just started.  Also, I don't see how the output from multiple
> simultaneous jobs are kept separate.

Hmm. This means that the printer driver must support listening for
multiple connections. In addition, you have to standardize how clients
can discover the various printer drivers with open ports, as well as
nailing down how the driver does access control.

Incidentally, I'm now thinking that "master" and "slave" are more
appropriate names for the IJS roles than "client" and "server". This
terminology is far more intuitive for describing a process which is
both an IJS master and a server for some other protocol, for example
IPP.

Output can be kept separate by specifying finishing options.

> Form Size vs Form Name
> ----------------------
> 
> The form should be selected by the media name.  First, there is a non-exact
> conversion between inches and millimeters.  Second, it is easier to
> remember
> the form name rather than the form size.  For example, a non-US user wants
> to print out on A3 paper.  Is it easier to specify 11.69x16.53 or iso_A3?
> While a table may help, if a new form comes out, then it will be unknown to
> the application.

Possibly. I'm not convinced. In any case, the IJS wire protocol can
easily handle form names as an extension parameter.

> Device Name
> -----------
> 
> Printer drivers that handle many different categories of devices need to be
> told unequivocally what the model name and device name is.  It should not
> have to do a bidirectional call to query the printer name (one reason why
> would be printing to a file).  I believe that this is something that the
> operating system should store and tell the application and printer driver.

This is an architectural question having to do with the way the driver
is used. There's nothing about IJS that forces clients to query the
device name.

> All of the Job Properties
> -------------------------
> 
> I think that the protocol should send every job property to the printer
> driver.  It should also, in the best case, set all of the job properties at
> once.  PDC tries to define a set of common job properties that are the same
> between all drivers.  It is difficult for the user to know that there is a
> set of Ghostscript job properties (-sPAPERSIZE=a4, -r300) and a set of IJS
> job properties (-dIjsDepth=24, -sIjsParam="...").

I'm afraid I simply don't understand this issue.

> Printer Properties
> ------------------
> 
> Printer properties are necessary to know things like 4Mb of memory is
> installed and yellow paper is in tray 2.  The printer driver will send
> different commands to the printer based on what printer properties are set.

I agree that such a thing is desirable. In the PostScript world,
PPD files generally provide this functionality. To the extent that
it should be implemented in the IPC protocol, I can see it implemented
as sub-namespace of IJS parameters.

This kind of thing seems potentially quite tricky to me: how does
the print driver _know_ that tray 2 contains yellow paper? I am
unaware of any printers that have colorimeters in their paper trays.


I think it's possible to come to some closure here. The goal of IJS is
basically to solve the easy problems needed to make inkjet printers
work reasonably well in current Linux/Unix systems. It avoids the
harder problems of parameterized UI bits, non-raster PDL and font
characterization, driver selection for autosensed device ID's, and so
on.

These are important issues, and I truly wish the PWG<2> success in
dealing with them. I believe that IJS is a useful starting point, and
that it would be beneficial for users and driver developers alike to
be able to implement a simple driver based on IJS at first, and add in
PWG<2> enhancements as needed, and as they become standardized. I am
open to suggestions on how to make IJS a suitable basis for this
future work, particularly in terms of providing a robust extension
mechanism.

I personally do not have the time or energy to participate fully in
a standards process for these rather tricky issues. Thus, in terms
of process, I see myself pushing IJS to a 1.0 version in a relatively
short timespan, then handing it over to another group (perhaps the
PWG<2>) for future extensions.

On the other hand, I'm not going to try to stop the PWG<2> from
adopting an incompatible wire protocol if that's what they truly want
to do.

Raph