Re: cupsys (was: Re: lprng as 'stantard' package)
On Fri, Jul 14, 2000 at 06:53:23PM -0300, Henrique M Holschuh wrote:
> (CCed to cupsys maintainer, so as to get his ideas on the 'wishlist' stuff
> at the end of this email without filling out bugs)
Sorry I didn't reply; it appears I need to work on my procmail
filters, as it all got dumped into my debian-devel mailbox. :-)
> On Fri, 14 Jul 2000, Robert Bihlmeyer wrote:
> > Josip Rodin <joy@cibalia.gkvk.hr> writes:
> > > % apt-cache show lpr lprng cupsys | grep ^Size
> > > Size: 85766
> > > Size: 894722
> > > Size: 2298766
> > >
> > > Nice :<
> >
> > First, cups provides more than the other printing packages. It can
> > print postscript to non-PS printers out of the box, and seems to
> > include some version of GhostScript for that. If one subtracts out the
>
> Yes, and that's my grip with it so far. Unless the code HAS to include a
> modified GS instead of interfacing to an installed GS for a very, very good
> **technical** reason, that's a rather ugly way to solve a problem.
The main reason cupsys includes GS is laziness; Easy Software Products
did some things to it that I don't fully understand yet, and I'm loath
to pull it out without a working replacement.
> Besides, something called the Common UNIX Printing System HAS to follow the
> Unix way, ne? That means piping through GS, not including it... even if it
> would require extending GS' external interfaces upstream, or writing a CUPS
> driver for GS.
My plan, at this point, is to set up cupsys by default to use gs for
formatting, and depend on gs; the cupsys-specific gs and fonts could
be installed as a separate package, which wouldn't be required for
cupsys proper.
I don't think this will be too hard; right now, CUPS works through
filtering, and the "pstoraster" command (the CUPS-modified gs) is
simply one of many filters. Printing to an HP, for example, goes
something like this:
PostScript job -> pstoraster -> huge raster image -> rastertohp -> printer
> And, provided that cupsys stabilizes enough, an unpacked size < 1.5MB (no
> docs) would make it a very good candidate for a user-friendly, standard
> printing system for Debian (as long as we package the KPP [see
> http://cups.sourceforge.net] GUI front-end as well, that is).
>
> As it stands, I think either promoting lprng to standard or keeping the
> status-quo (lpr) are better choices for the time being (Woody).
Well, I wouldn't mind cupsys being promoted to "preferred print
system", but I'll let others make that decision. Personally, I think
it could be a very capable default printing system. It is a bit new,
though, which might be of concern; do we want an immature system
becoming the default?
I haven't seen the KPP front end; I'll have to take a look, and
package it (that is, if it isn't already).
> > I conclude that cupsys-doc should probably be split off, and that a
>
> This is a very good idea. However, CUPS has been infected by the "see ma,
> i'm a webserver as well" plague that is so common these days. Part of that
> cannot be avoided, as IPP is layered over http. But cupsys also serves a lot
> of help docs through its http layer, which might need some automatic
> disabling or something like that when the -doc package isn't installed.
This is something I've been thinking about. One possibility: the
index page (which contains the link to the documentation) could be an
alternative, with the default cupsys one not including a documentation
link, and the cupsys-doc one including it. I believe that the docs
are all referenced from a central start link, so removing one link
will suffice.
> (AND that file serving is something I'd disable immediately if at all
> possible, it's just not worth the danger IMHO. Same goes for PULL IPP
> printing and any other stuff like that... but THAT is a really huge IMHO)
Don't think it's possible now, except by doing things like listening
on localhost only. That's because the same interface that allows you
to print serves the admin interface, which gives you the link to (and
serves) the docs.
> > separate cupsys-ps package that only people without PS-aware printers
> > needed would be a win (perhaps this could also somehow share with
> > GhostScript).
>
> If one manages to get a pstoraster which runs GS instead of embebbeding it
> (somehow keeping whatever enhancements CUPS made to the code, of course. The
> idea is to dump the original pstoraster without lowering CUPS quality), that
> alone would be enough to reduce the package size nicely. It shouldn't be
> impossible, as CUPS 1.1 builds nicely even after a rm -rf pstoraster and
> slight makefile edit :^P
As mentioned before, technically CUPS doesn't need pstoraster. It
uses a filtering system based on MIME types that just so happens to be
a bit dependent on PostScript for implementing certain options. I
imagine it won't be a big deal to replace it with the default gs.
> > How lprng or cupsys compare on technical merit should be our main
> > concern here.
>
> I'm worried about cupsys' security. It has too much "nifty network
> awareness" (i.e.: browsing, serving files(!) and running cgi scripts(!!))
> for my tastes, Personally, I'll not trust it in a hostile network until I
> have a LOT of time to look at it closer.
Point granted here. There's been one DoS already, as well as an issue
with a broadcast autodiscovery system CUPS can use (the existence of
the broadcast tipped off some intrusion detection systems, which
wasn't cool). I can't imagine these will be the last.
> Other stuff the DEBIAN packaging of cupsys and friends would need before
> going standard (IMHO, obviously):
>
> - To try to take advantage of magicfilter... or incorporate all that
> conversion support that magicfilter already has (at the very least DVI,
> compressed data and *roff). If CUPS has a fallback system for conversions,
> a wrapper script could be written I guess...
There's a wishlist bug for cupsys to recognize DVI already, so 'lpr
file.dvi' would work. This might be an interesting option; I can't
imagine it would be that hard to write a filter that would convert
from one of the many formats magicfilter supports to PostScript, and
register it into the CUPS system.
> - To integrate CUPS with the distribution's font system (it really should
> share fonts AND font configuration with the gs-* packages) if that isn't
> done yet. I know I would be VERY ticked off if I found out that my
> postscript stuff wasn't printing correctly because cupsys' embebedded
> postscript rasterizer was not even trying to use the postscript fonts
> installed in the system. I assume others might not like it either :-)
Be ticked off. As of now, it doesn't.
> - Package all that nifty ammount of printer PPDs at cups.sourceforge.net if
> their license allows it. Otherwise, consider packaging a installer and add
> URLs to cupsys' README.Debian
This could be done. I could do it, or (if anyone out there's
interested), I described a little naming convention for others to
package PPDs and other add-ons to CUPS.
If anyone decides to do this, I'd be delighted to help as much as I
could with integration issues, etc.
Alternatively, I'll probably do it eventually (once CUPS 1.1 is
uploaded, the packages are reorganized, I can hook standard gs into
CUPS, fix some of the bugs, etc.)
> - Package the GS PPD and related utils if the internal rasterizer can't be
> made to run GS to begin with. Without it, cupsys simply isn't useful for
> way too many people.
See above.
> - Package the web-based administration separately (requiring the -docs
> package) if that proves necessary for system stability or reduces size in
> a meaningful way (better than 500kb savings IMHO).
See above.
Reply to: