[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cupsys (was: Re: lprng as 'stantard' package)

On Fri, 14 Jul 2000, Henrique M Holschuh wrote:
> 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...

This one I've not addressed yet. However, it should be possible to add a
"*/*" filter with cost 1000 or whatever, which wraps a call to magicfilter
and outputs a ps file back into the cups filter chain.

Given that cups rejects anything which it couldn't find a filter to grok
(unless you tell it its raw data), this should work fine.

Also, I got to compliment the cups guys. Their management of the /etc/cups
directory makes it _very_ easy to break components into different binary
packages, as well as designing add-on packages. Cups looks for *.convs and
*.types when reading its filter conversion tables, so there's no need for
update-modules behaviour.

> - 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 :-)

I've managed to do this in theory (compiled, but untested): Just add back
gs_lib_default_path to pstoraster/gscdefs.c, and initialize it. The proper
way would be to add a --set-default-gs-libs-path to the configure script,
with a default of empty (the current cups practice) and set GS_LIB_DEFAULT
to it, akin to what gs5.50 and 6.01 do in their original makefiles and
gscdefs.c. I just dumped the output of (source package)
gs-alladin-6.01/debian/default_path.sh 5.50 in there for the testing :-)

The default lib path ended up in the binary pstoraster executable, and it is
used in imainarg.c so I guess this should work. Obviously,
/usr/share/cups/fonts (and /usr/share/cups/pstoraster/ ?) should be
prepended to the default Debian gs_def_library_path just as to make sure
we're not breaking anything.

This means 1829kb (installed) of /usr/share/cups/fonts can (and SHOULD) be
removed, and replaced by a dependency on gsfonts.

Now, for the /usr/share/cups/pstoraster files. These are the GS internal .ps
files, but they're only 369kb, so I didn't bother as the path to those in
the GS packages change every version anyway, and one shouldn't need gs
installed to use pstoraster.

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

This can be easily done, due to the cups handling of its /etc/cups config

I'd suggest breaking stock cups into:
 -  cupsys-base (or cupsys-common, or cupsys)
      Everything not in the packages below :-) Do note that stock
      /etc/cups/mime.convs must have the pstoraster and pdftops lines
      removed, as those would be provided by other optional packages in
      /etc/cups/pstoraster.convs and /etc/cups/pdftops.convs files.
 -  cupsys-bsd, libcupsys1, libcupsys1-dev
 -  cupsys-pstoraster
      Stuff not needed by onwers of ps printers or cupsys-gs users, that is
      the pstoraster filter and its data files. This package should depend
      on gsfonts, and have the Debian standard gs_lib_default_path with cups
      lib directories added hardcoded in. This one is at least 1254kb
      installed (after stripping). I'd be even bigger if the fonts were not
      Send the default lib path stuff upstream as a wishlist. Why they removed
      it in the first place is something I don't know.
 -  cupsys-pdftops
      All the pdf stuff. Unless xpdf is so good as to accept and correctly
      process just about every PDF in the planet (including the encrypted
      ones!), it shouldn't be forced down our throats (even if it's not
      much bigger than 300kb installed after stripping).
 -  cupsys-docs
      The /usr/share/doc/cupsys documents cups like to export to the world.
      *Please* add a WARNING-FOLDER-EXPORTED-BY-CUPSYS file to this directory,
      for obvious reasons. This is about 2097kb installed, so it DOES
      deserve a package of its own.

      Also, there is a pdf and a html+external images version of every
      document, which is a waste of space. The pdfs are 1261kb, the
      remaining 836kb being the html+images version of the same docs. Maybe
      a cupsys-docpdf package would be good enough, and the html+images
      could go in cupsys base package anyway.

Also, I'd suggest packaging:
 -  cupsys-magicfilter
      Magic-filter glue as a very low priority (high cost) filter for CUPS.
      Contribute this one to the cups bazar (or upstream), of course. I'll
      write it if that's what it takes to get it done (but I'm not a Debian
      developer, so someone else must do the packaging).
 -  cupsys-ppd
      Lots and lots of freely-distributable PPDs. Note that the ppds
      distributed with CUPS are in the cupsys base package, not here.
      BTW, IMHO PPDs should always be conffiles and stored somewhere in /etc, 
      not in /usr/lib or /usr/share.
 -  cupsys-gs
      The GS PPD and filter glue, for those who'd rather use an external
      (and possibly more up-to-date) GS than pstoraster. This also requires
      less disk space than pstoraster if you already have gs installed
      anyway, but lacks pstoraster integration with cups (memory limits, and
      *maybe* a faster handling of the resulting ps or bitmap to the next
      guy in the chain as far as I can tell). On the other hand, it supports
      a LOT of printers CUPS never will out-of-the-box.

That done, I'm one of those who would gladly drop lprng for cups. I think
the quality increase of the packaging is well worth the trouble of
implementing it.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Attachment: pgpRPjQK4DMSV.pgp
Description: PGP signature

Reply to: