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

[Aleksander Adamowski]

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).
Then for example, if in the future you'd switch to CUPS, the 2nd plugin 
(PPDs from CUPS) should detect CUPS availability, and provide additional 
model information form CUPS.

All info should be merged with configurable priorities (you should be 
able to decide what overrides what, with the default being 
"model-configs <- CUPS PPDs <- local manually installed PPDs").

If some other network mechanism was added in addition to CUPS PPD (e.g. 
LDAP), it should probably sit between CUPS PPDs and local PPDs (that is, 
your local PPD's should override everything else).

>> Well, it seems that the CUPS API has been here for a couple of years 
>> and it isn't going away in a few years, especially since it now ships 
>> with all major Linux distributions, Apple MacOS, and works well on 
>> other *NIX-es.
>> In fact, it is steadily replacing older spoolers everywhere.
>
>
> Slowly. And 3 years ago people said LPD wouldn't be replaced. 
> Something will happen and CUPS will no longer be the hot spooler. It 
> could be next year, or it could be 5 years. I just don't think that 
> API should be used when other, long term methods are available instead.

Well, this is the point where I do disagree with you.

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...)
   * It uses a widely adopted printer description format (PPD), which is:
      1) Supported by largest amount of printer vendors
      2) Based on a standard, mature Postscript language that has been 
here for almost thirty years, and PPD has been a stable standard for 15 
years
   * It's so superior that it has replaced other spoolers in all major 
Linux distros just 2 years ago and since then it shows no signs of weakening

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

> That's Unix. Everything is a file. It doesn't have to be local, it 
> could be NFS, SMB, or som other networked filesystem easily. It the a 
> simple way to get info from CUPS, and LDAP, and NIS, using file commands?

Well, you can write shell and Perl scripts. That's moderately complex 
and I for example do some of this stuff. But there's no standard 
covering filesystem representation of LDAP of NIS data, so those would 
be purely ad-hoc solutions.
Most probably they would end up as some "NFS-accessible structure 
synchronised through rsync-over-SSH by a Python script getting a pipe 
from a Perl sub, launched as a CORBA method from a shell script from 
crontab", being a nightmare to support by any admin.

Besides, LDAP or CUPS are used mainly there, where ordinary filesystem 
stops to scale well; LDAP offers high performance access by queries to a 
hierarchical database by various keys, something you don't have with NFS 
(NFS doesn't offer indexing by various file properties, you just have 
directory structure and symlinks).

CUPS's value is mainly in the standardization, so it can be used 
directly through IPP from UNIX clients, Windows clients and MacOS clients.

It's a heterogenous environment godsend.

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

> There is no reason for Xprint to know CUPS, LDAP, NIS, NFS, HTTP, ... 
> when all could be abstracted to a file which is what Xprint needs. 
> That a Windows/Microsoft mentality, all apps speak all protocols. Look 
> at the problems caused but not abstraction these already. Every mail 
> tool has to have extra, often buggy, support for LDAP and IMAP. If 
> they were abstracted to a file model, all mail tools coul use them 
> without (major) changes.

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

Note that telephone number queries are specifig, since telephone numbers 
have to be compared in a special way (e.g brackets would be ignored etc.).

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.

Now you could imagine some mapping of CUPS printers for filesystem (e.g. 
a single printer queue is a file, and printer with its various queues is 
a directory, and properly named symlinks pointing to those queues denote 
current settings, e.g. currently set default paper orientation and 
resolution and ReT settings) which could be shared through NFS.

But there's no standard on that. And probably never will be. And you 
have not only standardize on directory structure, but also on all data 
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'".

That's just too much work that has to be done fighting inertial; even if 
a strong community started today, it would take more than 10 years to 
get this widely adopted.


> Xprint would be (is) a central server, not running on every machine if 
> there is a central CUPS server in use.
>
> If the Xprint server and cups serve are colocated, Xprint can query 
> the spooler as it currently does, and load the same PPDs as CUPS did. 
> Only "extra" step is installing/starting Xprint. 

Plus synchronisinhg the ever-changing printer data from CUPS to Xprint. 
The helpdesk guys replace broken printers, relocate them to different 
offices, rename them, change default printout settings, and they do it 
using CUPS's web interface.

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.

BTW, I couldn't find this information in the docs: does Xprint server 
require a after a change in model configs?

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.


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