[Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large

[Thomas Dodd]

Aleksander Adamowski wrote:
> Thomas Dodd wrote:
> 
>> So if I use LPRng and want xprint to use PPDs?
>> Write another config option so Xprint can get the PPDs from a directory?
> 
> 
> Exactly.
> That would be a third model-config source mechanism plug-in (in addition 
> to classic model configs and CUPS PPDs).

Adding multiple ways of getting the configuration data sound trouble 
prone. I cannot think of any cases where more than one configuration 
type is used. System wide (/etc) and local ($HOME) happens, but the 
format is the same. NIS and LDAP attempt to add LAN wide, but still tend 
to be roughly the same.

> The CUPS is young, that's true, but look:
>   * It is based on IPP (Internet Printing Protocol), which is an 
> Internet standard, documented by RFC, thus is interoperable with systems 
> outside the POSIX world (Mac, Windows...)

Never seen IPP outside of CUPS. How do I configure Win98 to 
automatically get the pinter info from a CUPS server?

>   * It uses a widely adopted printer description format (PPD), which is:

I agreed with using PPDs for the info they provide. Paper sizes and 
trays, plex, resolution and such.

Notice one of the things that allowed CUPS to move in was compatibility 
of the user tools. Having lpr/lpq/lprm commands. It met resistance when 
it used the solaris lp/lpstat/lpcancel scommands only.

> Maybe I'm wrong, maybe I don't know something you do know. What are 
> those long term methods that you have mentioned?

Networked filesystems and file acess.

> But there's no standard covering filesystem representation of LDAP of
> NIS data, so those would be purely ad-hoc solutions.

That's unfortunate. What about the libc functions that get data from 
files, NIS, LDAP and other sources? The apps that uses that info don't 
know or care if the data is a file or NIS.

> The UNIX "everything is a file" paradigm just doesn't fit well to all 
> possible problems, and it's is the case here too.

That's been claimed for 20 years, yet it still works well. Look at the 
linux /proc and nor /sys psudoe filesystems. It uses "files" for thing 
others said a file wouldn't work for.

> Ok, comparing with LDAP, how do you abstract a query for a telephone 
> number as an attribute of a person to a filesystem?

Not a clue.I don't use LDAP much. I do know I've had problems wil mail 
tools not working with LDAP and IMAP. So the current interfaces ar not 
great.

> What filesystems implementation currently offer built-in indexing of 
> such data in order to speed up searches?
> 
> You just can't use the UNIX filesystem for everything.

You don't have to have full access for PPDs. You just populate a CUPS 
directory, with print queue directories, which has a PPD file. Maybe 
some other info, but we don't need it.


> formats. E.G. "to submit a job with a non-default resolution of 600 DPI 
> you open the file spool/printername/queuename, and write 'Resolution: 
> 600 DPI\n\nPOSTSCRIPT_DATA'".


Or write to the 600DPI subqueue.

CUPS/
    lp1/
        600dpi
        300dpi
    lp2/
        600dpi
       1200dpi

You only need the different queues for info that won't fit in the 
postscript data. Not sure what postscript supports, but I know plex mode 
and paper tray selection are.

> There are currently no tools to populate that data to Xprint, so each 
> deployment requires writing them by hand. And they'd have to be launched 
> periodically from crontab (the changes wouldn't be instant), or 
> modyfying the CUPS source so that it launches a synchronisation script 
> after each change in printers configuration.

If the PPDs are being used, you don't have to write it by hand.

> If yes, then when you have a couple dozen's of printers, either users 
> would be denied printing access for a couple of seconds a number of 
> times a day, or in the case of replacing a broken printer the users 
> would have to wait with their printouts till next day. Both solutions 
> are unacceptable.

And restarting CUPS is instant? All changes are immediately available on 
all clients? And xprint doesn't take that long to start.

I do think that Xprint need a way to reload config data other than a 
complete restart. With X getting RandR most reasons for an X restart are 
  going away.

Then again, for a long time, lpr has required a restart to get config 
changes. We've all survived that so far.