omniprint-user — User discussion of the Omni driver

Re: [Omniprint-user] espgs-7.05.5: could not load libomni.so

[n8ptt <n8...@n8...>]

You need the path to where the libomni.so in your
LD_LIBRARY_PATH variable (incase you haven't already done that.)
i.e. For example on my Linux box I have:
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/opt/Omni/lib:/usr/src/espgs-7.05.4/Omni;export LD_LIBRARY_PATH

I also had trouble compiling Omni 7.1 so I used Omni 0.6.1 which compiled with no problems.
--
Ken C.

Re: [Omniprint-user] espgs-7.05.5: could not load libomni.so

[Mark H. <ha...@us...>]

There was a bug in espgs that I fixed.  Can you remove espgs and install
the version built on omni's download page?
      rpm -e ghostscript --nodeps
      rpm -i ghostscript-7.05-15omni.i386.rpm

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-user] espgs-7.05.5: could not load libomni.so

[Giulio O. <gi...@po...>]

On Fri, 27 Sep 2002 10:50:57 -0500, "Mark Hamzy" <ha...@us...> wrote:

>What is the URL for ghostscript-7.05.5-0.i386.rpm?  I was unable to find
From http://www.cups.org/software.html
ftp://ftp.easysw.com/pub/ghostscript/ghostscript-7.05.5-0.i386.rpm


>      rpm -qa | grep ghost
>      rpm -qa | grep mni
$ rpm -qa|grep ghost
ghostscript-7.05.5-0
ghostscript-fonts-5.50-3
ghostscript-cups-7.05.5-0
$ rpm -qa|grep mni
OmniBrother-0.7.1omni-4
$

>Can you run
>      OmniDeviceOptions driver Brother_MFC_P2000

pszJobProperties = "(null)"
-sproperties="..." values are are follows (* - default):

dither=
	DITHER_LEVEL
	DITHER_SNAP
	DITHER_DITHER_4x4
	DITHER_DITHER_8x8
	DITHER_STUCKI_DIFFUSION (*)
	DITHER_STUCKI_BIDIFFUSION
	DITHER_MAGIC_SQUARES
	DITHER_ORDERED_SQUARES
	DITHER_FAST_DIFFUSION
	DITHER_STEINBERG_DIFFUSION
	DITHER_SMOOTH_DIFFUSION
	DITHER_HSV_DIFFUSION
	DITHER_HSV_BIDIFFUSION
	DITHER_CMYK_DIFFUSION
	DITHER_VOID_CLUSTER
	DITHER_JANIS_STUCKI
	DITHER_ESTUCKI_DIFFUSION
form=
	FORM_3_X_5_CARD
	iso_a4_2100.00x2970.00mm
	iso_a5_1480.00x2100.00mm
	iso_b5_1760.00x2500.00mm
	FORM_C10_ENVELOPE
	na_c5_6.38x9.02in
	FORM_DL_ENVELOPE
	na_executive_7.25x10.50in
	na_legal_8.50x14.00in
	na_letter_8.50x11.00in (*)
	na_monarch_3.88x7.50in
media=
	MEDIA_PLAIN (*)
orientation=
	portrait (*)
printmode=
	PRINT_MODE_1_ANY (*)
	PRINT_MODE_24_RGB
	PRINT_MODE_8_RGB
resolution=
	150x150
	300x300 (*)
tray=
	TRAY_MULTI_TRAY (*)
HardwareScaling=
	0 ... n (0)


Thanks

-- 
gi...@po...

[Omniprint-user] espgs-7.05.5: could not load libomni.so

[Giulio O. <gi...@po...>]

RedHat7.3
Ghostscript in the espgs-7.05.5 incarnation (ghostscript-7.05.5-0.i386.rpm
from web site)
OmniBrother-0.7.1omni-4.i386.rpm (from sourceforge omni site)

# rpm -V ghostscript
# rpm -V OmniBrother
#

$ gs -h |grep omni
   xes cups ijs omni stp nullpage
$

gs -q -dSAFER -dBATCH -dNOPAUSE -sOutputFile=myfile.raw -sDEVICE=omni
-sDeviceName=Brother_MFC_P2000 -smonodither=GSMONO -sproperties="
form=iso_a4_2100.00x2970.00mm media=MEDIA_PLAIN resolution=300x300
printmode=PRINT_MODE_1_ANY tray=TRAY_MULTI_TRAY
dither=DITHER_STUCKI_DIFFUSION orientation=portrait HardwareScaling=1"

gs says

<<<<<<<<<<<<<<<<<<<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>
 
Error: Could not load libomni.so
 
<<<<<<<<<<<<<<<<<<<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>
 
Error: Could not load libomni.so


strace -f ...
...
...
[pid   878] open("/opt/Omni/lib/libomni.so", O_RDONLY) = 5
[pid   878]
read(5,"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260`\5"...,
 1024) = 1024
