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

[Aleksander Adamowski]

Thomas Dodd wrote:

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

It's in Windows since version 2000. Win98 isn't supported by MS anyway 
for some time, it's too old.

In Win 2000, when adding a printer, you select adding by URL, and you 
can paste a IPP URL there (from CUPS it would be 
http://cupsserver/printers/printer_name).

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

I know that, but as I've said it's not enough. The UNIX filesystem model 
is too limited. For a rationale, read my next reply.

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

But that's using getent(), not the filesystem-related functions. Which 
only illustrates that the filesystem model is not perfect for solving 
all thge problems.

We have a key->value database problem, with a need for efficient 
searching based on various object attributes, and traditional UNIX 
filesystem model is weak at this task.

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

It works only, if you know precisely the name and location of the object 
which you want to get. This is indeed good for storing system settings, 
and printer model configs.

But when you want to centralise organization-wide information, this is 
not enough, hence the popularity of LDAP and directory services in 
general these days.

CUPS could be thought of as a "directory service for printers", and it 
will probably integrated with LDAP some time in the future.

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

That would be nice, but there's no implementation nor a standard 
covering this.

If XPrint were accepting a directory of PPDs with printer names as 
filenames, one could simply NFS mount the directory /etc/cups/ppd from 
the CUPS server at a proper mount point- that would be a nice 
filesystem-based standard for the start.

But this layout is internal to the CUPS server, it can change in the 
future and the CUPS API is the most proper way of extracting model 
information.

>
> Or write to the 600DPI subqueue.
>
> CUPS/
>    lp1/
>        600dpi
>        300dpi
>    lp2/
>        600dpi
>       1200dpi

Then you'd need:
CUPS/
   lp1/
       600dpi/
          A4
             doublesidedlongedge
             doublesidedshortedge
             singlesided
          A3
             doublesidedlongedge
             doublesidedshortedge
             singlesided

          Letter
             doublesidedlongedge
             doublesidedshortedge
             singlesided
       300dpi
          A4
             doublesidedlongedge
...

You get the idea?

Now imagine you want to add support for e.g. media source (envelope 
feeder, manual feeder, tray 1, tray 2...). Or economy mode.

This directory structure becomes exponentially complex, because the 
information is multidimensional. There are multiple orthogonal 
attributes (paper sizes; possible plexes; resolution). You end up with 
thousands of symlinks for a few printers. At some point your filesystem 
will run out of inodes. Earlier it will become very slow.

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

The structure is not only for submitting, but also for discovering 
information about supported printer input, e.g. so you can see whether a 
printer can print 600DPI duplex on the Letter format paper. This is what 
we are discussing: a way to specify model config information to Xprint 
in a functional way.

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

I know, I were talking about distribution of those PPDs in large 
corporate environments.

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

No, but it's not needed.

> All changes are immediately available on all clients?

Exactly. CUPS is designed as a heavy duty multi-user, multi-workstation, 
multi-printer system.

> And xprint doesn't take that long to start.

For environments where there are thousands of user, a restart taking a 
couple of seconds is unacceptable. Of course, one could cluster Xprint 
servers and provide dynamic failover, but it would be better if it could 
just run continuosly and not be restarted when a trivial thing such as a 
change of a printer somewhere on the network occurs.

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

Agreed.

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

Some have got fed up with that. And CUPS is the result. It was designed 
to eliminate that problem (among others).

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.ab.altkom.pl