[cups.general] Cups

[John]

Hello Mike
I have carmed down a bit now. I have a habit of climbing on soap boxes if I'm 
not careful. My problem here is that I see an increasingly rosy future for 
Microsoft. Along with a lot of other people I'm inclined to think that people 
should have more choice but I don't think that this will happen until areas 
such as the ones under discussion are simplified one way or the other. Ease 
of installation of anything is probably the single most important thing on 
any system.

In the same vein.

I detect a big system note in your comments. This reminds me of DEC's attitude 
to PC's when they first came out. They actually thought that they wouldn't 
catch on. Me I wondered why they didn't port rt11 on to them and sell it for 
a tenner. The 'intel' platform is making ever increasing inroads everywhere. 
I work in the automotive industry. I aught to see all sorts of work stations 
in use - I did once. Now all I see is windows on ever increasingly powerful 
boxes. According to figures I have recently seen in terms of $'s Intel is way 
way ahead of any other silicone suplier and AMD sales are looking good I'm 
glad to say. They may even oust Intel. This must take it's toll on other 
platforms though eventually. That's sad but maybe what is there in printer 
terms allready is adequate for higher cost specialist platforms. Mac's are 
being catered for increasingly though and I understand that their insides are 
very unixy. What have they done that Linux/cups hasn't?

The two cups mails just arrived on my machine. One on a HP printer and another 
on remote administration. I think that these illustrate my point. Neither of 
these users are likely to be average Joe's. The above average Joe probably 
needs instructions laid out in a for example format that cover as many as 
possible typical printer installations. All steps need to be clearly 
explained. Jargon needs to be avoided or explained very carefully. Error 
messages need to lead directly to solutions. Command explanations are 
probably allready adequate. All of this is I know utopia but attempts could 
be made to at least head in this direction. Another alternative is so called 
'wizards'. I personally have mixed feelings about them but they do mask 
underlying complexity in situations where this is likely to cause 
difficulties. Ideal for a truly average Joe but the direct route should also 
be available.
Will a command line interface ever be suitable for typical users? Most young 
software graduates I meet these days say 'yes I know unix' but in real terms 
they have been using x windows and what ever. I am not a typical user. I'm a 
software engineer. In principle given a specification etc I should be able to 
make use of it.

On the monumental effort involved with gdi emulation I can't comment. It isn't 
an area I have ever had the need to look at but I can't help wondering if 
cups is becoming archaic especially in respect to printer availability and 
cost. It has even been suggested that most 'stock' Linux drivers aren't very 
good. Why should a typical user have to buy or produce another one? A windows 
driver will do all that the printer is capable of. It will work straight out 
of the box. It will usually install itself. True more sales may correct this 
aspect but isn't that a chicken and egg situation?

