On Mon, 24 Jul 2000, Jeff Licquia wrote: > [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: > > I've managed to do this in theory (compiled, but untested): Just add back > Got it. I will note this and implement it. Don't. It doesn't work. I sent a patch to the CUPSML yesterday which does implement this right, along with a much better fontpath for Debian (taken from the gs-aladdin package) and Makefiles cleanup which fix that mess of RMs you had in Debian's 1.0.4 package :-) BTW, it looks like they fixed the library builds as well, so now a simple $(MAKE) is enough to correctly build the package. > If you have patches, I'd appreciate them; otherwise, I'll just go > ahead and do this. I've been sending the patches to the CUPSML for upstream inclusion. If you don't subscribe to that list, drop me a reply and I'll send them directly to you. > In theory, this shouldn't be necessary if we can get CUPS to use gs > rather than pstoraster. Regardless, I've managed to implement this, so that one can choose wether to use stock GS or the modified CUPS version. > > - 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. I really hate when upstream makes a mess of things :-) I didn't bitch in cupsml about the atrocious handling of /etc/cups/printers.conf yet, but I will sooner or later. Since when mixing configuration and state is acceptable in a well designed product?! CUPSD will _trash_ your printers.conf file and write to it so many times (at least once per IPP request) it actually belongs in /var, not in /etc. This is Not Good. I really didn't expect to find such a thing in CUPS after the beatiful way they got the MIME handling thing to be painlessly extensible :-( > > - 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.) Right, I'll write it. CUPS is broken for */* MIME types right now (I tested :-), and the manual DOES say "DON'T DO IT"), so one would have to add the filters directly (which isn't a bad thing, come to think of it). Which means write a 'magicfilter' clone for CUPS instead of interfacing the two (it'd be pointless to interface the two packages since all the MIME detection and identification would have to be duplicated anyway). > > - 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. They'll have to be there for CUPS to plead for Standard priority, though. I suppose whomever packages PPDs should place them somewhere in /usr/share/. If CUPS takes the responsability of copying them to /etc/cups/ppd, they needn't be conffiles or stored in /etc. While this would have to be documented, it's actually a good way to do things IMHO. > > - 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. I wonder if the colorspace mapping and correction doesn't go bonkers with a standalone GS, but that'll have to wait. I don't feel like testing THAT now, and I don't have a color printer handy anyway. Good luck with CUPS 1.1.1. I'm trying to package it myself just to learn how to do a multiple binary package, and so far it doesn't seem too bad (I'm not even trying to touch the smooth upgrade stuff, though :-) ). -- "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:
pgpZXcNrXRYIH.pgp
Description: PGP signature