[pid   878] fstat64(5, {st_mode=S_IFREG|0755, st_size=1383348, ...}) = 0
[pid   878] old_mmap(NULL, 1031936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0)
= 0x40434000
[pid   878] mprotect(0x404fa000, 220928, PROT_NONE) = 0
[pid   878] old_mmap(0x404fa000, 221184, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0xc5000) = 0x404fa000
[pid   878] close(5)                    = 0
[pid   878] munmap(0x4042e000, 22777)   = 0
[pid   878] munmap(0x40434000, 1031936) = 0
[pid   878] write(2, "<<<<<<<<<<<<<<<<<<<<<< ERROR >>>"...,
54<<<<<<<<<<<<<<<<<<
<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>
 
) = 54
[pid   878] write(2, "Error: Could not load libomni.so"..., 33Error: Could
not load libomni.so) = 33
[pid   878] write(2, "\n<<<<<<<<<<<<<<<<<<<<<< ERROR >>"..., 55
...


I tried downloading omni source, but now I'm in dependency hell: it wants
xml-devel which wants something other, then automake is angry with many
messages, m4 says there's no configure.in, .... hopeless :)
...
config.status: creating JobDialog/Makefile
config.status: creating tools/Makefile
config.status: creating config.h
config.status: executing default-1 commands
****************************Stage*1*Make****************************
make SUBDIRS=hppcl3 . XMLParser
Makefile:550: *** missing separator.  Stop.
Error: Build break!
+ exit 0


-- 
gi...@po...

[Omniprint-user] LC-20 problem

[Dusan G. <du...@hq...>]

Hi, I have got a Star LC-20 printer and I installed your omni driver from
package OmniStar-0.7.1omni-4.i386.rpm.

Then I wanted to configure my lpd to use omni driver for my printer so I did
used printconf-tui. But while configuring driver this error appears:

not well-formed (invalid token) at line 33, column 35, byte 849 at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/XML/Parser.pm line 185

I'm running Redhat 7.2 with some packages from 7.3 (perl, Gimp..)

Can anyone help me?
Thanx

					dusky

Re: [Omniprint-user] Trying to get Omni library to work

[Mark H. <ha...@us...>]

Hey Geoff,

It is missing the glib includes and libs.  These are put in the makefiles.
You run programs xml-config or xml2-config with options --cflags or --libs.
You also run glib-config with --cflags or --libs.  The --cflags is for the
compiling phase and the --libs is for the linking phase.
Since gomni.c was compiled into ghostscript, I thought that these changes
were made already.

It might be easier to start from scratch by downloading a version of the
ghostscript source and add the corresponding patch from the omni's
Ghostscript directory.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-user] Trying to get Omni library to work

[Geoff C. <geo...@bj...>]

On Tue, 23 Jul 2002 06:38, you wrote:
> Hi Geoff,
>
> Is your gomni.c the latest version?  A couple of lines before the code that
> you pointed out should have a call to g_module_error ().
> If not, use this version:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/omniprint/Omni/Gh
>ostscript/new_src/gomni.c?rev=HEAD&content-type=text/plain
>

  No, my gomni.c isn't the latest version, just the one that comes out of the 
debian source package. It's labelled version 6.53 (for the ghostscript 
package). Anyway, the version I have got doesn't have a call to 
g_module_error(). I downloaded the above url, copied it over my gomni.c, but 
it has two #includes that my system can't supply:

#include <glib.h>
#include <gmodule.h>

  Any chance you could tell me what is supposed to supply them? I did a 
google search on gmodule.h, but I didn't see anything that helped me.
The other question I had was, other there are files under the ghostscript 
package that are likely to need modifying? If so, should I be looking for a 
patch for the ghostscript source, rather than replacing just the gomni.c file?

> That should say why the g_module_open is failing.
>
> Mark

Thanks for the help, I'm just not all that good a programmer.

  Geoff Crompton

Re: [Omniprint-user] Trying to get Omni library to work

[Mark H. <ha...@us...>]

Hi Geoff,

Is your gomni.c the latest version?  A couple of lines before the code that
you pointed out should have a call to g_module_error ().
If not, use this version:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/omniprint/Omni/Ghostscript/new_src/gomni.c?rev=HEAD&content-type=text/plain

That should say why the g_module_open is failing.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-user] Trying to get Omni library to work

[Geoff C. <geo...@bj...>]

  I have recompiled ghostscript, changing fDebugOutput to 1. The output I saw 
was exactly the same as before. Ie, there were no extra diagnostic messages 
displayed to indicate some problems.
  
  Are there any other suggestions?