These comments have mostly been made without any reference to my own problem 
which relates to another illustration of simular issues. I am short of a lot 
of information. The point I'm trying to make is an example of the other 
difficulties that would put a lot of users right off. I recently purchased a 
colour laser printer that states Linux on the box. The manufacturer goes to 
great lengths to point out on it's web sight that it's drivers offers far 
more facilities than it's rival's linux offerings. It's a Samsung and I have 
since looked at the HP and Epson web sites and found that this statement is 
true. The printer in question is way over the top for personal printing. It 
could easily serve as an office printer for 20 or 30 people in all sorts of 
jobs. Installation was interesting. I'm running suse9 and kde. The 
installation runs graphically but I found that I couldn't complete the final 
step (configuration) due to rights issues even though I started it all as 
root. (When I try it again I will create a KDE root user and try that.) Then 
came the problems. I tried to complete the installation with yast (the suse 
installation utility). The error messages here were excellent and very 
direct, presumably from cups. The ppd file has a missing section, a default 
wasn't specified and the printer name wasn't a string even though it 
consisted entirely of ebdic characters. I then found the KDE printer wizard.  
It accepted the lot but the printer wouldn't work - nothing came out of the 
port. Yast could however at least show that this was working but not in any 
fashion that the printer could understand. I had a look at the ppd file - no 
problem correcting the missing default. The others not so easy so I went in 
search of the ppd file spec. I found this but came to the conclusion that the 
writer ran out of wind after the first few pages. The missing bit of the ppd 
seems to relate to the rear single sheet entry point but the spec doesn't 
really identify what's going on here. Maybe all printers are the same? The 
string seems to need spaces at each end. From a software engineers point of 
view I was disturbed by the lack of any details on the architectures that are 
being used. Is a specific print driver being used for instance? If I attempt 
to write the corrections myself I would have no confidence what so ever in 
the outcome. The ppd file seems to be just there to generate the various 
printer configuration boxes. This is a neat idea as are other cups 
abstractions but I can't be sure that this is the case. OK all of this 
relates to ppd files but cups needs them. They can't really be separated. It 
gets worse. I've only had two trawls through the spec but I'm fairly sure I 
will never get a clear idea of what I need to do from it. The 1st trawl was 
straight to the bit I needed. It wasn't very informative. 
(Understatement.)The 2nd trawl lead me to believe that I have a sheet feed 
printer that has been set up as a roll feed printer! Is this ok - will the 
printer only work in that fashion. I have no idea but I doubt it as I can't 
see any evidence of the ppd file having information on control sequences etc. 
Did the second trawl help - not really. Do I need to absorb the whole thing? 
I hope not that would be documentation in it's worst form. Then there's the 
cups DDK. Do I need to get into that to add maybe 20 lines to the existing  
ppd file. Looking at the content of the ppd file does anybody really need a 
DDK if the base documentation is good enough? The language used looks to be 
on a lower par than dartmouth basic.
I eventually got to the linux printing org. Here this printer is described as 
a paper weight. Sad. I have seen the output under windoze - it's truly 
excellent. Even a confirmed ink jet user was very surprised. His ink jet at 
some incredible dpi couldn't do much better and would be worse at 3 colour 
600dpi. The printer is capable of 1200dpi but that aspect is entirely missing 
from the ppd. As somebody has allready pointed out this comment by the org 
isn't of much use to anybody. Apparently it will work on some installations/
distributions but not others. Here I have to wonder why. Some form of 
standardisation is essential in this area.
Where will I go from here? I will have a go at correcting the ppd file. I will 
trawl the cups site. If this doesn't work out or Samsung doesn't come up with 
a correction shortly the printer goes back to the supplier. People shouldn't 
have to and will not put up with this sort of problem if alternatives are 
available. It isn't good for Linux, CUPS, or the printer manufacturer.  I 
suspect that it would be unfair to lay all problems on the printer 
manufacturers. They all seem to have simular problems and are unlikely to be 
equally bad. In terms of the facilities offered Samsung would appear to be 
paragons - if only it would work.

regards
   john woodhouse

On Saturday 08 May 2004 14:24, Michael Sweet wrote:
> John wrote:
> > Hi
> > I would like to be provocative.
>
> By all means, please do! :)
>
> > I have successfully worked on a variaty of platforms over the past 35
> > years. Printing is to say the least almost a universal 'computing'
> > requirement and here we have cups. The underlying documentation is
> > appallingly bad. The ppd file specification is an excellent example.
>
> Well, we can't take credit for the PPD specification - that is
> Adobe's work, not ours.
>
> > It was clearly written by some one who knows what they are doing and
> > assumes that every one else does too. While this is great for the
> > 'boys' it's not much use for anybody else especially the
> > inexperienced.
>
> Well, given that the specification was written to assist computer
> scientists in developing printer drivers for PostScript printers,
> why would you expect that it would be written for Joe User?
>
> > It's also clear from the questions posted here that the same
> >
>  > comments can be applied to cups documentation in general.
>
> Can you be more specific?  What areas do *you* feel need
> improvement?  What would you like to see?  If you don't get
> specific, how can *we* determine what *you* want???
>
>  > ...
> >
> > linux box. I like what I see. In that particular area I am left
> > wondering why some one hasn't produced code that make use of the
> > windows driver that COMES WITH EVERY PRINTER THAT IS CURRENTLY
> > AVAILABLE. This has been done with codecs. The case is a lot clearer
> > with printers. If one buys a printer one has clearly bought the
> > driver that comes with it and the facilities it offers. I am firmly
> > convinced that Linux will remain in the backwaters until this area is
> > finalised and all installations are at least tidied up and made more
> > transparent to the typical user.
>
> Well, in the case of codecs and network drivers, there is a well-
> defined and simple interface that can be emulated in Linux.
>
> Printer drivers are another matter entirely, and many will make
> use of dozens of DLLs and any number of Windows system calls in
> order to do their work.  Assuming that we *could* somehow emulate
> enough so that common drivers worked, there is still the issue
> that those drivers would only work on Intel-based systems.
>
> In short, we (the CUPS developers) do not consider emulation to
> be an effective long-term strategy and in the short-term would
> be a monumental effort that would be better served by improving
> native drivers on Linux and UNIX in general.
>
> Fortunately, Linux support for most business printers and many
> consumer printers is quite good as long as you are using a
> printer-friendly Linux distro that keeps up with the free software
> printer drivers.