Public SourceMage Discussion List

[John T Copeland <johnc AT neto.com>]

Jason,
See my answers below.


Jason Flatt wrote:

> FYI, I'm removing the omni people from this replay as I suspect that they will 
> be uninterested in SMGL stuff.
>  
Of course.

> On Tuesday 24 December 2002 05:23 pm, John T Copeland wrote:
>  
>
> > Jason, Mark,
> > A follow up and final on this.  I finally got my printer to work
> > properly.  I did the following to get there.
> > 1) Downloaded omni-0.7.2.  Configured, compiled, installed AOK.
> > libomni.so showed up in /opt/omni/lib.  Mark, I had a small proplem
> > here.  I deleted all the printers in devices.mak except Panasonic, and
> > the compile failed with some error related to Hewlett Packard.  I add HP
> > back to devices.mak and compile went OK.
> > 2) Downloaded espgs-7.05.5 from the CVS, did a makesrcdist, replaced my
> > version in /var/spool/sorcery.  An install(cast -r -c) of espgs then
> > configured, compiled, and installed OK.
> > 3) Reviewed all my cupsomatic and PPD stuff
> > 4) Printed a simple text file OK
> > 5) Tried the test print in CUPS, and it failed looking for a particular
> > font.
> > 6) Investigation showed the standard ghostscript fonts had disappeard.
> > Probably because espgs install had done away with them.
> > 7) Installed(cast -r -c) ghostscript-fonts-std, and the CUPS test ,
> > print a test page, worked.
> >
> > Jason, it appears the espgs spell needs to be upgraded for the omniprint
> > driver.  You copy?
> > JohnC
> >    
>
>
> In attempting to provide solution(s) for you (and others who would be 
> interested in persuing a similar path), I have come up with some questions 
> for you:
>
> 1)  Did you build Omni from the source tar, or from CVS?
From the tarball on the Omni download site.  espgs from CVS because of 
Omni related errors in the tarball.

> 2)  Did you use GCC 2 or 3?
3.2.1

> 3)  Did you answer "y" to including Omni in ESPGS, or not?
Yes, which  adds the Omni interface, but not the Omni library, to the 
espgs device list.

> 4)  Did you build Omni as an integral part of ESPGS, ie: copied the Omni
>
>
> source into the appropriate place within the espgs source, or as a separate 
> packag
As a separate package, it was a manual, ./setup, ./make install, 
./makelocal install.  The tarball contains the ability to build/install 
the library, and patches(the additon of a "omni.c" function and code 
mods to call it) for various versions of ghostscipt so the build of 
ghostscipt will add omni to the device table.  espgs has the "omni.c" 
availabe for the omni configure option, while ghostcript does not.

> 5)  Are you suggesting that there may need to be some sort of trigger which 
> causes ghostscript-fonts-std to be recast after espgs, or was that just a 
> fluke?
Not sure.  I had previously installed the fonts at the same time I 
installed ghostscript(not espgs) in my first attempt to get my printer 
up, and somewhere along the way the fonts disappeared, so I simply did a 
re-cast.  It does appear that the fonts are required, and may need to be 
a required dependency of espgs.  I simply don't know that much about 
ghostscript and  how it relates to CUPS.  ghostscript probably does't 
relate to CUPS, except indirectly if required by cupsomatic.  In the 
case of omni(and my Panasonic KX-P2124 printer) and the CUPS 'print a 
test page' function the fonts were required.  Probably not be required 
with other printers, or non-omni supported printers, since Omni uses the 
ghostscript framework and is dependent on it.

> My plan is to create a separate spell for Omni and a dev/cvs spell for espgs.  
> If Omni does not work correctly (or at all) with the way it is currently 
> implemented (as an integral part of espgs), then I will remove it.
The key here is that if the Omni option is selected in espgs, then the 
Omni library is required, which is a separate download than espgs.  Only 
the interface  to the Omni library(libomni.so), not the total Omni 
functionality, is included as an integral part of espgs as it is 
currently implemented.  As the espgs spell is currently implemented, if 
the omni option was selected, only a configure/compile/install of the 
Omini library tarball would need to be added.  The tarballs is already 
downloaded as you know.  I used CVS only to fix the Omni interface bugs 
reported in the IBM Omni website.

Of course all the cupsomatic stuff further complicates the printer 
issue.   I don't know how much of a burden the proper integration of all 
this printer stuff is to SMGL users, but it is a significant problem, as 
printing always was/is.  Jason, this is a really tough problem for users 
and a tough problem for spell writing.  One could argue that 
ghostscript(espgs) is an optional dependency of CUPS if a users printer 
is not a postscript printer(which most aren't).  So you can see that s 
CUPS capability has to integrate CUPS, PPD's, cupsomatic, ghostscript(if 
it integrally supports your printer), and espgs perhaps for Omni.

I don't believe it is possible to put all this together in a simple(or 
even a comlicated simple) spell.  Omni supports a lot of printers and 
others will be added as time marches on, so I think Omni needs to be 
part of SMGL if it can be installed properly as a part of espgs.

Also it would be nice if this functionality for non-postscript printers 
and CUPS could somehow be cookbooked for SMGL users.

Dependency Hell continues unabated.

>  
JohnC