I had a look into the code. It seems that the error message is being 
generated in the gomni.c, line 650,  after checking something:

 if (!pDev->vhOmni)
 {
         // Failure!
         fprintf (stderr, "\n<<<<<<<<<<<<<<<<<<<<<< ERROR 
>>>>>>>>>>>>>>>>>>>>>>>\n\n");
         fprintf (stderr, "Error: Could not load libomni.so!\n\n");

  However, I have no idea why pDev->vhOmni is NULL, and I don't have the 
skills to track it down.

  Thanks for anyhelp

  Geoff

On Sat, 13 Jul 2002 00:36, Mark Hamzy wrote:
> Hi Geoff,
>
> How do you enable omni into ghostscript?  Did you recompile ghostscript
> with our patch?
> If so, can you check out Ghostscript/new_src/gomni.c, change fDebugOutput
> to 1 and recompile and retest.
> That should give more debug output as to what is wrong.
>
> As far as your test program, libomni.so is C++ code so the calling
> application should link with stdc++.  Also,
> while I don't know if this causes problems or not, all of our loading code
> uses glib's g_module_open instead of dlopen.
>
> Also, as a test you can run OmniDeviceOptions libKyocera_FS_1600_.so and
> see if that works.
>
> Mark
>
> Take a look at the Linux Omni Printer Driver Framework at
> http://www.ibm.com/linux/ltc/projects/omni/

Re: [Omniprint-user] Trying to get Omni library to work

[Geoff C. <geo...@bj...>]

On Sat, 13 Jul 2002 00:36, Mark Hamzy wrote:
> Hi Geoff,
>
> How do you enable omni into ghostscript?  Did you recompile ghostscript
> with our patch?

  I am just using the debian package for ghostscript. A 'gs -h' shows omni 
listed as an available device.

> If so, can you check out Ghostscript/new_src/gomni.c, change fDebugOutput
> to 1 and recompile and retest.
> That should give more debug output as to what is wrong.
>
> As far as your test program, libomni.so is C++ code so the calling
> application should link with stdc++.  Also,
> while I don't know if this causes problems or not, all of our loading code
> uses glib's g_module_open instead of dlopen.

  I had vague thoughts that might be a problem with my dlopen code, but I'm 
not really a programmer, so I wasn't sure. Ah yes. I changed the dlopen 
program, and compiled with g++, and it opened the libomni library without any 
problems.

>
> Also, as a test you can run OmniDeviceOptions libKyocera_FS_1600_.so and
> see if that works.
>

  Yep, that worked.

  I will have to get the debian source package for ghostscript, and try out 
that debugging option that you suggested. I'll let you know how that goes, 
when I get around to it :(

  Cheers, 
  Thanks for the suggestions
   Geoff Crompton

Re: [Omniprint-user] Trying to get Omni library to work

[Mark H. <ha...@us...>]

Hi Geoff,

How do you enable omni into ghostscript?  Did you recompile ghostscript
with our patch?
If so, can you check out Ghostscript/new_src/gomni.c, change fDebugOutput
to 1 and recompile and retest.
That should give more debug output as to what is wrong.

As far as your test program, libomni.so is C++ code so the calling
application should link with stdc++.  Also,
while I don't know if this causes problems or not, all of our loading code
uses glib's g_module_open instead of dlopen.

Also, as a test you can run OmniDeviceOptions libKyocera_FS_1600_.so and
see if that works.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] Trying to get Omni library to work

[Geoff C. <geo...@bj...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  Hi, I'm having problems getting the Omni library to work with GhostScript.
I'm running Debian (testing), and have got the Omni-0.7.0 tar ball.
I have gs already installed (6.53).
  The building all goes well (I'm only building Kyocera, and the 1600+ 
driver), and I have added /opt/Omni/lib to my /etc/ld.so.conf and re run 
ldconfig. However when gs runs it reports:

~$ gs -sDEVICE=omni
GNU Ghostscript 6.53 (2002-02-13)
Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.

<<<<<<<<<<<<<<<<<<<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>

Error: Could not load libomni.so!

I have also written very short c program to simply do a dlopen("libomni.so"). 
This fail, reporting:

$ ./a.out 
/opt/Omni/lib/libomni.so: undefined symbol: cerr

Can anyone help me out with what is going wrong? I have attached the short c 
program that I wrote to do the dlopen().
(BTW, I'm not subscribed to the mailing list).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9LkwGx8QbdaYmRS8RAsq0AJ9jnltFBZMSKEwjeXTxJ8V3w8Gu6gCgg6EG
oW8BEZD2cKk3s+kKO3DI+Dw=
=I98P
-----END PGP SIGNATURE-----

Re: [Omniprint-user] New driver for thermal printer

[Mark H. <ha...@us...>]

The omni driver provides many different ways of adding a device.
The simplist is to take an existing device and copy the XML file into a new
device name and add a line to "Device List".
From there, you can modify the forms that it has by creating a new form XML
file or tray, or resolution, or ...
If the language is different, then you create new blitter and instance cpp
files.

If you want to support the device in a proprietary manner, then you can
still have open source forms, trays, medias, etc, but have a binary object
for the bitmap to printer language (or blitter) section.  Take a look at
"Pluggable Blitter" document.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/


                                                                                                                                        
                      mi...@mi...                                                                                                      
                      Sent by:                               To:       omn...@li...                             
                      omn...@li...ur        cc:                                                                        
                      ceforge.net                            Subject:  [Omniprint-user] New driver for thermal printer                  
                                                                                                                                        
                                                                                                                                        
                      05/15/2002 11:44 AM                                                                                               
                                                                                                                                        
                                                                                                                                        



Hello

I have been tasked with writing a new driver for a proprietary thermal
printer.
The printer is based on the Epson TM-T88P.

I would like to use the IBM Omni driver as the model for this new driver,
what
is the best way to proceed?

Sincerely,

Jeremiah


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Omniprint-user mailing list
Omn...@li...
https://lists.sourceforge.net/lists/listinfo/omniprint-user

[Omniprint-user] New driver for thermal printer

[<mi...@mi...>]

Hello

I have been tasked with writing a new driver for a proprietary thermal printer. 
The printer is based on the Epson TM-T88P.  

I would like to use the IBM Omni driver as the model for this new driver, what 
is the best way to proceed?

Sincerely,

Jeremiah   

[Omniprint-user] Omni version 0.6.1 has been released

[Mark H. <ha...@us...>]

Download it at http://sourceforge.net/project/showfiles.php?group_id=18713

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/

[Omniprint-user] new compilation error...

[Louco.com internet. <pr...@ig...>]

Now, I've got this errors on compilation (cvs-version 04/13).

On the attach.

--------------------------------------------------------------------------
   -o)(o-   Sem noção joselito, sem noção!
 -./\\//\.- Slackware 8 vs. Cubo Linux Beta 123
  _\_VV_/_  Por que usar as janelas se você pode usar a Porta?
--------------------------------------------------------------------------

Re: [Omniprint-user] problem with compilation...

[Louco.com internet. <pr...@ig...>]

Why dont you make a "configure" script? Its can make problems like this 
disapear for all the times. Hehehe.

--------------------------------------------------------------------------
   -o)(o-   Sem noção joselito, sem noção!
 -./\\//\.- Slackware 8 vs. Cubo Linux Beta 123
  _\_VV_/_  Por que usar as janelas se você pode usar a Porta?
--------------------------------------------------------------------------

[Omniprint-user] problem with compilation...

[Louco.com internet. <pr...@ig...>]

When I try to compile (do make) omni i've get errors on not founding the xml 
includes... Making some changes in XMLparser/makefile and in some files of 
this directory, finaly the error come out.

But after of some time of compilation i've got this error:

make[1]: Entrando no diretório `/usr/src/gs/ghostscript-6.53/Omni/XMLParser'
c++ -Wall -fPIC -O3 -fPIC -rdynamic  -DRETAIL=1  -I .. 
-I/usr/local/include/glib-1.2 -I/usr/local/lib/glib/include -c 
OmniDomParser.cpp
OmniDomParser.cpp: In function `char * bundleStringData(xmlNode *)':
OmniDomParser.cpp:335: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:336: warning: control reaches end of non-void function 
`bundleStringData(xmlNode *)'
OmniDomParser.cpp: In function `int bundleIntegerData(xmlNode *)':
OmniDomParser.cpp:341: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool 
OmniDomParser::processDeviceOrientations(xmlNode *)':
OmniDomParser.cpp:763: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:774: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool 
OmniDomParser::processDeviceCommands(xmlNode *)':
OmniDomParser.cpp:1017: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:1037: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool 
OmniDomParser::processDeviceResolutions(xmlNode *)':
OmniDomParser.cpp:1186: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:1200: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool 
OmniDomParser::processDevicePrintModes(xmlNode *)':OmniDomParser.cpp:1616: 
`struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:1628: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDeviceTrays(xmlNode 
*)':
OmniDomParser.cpp:1918: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:1933: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDeviceForms(xmlNode 
*)':
OmniDomParser.cpp:2289: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:2304: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:2370: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDeviceMedias(xmlNode 
*)':
OmniDomParser.cpp:2716: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:2730: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool 
OmniDomParser::processDeviceConnections(xmlNode *)':
OmniDomParser.cpp:3080: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:3088: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDeviceGammas(xmlNode 
*)':
OmniDomParser.cpp:3171: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:3183: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDeviceDatas(xmlNode 
*)':
OmniDomParser.cpp:3535: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::preprocessDriver(xmlNode 
*)':
OmniDomParser.cpp:3855: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `bool OmniDomParser::processDriver(xmlNode *)':
OmniDomParser.cpp:4098: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:4387: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp: In method `void OmniDomParser::processDOMNode(xmlNode *)':
OmniDomParser.cpp:5340: `struct _xmlNode' has no member named `childs'
OmniDomParser.cpp:5373: `struct _xmlNode' has no member named `childs'
make[1]: ** [OmniDomParser.o] Erro 1
make[1]: Saindo do diretório `/usr/src/gs/ghostscript-6.53/Omni/XMLParser'
make: ** [XMLParser.make] Erro 2

I dont now what to do... can you help me??

I'm tring to use omni for support my epson lx300 on ghostscript.
My system is an slack8.

--------------------------------------------------------------------------
   -o)(o-   Sem noção joselito, sem noção!
 -./\\//\.- Slackware 8 vs. Cubo Linux Beta 123
  _\_VV_/_  Por que usar as janelas se você pode usar a Porta?
--------------------------------------------------------------------------

[Omniprint-user] Re: [Inkjet-list] Thoughts on Drivers, Early and Late Binding, When to Do Conversion

[Patrick P. <pap...@as...>]

> From rl...@ti... Thu Jan 24 04:24:40 2002
> Date: Thu, 24 Jan 2002 07:18:55 -0500
> From: Robert L Krawitz <rl...@al...>
> To: pap...@as...
> CC: pri...@fr..., ink...@li...,
>    omn...@li...,
>    omn...@li..., pri...@fr...,
>    pz...@us...
> Subject: Re: [Inkjet-list] Thoughts on Drivers, Early and Late Binding, When to Do Conversion
>
>    Date: Tue, 22 Jan 2002 15:56:48 -0800 (PST)
>    From: Patrick Powell <pap...@as...>
>
>    a) Bind the 'graphical image size' as early as possible.
>       That is, generate your print jobs with intimate knowledge
>       of the graphical image size.
>
>      This means:
>        'select page size and printable area first' 
>
>    b) Do paper or media selection as LATE as possible.
>      That is, pass requests for paper type, paper size
>      (actually, you may need to do this together with a)),
>      duplex, finishing, etc., as late as possible.
>
>       This means:
> 	'do not embed these options in the output from a)'
>
> The printable area may depend upon these parameters.  For example, the
> printable area when printing on an 8.5x11 piece of roll-fed paper is
> typically different from that on sheetfed paper.
>
> -- 
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
>
> Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lp...@uu...
> Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net
>
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>

Right.  No question about it.  I said that this is a preference,
and not an absolute requirement.  If you are in need of 'absolute printable
area and the real location on the page at print time'  then you will have
to borrow the IPP method:  send a job to the printer with a 'request',
get back a set of 'configuration values' for the job, which will tell you
what various things will be done.

Of course, for most purposes (99.99995%) this will be overkill...  But it
is still important.

The other method is to brutally create a special 'printer' that simulates
the actions of the 'print on roll paper' and have it fake the parameters.

This is once again an example where EARLY BINDING is necessary,   but you will
need to bind all of the stuff at job submission time.

Patrick Powell                 Astart Technologies,
pap...@as...            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.lprng.com)

[Omniprint-user] Re: [Inkjet-list] Thoughts on Drivers, Early and Late Binding, When to Do Conversion

[Robert L K. <rl...@al...>]

   Date: Tue, 22 Jan 2002 15:56:48 -0800 (PST)
   From: Patrick Powell <pap...@as...>

   a) Bind the 'graphical image size' as early as possible.
      That is, generate your print jobs with intimate knowledge
      of the graphical image size.

     This means:
       'select page size and printable area first' 

   b) Do paper or media selection as LATE as possible.
     That is, pass requests for paper type, paper size
     (actually, you may need to do this together with a)),
     duplex, finishing, etc., as late as possible.

      This means:
	'do not embed these options in the output from a)'

The printable area may depend upon these parameters.  For example, the
printable area when printing on an 8.5x11 piece of roll-fed paper is
typically different from that on sheetfed paper.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-user] Thoughts on Drivers, Early and Late Binding, When to Do Conversion

[Patrick P. <pap...@as...>]

Due to time problems,  I have not been an active submitter to this
list.  I would like to make some comments on some topics that have
been under discussions.

WHAT IS A DRIVER?

The problem here is that the term 'driver' is a semantically loaded
word.  In the Microsoft Windows environment,  printing is done VIA
a 'printer device',  which just happens to look very similar from
an IO standpoint to a real device.  You can send data to the device
(well, anybody with any sanity will use the graphics library:-),
and there are a well supported set of IO operations API's defined
to support them as well.

But you are really doing IO operations that magically get translated
into stuff in a file that is then sent to a printer.

To make things work right,  you need to get device parameters and
discover the magic things that need to be done in what order.  Most
of the work of the API library support is making this job easier
for the user.

One way to 'simplify' UNIX printing is to clone this type of
operation:  come up with a standard set of 'drawing operations'
and you are finished.

This is REALLY REALLY appealing.  In fact,  several systems have
been designed and papers written on how to do this in the UNIX
environment.  In fact,  some folks tried to do this VIA the X
environment,  by setting up a virtual X device that was such a
printer.  So....  all we need to do is extend the X Server so that
it has:

  a)  Open a print job
  b)  Set the 'visual characteristics' of the current 'page image'
  c)  Get the 'visual characteristics' of the current 'page image'
  d)  Throw crud on the screen^H^H^H^H^H 'page image'
  e)  Finish/terminate the current page
  f)  Finish/terminate the current 'print job'
  g)  Commit the print job to the 'printer'

The 'driver API' can then simply be the set of X library functions
that do low level graphics operations,  extended by the various
printing stuff.


EARLY BINDING and LATE BINDING

The big headache in printing is trying to decide how and when
to bind your printing job image to the printer.

Early binding:
  At the time of 'print job submission' you do absolutely everything
to nail the job/output/format/whatever to the output device.
You can,  given knowlege of the communications channel to the device,
do various things in real time,  such as request paper to be loaded,
operator to put covers into printer, etc.


  Disadvantages:
   This requires that as much information as possible,  including
   all raster conversions, data formats, communication channel
   operations, etc.,  be known to the 'early binding' process.
  
  Advantages:
   The print job generator can take advantage of special device options
   that are available to her.

Late Binding:
  As little as possible is done to make the print job depend on the
output device.  In fact,  some sort of 'generic print job' format
is used,  and then the last stage in the printing process will
convert this to the output format and/or commands compatible
with a specific printer.

  Disadvantages:
   You need a special 'generic language' that does not depend
   on the printer,  and conventions about 'format requests'
   and 'print job options' to be passed as part of the print
   job.
  
  Advantages:
   You do not need to have intimate knowledge of the printer,
  just of the &*(()*& 'generic language'.

What is Best?

That depends on what you are doing.  HOWEVER...  I like the
following:

a) Bind the 'graphical image size' as early as possible.
   That is, generate your print jobs with intimate knowledge
   of the graphical image size.

  This means:
    'select page size and printable area first' 

b) Do paper or media selection as LATE as possible.
  That is, pass requests for paper type, paper size
  (actually, you may need to do this together with a)),
  duplex, finishing, etc., as late as possible.

   This means:
     'do not embed these options in the output from a)'

c) Do rasterization, font selection, etc. etc., at the most
   appropriate point.  This can be done AFTER a) or AFTER b)

Initial Submission Does Raster 
   NEED: page size (generate image + rasterize)
      OUTPUT:  'raster for device'
       ->  Late binding media selection stuff
          -> device
       Note - this makes a lot of sense for devices that
   do not do rasterization or whose basic rasterization
   stuff is terrible.

      Example:
        Images -> raster for some printers
            (Gimp folks do a great job here)


Initial Submission Does Generic  
   NEED: page size (generate image in 'generic format')
      OUTPUT:  'generic format'
       ->  Late binding media selection stuff
          -> device
              -> device does rasterization

     Example:
       text -> PostScript
         (Font definiitions added to the job)
           ->  Late binding media selection stuff
              -> device
                 Postscript interpreter in device
                 does rasterization

But really,  we want the ability to do both:

Initial Submission Does Generic +
   Middle Does Raster
                
   NEED: page size (generate image in 'generic format')
      OUTPUT:  'generic format'
       -> Raster converter and fixer upper
          ->  Late binding media selection stuff
             -> device

This is the model that is used for most GhostScript
based converters - you generate the job in PostScript,
fling it at a conversion system^H^H^H^H^H^H print spooler,
the conversion system does the rasterization based on the
output device it will choose to print the job on,
and then send it to the device.


I think that there is a need to support all three of these
models in whatever folks propose.
Patrick Powell                 Astart Technologies,
pap...@as...            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.lprng.com)

[Omniprint-user] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Thursday 10 January 2002 03:27 pm, Pete Zannucci wrote:
> ...
> The point here was to explain that you don't need the caching
> mechanisms in place for having non-current information about the
> printer at a particular time.  Only when the printer can't return
> real-time information (in the middle of processing data) will the
> query information of the device need to be pulled from a cache.
> At that point in time, everything will work the same between a
> multi-user printer and a single user.  There isn't any difference
> except to make sure both cases can be handled in the same fashion.

Without caching you are going to run very, very slowly with
multiple users/processes asking for printer status.  Also, state
information queries can be very time consuming on some printers,
due to the interface, amount of information, or protocol(s) being
used.

Also, many printers offer a "continuous update" mode that a
driver can use to get status/configuration updates *when they
happen*, instead of polling all the time.  This further improves
performance because the monitor only updates the status/config
info as needed, rather than rebuilding that data at regular
intervals, on-demand, or both.

*My* point is that you *do* need a caching mechanism in place;
it may not be used all the time, but it *will* be used.

> I would also state with most printers, you still will only have one
> process at a time accessing them so the item about multiple windows
> should go away. The spool system should be the process of choice
> because with most printers, you can't print to them from multiple

Repeat after me: "Applications do not directly communicate with the
printer device."  Applications (and even the spooler, if you make the
device monitor a separate daemon) communicate with an intermediary
which manages access to the printer device.

In the normal course of events, you may have several (or thousands)
of processes/users requesting the current status of the printer.
This is one of the reasons that a certain very popular Windows
file/printer sharing program (SAMBA) has to cache all of the printer
and job status information to keep up.

Under UNIX/Linux today, few applications actually know enough to
communicate with the printing system to keep track of the current
printer and job information.  In the future, thanks to GNOME and KDE,
many more applications will be "printer-aware" and will be asking
for things like "what is your current status", or "what is the status
of the job I just printed for this user?".

What does this mean?  Well, for one thing we need to cache the state
information.  We also need to integrate state/configuration reporting
with the printing system, so that applications have a single interface
for printing.  This interface will likely be abstracted to support
multiple printing environments (e.g. KDEprint).

> ...
> This was to bring up a point that a separate process could track that
> data to and from the printer.  The management of that data via that
> process would be beneficial because the associated code that is run
> by that process will know the specifics of the datastream and when it
> can query, abort, send additional info. etc. to the printer.
>
> If you have two printers that the protocol is the same, why re-write
> the code that manages the protocol (bidirectional send, receive,
> abort, restart, etc) code into each driver.  The individual protocol
> code that can be shared on a grouping of printers therefore written
> once, tested once, and plugged in along with its sister printer
> driver.

Your first paragraph conflicts with the second.  You can't write a
general-purpose device interface (say, for IEEE-1284 packet mode)
that can handle aborting a job cleanly by "managing the print data",
unless you have the driver tell the device interface what each piece
of data is.  You might be able to define a subset of devices for
which this would work, but doing it in a general way is very, very
difficult.

In CUPS we use pipes between the driver/filter processes and the
backend (device interface) that communicates with the printer.
CUPS 1.2 adds the "backchannel" pipe that allows bidirectional
comm with the printer through the backend which handles the
device-specific communication stuff.  Both the driver/filter
and backend processes can communicate information back to
the scheduler which is provided to the client(s) that need
it.  If a job is cancelled, the printer driver is responsible
for sending any required "cleanup" data to the backend - this
will make sure that the current page is ejected, the printer
is reset, and so forth.

The point of the last paragraph is to show that it *is* possible
to support device interface/backend software for multiple devices,
or to substitute device interfaces, without having to change the
printer driver or add special handling code to the device interface.

> ...
> From a printing application perspective, I would not want to have to
> code IPP into it.  I would expect the appropriate subsystems to
> handle the management of this for me.  I would expect nice query,
> set, page, job, and drawing commands to be all I would worry about. 
> The system APIs I utilize should do all the management and how we
> talk to the printer from a system perspective should be nebulous.
> printer is.

I believe that a lot of this is already available from the KDE and
GNOME folks (for the general interface), and is provided specifically
in the CUPS API for CUPS.

> We are still grappling with the issues of renderer and driver
> interface in these groups.  The licensing issue is very real and that
> is why it is a hot button for a number of people.  Vendors would
> rather not have to open source their intellectual property because
> they have to run their drivers in the same process as open source
> licensed code.

Lets be honest - Ghostscript is the stumbling block, as most print
files in UNIX are PostScript.  Everything else is available in many
forms and under many licenses, but Ghostscript is only available as
GPL or AFPL.

Putting a generic raster interface into Ghostscript is not new -
we've been doing it since 1993 - and it works very well.  The
generic interface bypasses those licensing issues nicely.

> IPP is typical for use with communications between systems and
> systems/printers.  This does not address the fact of how an
> application talks to a driver or finds out information about the
> capabilities of the subsystem and driver combination (fonts and other
> things that can be lumped under system).  What I am pointing out is
> additional things that should be in place.

Actually, IPP *does* address those things in several of the more
recent extension proposals in the PWG.  I *strongly* urge you to
look at the PWG web site (http://www.pwg.org/ipp/) or talk with
some of the people in IBM doing work on IPP...

> What I was attempting to point out is that we need to define
> interfaces for standardization and to be able to allow extension.  We
> shouldn't be tied to the past with things such as PPDs or munging

PPDs are still the ONLY common printer description format that is
available.  They also have the advantage of limiting the amount of
special-case stuff you need (XML for Printer Driver ABC, PPD for
PostScript Printer XYZ, etc.) just to support printing.

> them so that we now become incompatible with applications that might
> not know how to parse the data.  An API needs to be defined with data

If you do it right, any compliant PPD parser will ignore the extra
attributes/comments.

> structures, possibly XML, to isolate the application from having to
> do the tedious work such as parsing information that may need to be
> changed in the future. Methods and managing should be crisply defined
> for the application via an API for capabilities support.

The PWG (again) has a working group developing a common XML format for
printer description information, which may be adopted widely enough
to be useful.

That said, any successful replacement for PPD will have to support
a superset of what PPD does, and allow for automated conversion from
PPD to XML (and perhaps back to PPD)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

[Omniprint-user] Re: Taking a step back

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

      > ...
      > This all really depends on what set of problems you want to solve.
      > If you look at several scenarios it will better define the
components
      > that are needed and the way you could handle most of the scenarios.
      > We need to handle:
      > -  Device configuration information dynamic from the printer
      > -  Status information returned from the printer
      > -  Local configured printer
      > -  Network configured printer

   >   I would argue that we do not want to distinguish between a local
   >   and network printer.  All printers should be treated the same, and
   >   an application that communicates with a local print queue should be
   >   able to access a network print queue the same way.  Again, I'm
   >   harping on network transparency!
   >
   > I agree with this.  I would further argue that if the behavior of the
   > printer differs depending upon whether it's locally connected in a
   > single user environment vs. remotely connected, or in a multiuser
   > environment, that the system violates the "principle of least
   > surprise".  Unless it's absolutely impossible to provide identical
   > semantics (which I don't believe it is here), distinguishing these two
   > cases will simply lead to user confusion.

The above was an example of problems to solve, not all the problems or that
each of the problems should be handled in different ways.  If you don't
define what we are trying to solve we will never put code in place to
handle
those conditions.  This wasn't meant to differentiate the items.

      > 1. Local printer configuration and capabilities
      >
      >   The local printing (single user) scenario is fairly easily
   handled
      >   when utilizing IPC mechanisms.  Latency and information about the
      >   printer go away in this scenario because you don't have to worry
      >   about the 100 user scenarios.

   >    I would argue that even a single user will have multiple windows,
   >    etc. open that want to access a printer at the same time,
   >    especially to check the current status.
   >
>   While it's true that the latency issue largely goes away in this case
>   Epson printers do, and the driver deals with this), it's really not
>   clear to me why we want to special case this.

The point here was to explain that you don't need the caching mechanisms
in place for having non-current information about the printer at a
particular
time.  Only when the printer can't return real-time information (in the
middle
of processing data) will the query information of the device need to be
pulled
from a cache.  At that point in time, everything will work the same between
a
multi-user printer and a single user.  There isn't any difference except to
make sure both cases can be handled in the same fashion.

I would also state with most printers, you still will only have one process
at
a time accessing them so the item about multiple windows should go away.
The
spool system should be the process of choice because with most printers,
you
can't print to them from multiple apps.  The application will not have
access to the output device so spooling is the only real option here to
return the application to the user when multiple apps are printing.

      >    Local printer status information
      >
      >   When doing local printing, the status should be immediate and any
      >   device specific protocol converter (daemon) of the data be manage
      >   the flow to and from the printer to always maintain an accurate
      >   account of the status of the job and printer state.
   >
   >    The device daemon should *not* try to understand the data to/from
   the
   >    printer, nor should we expect it to track printer or job status.
   >    Specialization leads to bloat and all sorts of implementation
   problems.
   >
   > Depends upon exactly what the device daemon does.  If the device
   > daemon actually talks to the printer, it may have to understand the
   > data if the printer is a winprinter (the infamous Samsung laser
   > printer requires reasonably correct timing for sending data).  But the
   > application shouldn't know about the existence of something like this,
   > and certainly shouldn't talk to it.

This was to bring up a point that a separate process could track that data
to and from the printer.  The management of that data via that process
would be beneficial because the associated code that is run by that process
will know the specifics of the datastream and when it can query, abort,
send additional info. etc. to the printer.

If you have two printers that the protocol is the same, why re-write
the code that manages the protocol (bidirectional send, receive, abort,
restart, etc) code into each driver.  The individual protocol code
that can be shared on a grouping of printers therefore written once,
tested once, and plugged in along with its sister printer driver.


     >   - An IPC mechanism for getting dynamic information from the
     > driver and subsystem will be mandatory for licensing purposes.
     > It would likely be simpler if a singular interface could be used
     > by both an application and the renderer.

   >   I would argue that an IPC mechanism at the application level has
   >   already been defined and implemented - IPP.  Between driver and
   >   device, the interface to use is the pipe/socket: that abstracts
   >   the device IO into simple modules that can be reused for many
   >   drivers and devices.  The printer-specific stuff is then handled
   >   entirely by the printer driver, which has to be specialized...

>   I'd like to repeat my question to the people advocating a new
>   mechanism: what required capabilities does IPP lack?

I don't think that we are really advocating something other than IPP.  It
may end up that way but I think we are just talking about two different
levels and communications areas of the system.

From a printing application perspective, I would not want to have to code
IPP into it.  I would expect the appropriate subsystems to handle the
management of this for me.  I would expect nice query, set, page, job, and
drawing commands to be all I would worry about.  The system APIs I utilize
should do all the management and how we talk to the printer from a system
perspective should be nebulous.
printer is.

We are still grappling with the issues of renderer and driver interface
in these groups.  The licensing issue is very real and that is why it is
a hot button for a number of people.  Vendors would rather not have to open
source their intellectual property because they have to run their drivers
in the same process as open source licensed code.

IPP is typical for use with communications between systems and
systems/printers.  This does not address the fact of how an application
talks to a driver or finds out information about the capabilities
of the subsystem and driver combination (fonts and other things that
can be lumped under system).  What I am pointing out is additional
things that should be in place.

What I was attempting to point out is that we need to define interfaces
for standardization and to be able to allow extension.  We shouldn't
be tied to the past with things such as PPDs or munging them so that
we now become incompatible with applications that might not know how
to parse the data.  An API needs to be defined with data structures,
possibly XML, to isolate the application from having to do the tedious
work such as parsing information that may need to be changed in the
future. Methods and managing should be crisply defined for the
application via an API for capabilities support.




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...

[Omniprint-user] Re: [printing-driver] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Robert L K. <rl...@al...>]

   From: Michael Sweet <mi...@ea...>
   Date: Wed, 9 Jan 2002 09:00:26 -0500

   On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote:
   > ...
   > This all really depends on what set of problems you want to solve.
   > If you look at several scenarios it will better define the components
   > that are needed and the way you could handle most of the scenarios.
   > We need to handle:
   > -  Device configuration information dynamic from the printer
   > -  Status information returned from the printer
   > -  Local configured printer
   > -  Network configured printer

   I would argue that we do not want to distinguish between a local
   and network printer.  All printers should be treated the same, and
   an application that communicates with a local print queue should be
   able to access a network print queue the same way.  Again, I'm
   harping on network transparency!

I agree with this.  I would further argue that if the behavior of the
printer differs depending upon whether it's locally connected in a
single user environment vs. remotely connected, or in a multiuser
environment, that the system violates the "principle of least
surprise".  Unless it's absolutely impossible to provide identical
semantics (which I don't believe it is here), distinguishing these two
cases will simply lead to user confusion.

   > 1. Local printer configuration and capabilities
   >
   >   The local printing (single user) scenario is fairly easily handled
   >   when utilizing IPC mechanisms.  Latency and information about the
   >   printer go away in this scenario because you don't have to worry
   >   about the 100 user scenarios.

   I would argue that even a single user will have multiple windows,
   etc. open that want to access a printer at the same time,
   especially to check the current status.

While it's true that the latency issue largely goes away in this case
(at least if the printer supports an IEEE 1284.4 packet mode, which
Epson printers do, and the driver deals with this), it's really not
clear to me why we want to special case this.

   >    Local printer status information
   >
   >   When doing local printing, the status should be immediate and any
   >   device specific protocol converter (daemon) of the data be manage
   >   the flow to and from the printer to always maintain an accurate
   >   account of the status of the job and printer state.

   The device daemon should *not* try to understand the data to/from the
   printer, nor should we expect it to track printer or job status.
   Specialization leads to bloat and all sorts of implementation problems.

Depends upon exactly what the device daemon does.  If the device
daemon actually talks to the printer, it may have to understand the
data if the printer is a winprinter (the infamous Samsung laser
printer requires reasonably correct timing for sending data).  But the
application shouldn't know about the existence of something like this,
and certainly shouldn't talk to it.

   >   - An IPC mechanism for getting dynamic information from the
   > driver and subsystem will be mandatory for licensing purposes.
   > It would likely be simpler if a singular interface could be used
   > by both an application and the renderer.

   I would argue that an IPC mechanism at the application level has
   already been defined and implemented - IPP.  Between driver and
   device, the interface to use is the pipe/socket: that abstracts
   the device IO into simple modules that can be reused for many
   drivers and devices.  The printer-specific stuff is then handled
   entirely by the printer driver, which has to be specialized...

I'd like to repeat my question to the people advocating a new
mechanism: what required capabilities does IPP lack?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Omniprint-user] Re: [printing-driver] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Michael S. <mi...@ea...>]

On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote:
> ...
> This all really depends on what set of problems you want to solve.
> If you look at several scenarios it will better define the components
> that are needed and the way you could handle most of the scenarios.
> We need to handle:
> -  Device configuration information dynamic from the printer
> -  Status information returned from the printer
> -  Local configured printer
> -  Network configured printer

I would argue that we do not want to distinguish between a local and
network printer.  All printers should be treated the same, and an
application that communicates with a local print queue should be
able to access a network print queue the same way.  Again, I'm
harping on network transparency!

> 1. Local printer configuration and capabilities
>
>   The local printing (single user) scenario is fairly easily handled
>   when utilizing IPC mechanisms.  Latency and information about the
>   printer go away in this scenario because you don't have to worry
>   about the 100 user scenarios.

I would argue that even a single user will have multiple windows, etc.
open that want to access a printer at the same time, especially to
check the current status.

>   Information does not necessarily need to be statically maintained
>   unless the printer does not handle bi-directional information
>   that fully describes its configuration.  If the printer does not

Most printers cannot "fully describe" their configuration.  The smartest
inkjets provide a model ID (which often is too general to be of use),
installed inkset, paper status, and ink levels.  That is enough if you
know which driver to use, etc., but not which variety of ESC/P, PCL,
etc. to use, and what capabilities the printer has.

> ...
>   It can be done by reading a PPD or it can be done by calling a
> printer driver and getting the current information back.  In either
> scenario, it would be a very good idea to have an API that can return
> the information in a STANDARD format to a calling application.  It

Right, and currently the best match for that "standard" format is a
PPD file, which is supported by a lot of applications and adequately
describes most options.  I'm not saying PPD is the best format in
the world (there are many issues, and I'm quite sure that Adobe would
be interested in addressing them in a new rev of the spec), but it
is the best supported format, both under Linux and other operating
systems.  It is also already in use in all of the scenarios that have
been brought up.

> ...
>    Local printer status information
>
>   When doing local printing, the status should be immediate and any
>   device specific protocol converter (daemon) of the data be manage
>   the flow to and from the printer to always maintain an accurate
>   account of the status of the job and printer state.

The device daemon should *not* try to understand the data to/from the
printer, nor should we expect it to track printer or job status.
Specialization leads to bloat and all sorts of implementation problems.

> ...
>   - An IPC mechanism for getting dynamic information from the driver
> and subsystem will be mandatory for licensing purposes.  It would
> likely be simpler if a singular interface could be used by both an
> application and the renderer.
> ...

I would argue that an IPC mechanism at the application level has
already been defined and implemented - IPP.  Between driver and
device, the interface to use is the pipe/socket: that abstracts
the device IO into simple modules that can be reused for many
drivers and devices.  The printer-specific stuff is then handled
entirely by the printer driver, which has to be specialized...

As for licensing issues, simpler public interfaces eliminate this
problem - if a vendor doesn't like the license the "standard"
implementation uses, it can roll its own interfaces.  The TurboPrint
folks do this for their CUPS drivers, for example, since they don't
want to link to the CUPS imaging library (which is GPL'd, while the
rest of the CUPS API is LGPL'd...) to read the raster data.  Instead,
they rolled their own read-header/pixels code.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com