Re: cupsys (was: Re: lprng as 'stantard' package)
[sorry again for the late replies, as I'm trying to catch up]
On Sun, Jul 16, 2000 at 09:39:49AM -0300, Henrique M Holschuh wrote:
> > - 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.
Got it. I will note this and implement it.
If you have patches, I'd appreciate them; otherwise, I'll just go
ahead and do this.
> 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.
In theory, this shouldn't be necessary if we can get CUPS to use gs
rather than pstoraster.
> 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.
For CUPS 1.1, I will be adding:
- cupsys-client
SysV client files
The easysw people did some work to make the CUPS client programs
standalone, so you could have a central server and a lot of clients
that only had libcupsys and cupsys-client installed.
> - 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
> removed.
>
> 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.
I like your way of thinking about this better. The problem is that
the docs contain links to the PS and PDF versions of the docs, so
you'd have to modify all the index pages depending on what you had
installed, which becomes a mess. OTOH, if all the docs are stuffed
into one package, one link on the master page would be all that would
need to change.
> 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).
Write it, and I'll package it. (Or not, and I'll add it to my todo
list.)
> - 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.
Not the way CUPS handles them. The PPDs in /usr/share are templates;
when you create a printer, they are copied into /etc/cups/ppd. I
would imagine that third-party CUPS PPDs should be treated the same
way.
As I mentioned, I'd like to make it possible for others to package
these as add-ons. If no one has the time or ability, I'll get to it
eventually.
> - 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.
Got it.
> 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.
Thanks for the vote of confidence.
Reply to: