Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Devin Reade]

--On Wednesday, February 17, 2016 11:49:30 AM -0600 Chris Bennett
 wrote:

> I do see that lpc, lpq, lprm are dinosaurs and have to be made extinct
> and replaced with something more functional with more information output
> and better capabilities.

Whatever changes may happen under the hood, I would like to see
at least the basic operations of lpr, lpq, and lprm remain available
under those names, using the existing syntax.  I'm no fan of CUPS, but I 
get by with it on linux because of the lpr compatibility shim.

Devin

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Mihai Popescu]

| Funnily enough I didn't see either of those until they were quoted here ;)

| I recommend slrn pointed at gmane's news server for reading misc with liberal
| use of the 'k' key, some of the features for making newsgroups readable are
| equally applicable to busy mailing lists.

Is it possible to filter messages using some unwanted email addresses?

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Stuart Henderson]

On 2016-02-19, Chris Bennett  wrote:
> Why don't hru...@gmail.com and li...@wrant.com have a lovely and
> exciting chat off of my lpd/lpr thread?

Funnily enough I didn't see either of those until they were quoted here ;)

I recommend slrn pointed at gmane's news server for reading misc with liberal
use of the 'k' key, some of the features for making newsgroups readable are
equally applicable to busy mailing lists.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Roderick]

On Fri, 19 Feb 2016, Chris Bennett wrote:


On Fri, Feb 19, 2016 at 06:52:43PM +0200, li...@wrant.com wrote:


Maybe you should pull your head out of the sand (asshole) and understand
[...]


That previous request was not to include trolling me privately.


By the way, I only expressed my oppinion and concern. I am glad that
Chris wants to work in the project from which I profit.

Rodrigo.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Garance A Drosehn]

On 17 Feb 2016, at 14:07, Chris Bennett wrote:

> On Wed, Feb 17, 2016 at 07:51:28PM +0100, Tobias Ulmer wrote:
>>
>> The only thing wrong with lpd is nobody tedu'ed it yet.
>>
>> No really, it is outdated beyond rescue. If you want to write a new
>> print job queueing system, sure, have fun. Maybe you can come up with
>> a 'cups' that doesn't suck?
>>
>
> Oh, I agree, it's seriously ready for display in the computer museum.
> But it does work in a limited fashion.
> I want something in base that handles printing.
> I need a project that isn't at the skill level of pouring over code
> and finding subtle errors. Way over my head to do that.
> Wow all of you developers are good at that!
>
> I understand that this is going to take a long time to accomplish.
> It will need to fill a large group of users needs or it won't be
> kept in base.

In the "For what it's worth" department:

Here at RPI we use the BSD-based lpr/lpd to run our print servers.  Our
print servers run a few hundred printers for campus, including five pretty
modern plotters which see heavy use at the end of each semester.  We go
through a mile or two of plotter paper every semester.  I'm the guy who
implemented most of our printing system.

To touch upon the original subject of this thread, we have not used any
line printers at RPI in at least 20 years.  When we did have them, they
were connected to IBM mainframes, not unix print servers.

I use what is basically FreeBSD's lpr/lpd running on a version of solaris
from the days back when Sun was still in business.  I've done enough work
on lpr/lpd that I worked my way into being the maintainer of lpr/lpd for
FreeBSD (although I have not done much work on it lately).  I made many
improvements to FreeBSD's lpr/lpd from 2000 to about 2006.  In some cases
I pulled in changes from OpenBSD's lpr/lpd.  And the versions of lpr/lpd
that I use on our print servers at RPI have some additional improvements
that I keep meaning to move over to FreeBSD, however the source for RPI's
lpr/lpd is also quite a mess.  I need to clean it up and make sense of
the changes.  I do not know how many of my FreeBSD changes have made it
over to OpenBSD's lpr/lpd.

Over the years I have tried out both CUPS and LPRng, and both times I
ran into enough pain that I've stuck with plain BSD-based lpr/lpd.

There is much room for improvement in BSD's lpr/lpd, but there's also a
lot of good knowledge which is not obvious and not documented.  My main
example is that almost every non-BSD alternative will send a job's
control-file before sending the data file(s).  If you are sending to a
busy print server it is actually important to send the data-files first,
but the reason *why* you want to do that is not documented anywhere.
It's only when you run a busy print server that you realize why some
things were done the way they were done.

I've been keeping an eye on some of your recent changes to OpenBSD, but
I haven't had the time to look them over as much as I would like to.
That's been the story of my life for the last 4-5 years...

--
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Bennett]

On Fri, Feb 19, 2016 at 06:52:43PM +0200, li...@wrant.com wrote:
> 
> Maybe you should pull your head out of the sand (asshole) and understand
> why you can not find relevant information.  You're not reading man
> pages, but people say.

That previous request was not to include trolling me privately.
I have the code open in front of me and I have read the man pages
repeatedly.

I find most of your posts offensive, but occasionally you do say
something useful. So I might like to force you to go away, but in the
end that would be stupid. Sometimes the most annoying people do have
that precious answer nobody else can see.

Now go buy/borrow/pull out of the attic some printer and try to make it
work with our lpd/lpr system and report back success, partial success or
failure. Include the connection method
(serial/parallel/USB/network/wifi, etc).
Send your printcap file.
Did you use any input filters? What language(s) does your printer speak?
Does lpc,lpq,lprm work with the printjobs?

Of course test to see if it will print a banner page also.

You could format your response as a manual page instead of people say,
if you really think that matters.

Chris Bennett

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Roderick]

On Fri, 19 Feb 2016, li...@wrant.com wrote:


Well, let me say my opinion.


Why ?!


I think, you missed the context of my two postings of yesterday.

I do not see any problem with lpr/lpd, the only reason given here to
change it is:




* lpd(8)/lpc(8)/lpr(1) is very old and suffering from bitrot.
<<

(https://marc.info/?l=openbsd-misc=145376186932234=2)


People had to defend lpd/lpr supporting their printer after the 
following question was stated:





Is anyone still using a printer connected to a serial port or is that now
removable?
<<

(https://marc.info/?l=openbsd-misc=145377943204026=2)


Later, we read:




I do see that lpc, lpq, lprm are dinosaurs and have to be made extinct
and replaced with something more functional with more information output
and better capabilities.
<<

(https://marc.info/?l=openbsd-misc=145573157323762=2)


Then came the first question that I answered:




Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
lpr/lpd/lprm from base? Maybe I'm the only one?
<<

(https://marc.info/?l=openbsd-misc=145577346702071=2)


And then I reduced ad absurdum the following argument against lpd/lpr:




No really, it [lpd/lpr] is outdated beyond rescue. If you want to write a new
print job queueing system, sure, have fun. Maybe you can come up with a
'cups' that doesn't suck?
<<

Again: if lpd is outdated without rescue and must be replaced with a
non sucking cups, then bsd/unix is also outdated without rescue and
must be replaced with a new, non sucking operating system.

Under this logic, "lpd/lpr" may be deleted from base, and also obsolete
programs like "mt" that no one use (I did use it not long ago).

But inspite of the bad argument, the alternative is indeed to offer
a completely new (perhaps non standard?) print job queueing system 
to make some people happy (and leave lpd/lpr where it is).


About a month ago I tried to install "xscanimage" in OpenBSD 5.8
from the package collections, without success. This is the explanation 
given in CVS:





Remove sane-frontends; upstream hasn't put out a new release in >8 years
and Xsane is the de-facto SANE frontend nowadays.
<<

(http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/sane-frontends/)

Of course, the bloated Xsane is not a replacement of the meager xscanimage.

In spite of all irony in my postings of yesterday, I do believe that 
plan9 is, at least in some concepts, superior to Unix/BSD, but it is not a 
standard.


There are good reasons to use a standard like Unix/BSD, and that is one of the
reasons I use OpenBSD, but there may be also reasons to use something else,
for example an innovative, experimental system like Plan9 or a comercial
real time system. All depends on what you want to do with the computer, 
and security in the internet is not necessary a priority: I moved from 
FreeBSD to OpenBSD only because the wlan driver in OpenBSD seems to work 
better.


Rodrigo.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[lists]

Thu, 18 Feb 2016 20:38:38 + (GMT) Roderick 
> Well, let me say my opinion.

Why !?

> I think BSD and Unix is also "outdated beyond rescue", but we are
^^
This means "following standards and reliably implementing Unix core".

Same strong words can also be slammed to fire and wheel, and you put
your dearest into this daily.

> The inventors of Unix recognized that Unix is obsolete and
> developed Plan9.

To use it for novel ideas without breaking standards and well
established operating system that is Unix.

> Maybe he can come up with a new operating system that doesn't suck?

More fragmentation does not help.  Code quality and skillful art do.

Notice how consumerism is mostly tar-pitting consumer periphery devices?

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Bennett]

On Fri, Feb 19, 2016 at 05:47:42PM +0200, li...@wrant.com wrote:
> Thu, 18 Feb 2016 20:38:38 + (GMT) Roderick 
> > Well, let me say my opinion.
> 
> Why !?
> 
> > I think BSD and Unix is also "outdated beyond rescue", but we are
> ^^
> This means "following standards and reliably implementing Unix core".
> 
> Same strong words can also be slammed to fire and wheel, and you put
> your dearest into this daily.
> 
> > The inventors of Unix recognized that Unix is obsolete and
> > developed Plan9.
> 
> To use it for novel ideas without breaking standards and well
> established operating system that is Unix.
> 
> > Maybe he can come up with a new operating system that doesn't suck?
> 
> More fragmentation does not help.  Code quality and skillful art do.
> 
> Notice how consumerism is mostly tar-pitting consumer periphery devices?
> 

Perhaps the two of you did not read the subject line of this thread?

Why don't hru...@gmail.com and li...@wrant.com have a lovely and
exciting chat off of my lpd/lpr thread?

I just spent my time going over all of the relevant emails and pulling
out the useful information into a file using vim, noting who sent the
emails so I could ask them for any more useful info they have if I have
questions in the future. Others have been very helpful to me so far.
This is not helpful or wanted.
Bye
Chris Bennett

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Stuart Henderson]

On 2016-02-18, gwes  wrote:
> CUPS installs AVAHI. That is a security risk - it attempts
> to change DNS lookups, etc.

Can you expand on "it attempts to change DNS lookups"? Perhaps on OS with
nsswitch via nss-mdns, but I don't see any way of getting it to do this on
OpenBSD, even if you wanted to.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Bennett]

On Thu, Feb 18, 2016 at 06:58:07PM -0700, Andy Bradford wrote:
> Thus said Chris Cappuccio on Thu, 18 Feb 2016 17:09:38 -0800:
> 
> > aren't there  plenty of simple  pre-processor scripts that  people are
> > using  with lp  to  turn whatever  into some  output  for simple  dumb
> > printers? CUPS is so annoying and stupid, it's not even funny
> 
> Perhaps apsfilter?
> 
> Andy

I have found that apsfilter has a brutally slow filter.
Works, but go get coffee for a simple printjob.

Chris

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Andy Bradford]

Thus said Chris Cappuccio on Thu, 18 Feb 2016 17:09:38 -0800:

> aren't there  plenty of simple  pre-processor scripts that  people are
> using  with lp  to  turn whatever  into some  output  for simple  dumb
> printers? CUPS is so annoying and stupid, it's not even funny

Perhaps apsfilter?

Andy
--
TAI64 timestamp: 400056c676d2

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Cappuccio]

gwes [g...@oat.com] wrote:
> 
> I just created and will submit to ports a version
> of ghostscript which doesn't pull in cups - it
> turns out the configuration has a switch for that case.
> 

aren't there plenty of simple pre-processor scripts that people
are using with lp to turn whatever into some output for simple
dumb printers? CUPS is so annoying and stupid, it's not even
funny

christopher

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[gwes]

On 02/18/2016 16:33, Chris Bennett wrote:

On Thu, Feb 18, 2016 at 04:10:06PM -0500, gwes wrote:
.
They don't do dynamic autoconfiguration.
In an industrial environment autoconfiguration can be very bad.
(examples like directing confidential output somewhere unexpected)

I haven't looked at the code from LPRng, but it provides options to use
a pool of printers for certain jobs to be sent to.


I think that case is rare but should be considered.


The only function I can think of that lpr doesn't have is
the capability to request a forms change and wait until
it has been done. That could be an entirely separate subsystem
invoked by lpr.

When you say forms change, are you talking about paper size/type
changing or something else?

Forms change can mean size, material, preprinted forms, ribbon,
type chain, etc.. pretty much anything beyond "change input tray".

One more function that I can think of is scheduled access
dept. A from 4:00am to 11:00am, dept. B from 11:01 to 14:00, etc.

I've been in many places where many wifi printers were wide open and in
several adjacent businesses.


Ouch!

The case for retiring lpr et al really depends on your use model.
One size fits all could be difficult.
 How much access and use control?
 How much initial setup?
 How much per-user setup?
 How many printers and per-printer setup?

As you mention, wifi printers are common. Without access control,
they short-circuit any administration. Then anyone with the
password can do anything. A piece of javascript and a browser
would give users as much control as is possible.

So... wired printers - again, if they are open on the net,
access control is difficult or impossible. A very few
I've heard of have per-IP access control.

Either of these two cases really are "submit" and "monitor
for done". The only central administration that's possible
is to recommend which printer someone is to use.

IMnotsoHO, lpr works fine for these cases. The user
selects which printer to use and then queues the job.

Automatic printer discovery could be a boon or a
disaster. Better reporting of printer errors
and daemons not running and easy restart would be good.

Wired printers on a host have two cases.

The simple subcase: printer is a general resource
that happens to be connected to a machine that's
really someone's workstation, etc. Here, the biggest
problem is setting up a server daemon.

I think the previous cover 90% of use.
What improvements do these categories need?

Once you have multiple printers, things get complex.
It's probably one for businesses. Is there
any IT staff? The VAX/VMS print spooler probably has a lot of
the controls for this case. It assumes an operator.

My take: the interface to lpr, lpd, etc could be
cleaned up. For most uses, the functionality is adequate.
Adding a "find a printer" program would help.

The complex case, well, how much work do you
want to put in defining requirements?

None of this, of course, covers running out of paper
when all the stores are closed.

Geoff Steckel

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Bennett]

On Thu, Feb 18, 2016 at 04:10:06PM -0500, gwes wrote:
> I'm not sure what measure of "better" you're trying to apply.
> 
> lpr et al. don't have a GUI. One could be wrapped around them.
> 

I personally wouldn't want that. Others have said that cups provides
nice information for printers in other applications.

> They don't do dynamic autoconfiguration.
> In an industrial environment autoconfiguration can be very bad.
> (examples like directing confidential output somewhere unexpected)
>

I haven't looked at the code from LPRng, but it provides options to use
a pool of printers for certain jobs to be sent to.

> I worked for a company that ran as many IBM 1403 printers as
> they could buy. Line printers are very simple to run.
> They don't need elaborate output filters.
> 
> The only function I can think of that lpr doesn't have is
> the capability to request a forms change and wait until
> it has been done. That could be an entirely separate subsystem
> invoked by lpr.

When you say forms change, are you talking about paper size/type
changing or something else?

> 
> A laptop floating in many places could use something
> complex like autoconfigure. Again, that could be wrapped
> around lpr et al.

I've been in many places where many wifi printers were wide open and in
several adjacent businesses.

> 
> Geoff Steckel

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[gwes]

On 02/17/2016 12:49, Chris Bennett wrote:

After reading up on printers in use, I discovered that there is
significant use of line printers due to their very low cost of
consumables, production of a very long lasting output, unlike
laser/thermal/inkjet printers and high reliability.

Is anyone using these in a high volume output setting (not like a
restaurant or other low volume)?

If not using, but would like to, what is broken, missing or otherwise
wrong with our lpd/lpr system?

I do see that lpc, lpq, lprm are dinosaurs and have to be made extinct
and replaced with something more functional with more information output
and better capabilities.

Thanks,
Chris Bennett



I'm not sure what measure of "better" you're trying to apply.

lpr et al. don't have a GUI. One could be wrapped around them.

They don't do dynamic autoconfiguration.
In an industrial environment autoconfiguration can be very bad.
(examples like directing confidential output somewhere unexpected)

I worked for a company that ran as many IBM 1403 printers as
they could buy. Line printers are very simple to run.
They don't need elaborate output filters.

The only function I can think of that lpr doesn't have is
the capability to request a forms change and wait until
it has been done. That could be an entirely separate subsystem
invoked by lpr.

A laptop floating in many places could use something
complex like autoconfigure. Again, that could be wrapped
around lpr et al.

Geoff Steckel

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[gwes]

On 02/17/2016 12:49, Chris Bennett wrote:

After reading up on printers in use, I discovered that there is
significant use of line printers due to their very low cost of
consumables, production of a very long lasting output, unlike
laser/thermal/inkjet printers and high reliability.

Is anyone using these in a high volume output setting (not like a
restaurant or other low volume)?

If not using, but would like to, what is broken, missing or otherwise
wrong with our lpd/lpr system?

I do see that lpc, lpq, lprm are dinosaurs and have to be made extinct
and replaced with something more functional with more information output
and better capabilities.

Thanks,
Chris Bennett


CUPS installs AVAHI. That is a security risk - it attempts
to change DNS lookups, etc.

Any package which pulls in something as disastrous as avahi
isn't welcome here.

lpr et al are primitive. They work fine for me and have
worked fine at all the places I worked except one
which was Linux-centric.

I just created and will submit to ports a version
of ghostscript which doesn't pull in cups - it
turns out the configuration has a switch for that case.

Geoff Steckel

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Roderick]

On Wed, 17 Feb 2016, Tobias Ulmer wrote:


No really, it is outdated beyond rescue. If you want to write a new
print job queueing system, sure, have fun. Maybe you can come up with a
'cups' that doesn't suck?


Well, let me say my opinion.

I think BSD and Unix is also "outdated beyond rescue", but we are
really not better than Windoze Users and still use it. Inertia. Custom.
The inventors of Unix recognized that Unix is obsolete and
developed Plan9. Also the developers of Linux distributions recognize
that they dont need unix, because in Linux distributions, as in MacOS,
you dont recognize Unix in the surface, not only "lpr", but also
"cd", "ls", "mv", "cp", etc are not necessary for normal Linux and
MacOS users.

Maybe he can come up with a new operating system that doesn't suck?

Rodrigo.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Roderich]

On Thu, 17 Feb 2016, Andy Bradford wrote:


Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
lpr/lpd/lprm from base? Maybe I'm the only one?


I never used something else.

And if I install a package that bloats my system with cups as dependency,
I delete immediatly the package and its dependencies.

Perhaps needs lpd some little, well thought improvements, as also
many other tools, but I think, in many cases the best to do is to
do nothing.

Thank you very much for asking.

Rodrigo.

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[patrick keshishian]

On 2/17/16, Andy Bradford  wrote:
> Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
> lpr/lpd/lprm from base? Maybe I'm the only one?

yep. been using it for many years with many different HP and Brother
network printers.

--patrick

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Marc Peters]

Am 02/18/16 um 06:28 schrieb Andy Bradford:
> 
> Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
> lpr/lpd/lprm from base? Maybe I'm the only one?
> 
> Thanks,
> 
> Andy
> 

I've connected a Kyocera FS-920 to my router and all hosts (*bsd, mac,
win) do their printing on it (just b needed). Done the configuration
years ago with the help of apsfilter:

lp|PS;r=600x600;q=medium;c=gray;p=a4;m=auto:\
:lp=/dev/ulpt0:\
:if=/etc/apsfilter/basedir/bin/apsfilter:\
:sd=/var/spool/lpd/lp:\
:lf=/var/spool/lpd/lp/log:\
:af=/var/spool/lpd/lp/acct:\
:mx#0:\
:sh:

lpd is not very chatty when it comes to errors, though.

Marc

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Jeremy Evans]

On Wed, Feb 17, 2016 at 9:28 PM, Andy Bradford 
wrote:

> Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
> lpr/lpd/lprm from base? Maybe I'm the only one?


I've been using the lp* tools for many years for personal printing, first
using a PostScript HP 4050dn and now using a Samsung M2830DW (with a filter
from cups-filters).

Jeremy

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Andy Bradford]

Thus said Tobias Ulmer on Wed, 17 Feb 2016 19:51:28 +0100:

> No really, it is outdated beyond rescue.

But  it does  work  (at  least in  some  configurations).  To enable  my
PostScript  printers,  all  I  have  to  do is  add  a  single  line  to
/etc/printcap... well, maybe 2 lines.

printer:\
:lp=:rm=printer:rp=lp:sd=/var/spool/output/printer:\
:lf=/var/log/lpd-errs:sh:

That's it. Can  it be more simple?  CUPs is a nightmare,  however it too
works if one wants to spend the time with it.

For non-PostScript  printers, it would  be nice to  be able to  just use
:if:  in  the  printcap  (which  I  do  use  successfully  with  another
non-PostScript printer):

:if=/var/spool/output/printer/filter

Of course,  this would require the  ability to figure out  what kinds of
things need to go  into the filter. I suppose this is  one of the things
that CUPs tries to solve but without the simplicity of :if:

Anyway,  just  some  musings.  Is  there anyone  else  out  there  using
lpr/lpd/lprm from base? Maybe I'm the only one?

Thanks,

Andy
-- 
TAI64 timestamp: 400056c556b3

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Tobias Ulmer]

On Wed, Feb 17, 2016 at 11:49:30AM -0600, Chris Bennett wrote:
> After reading up on printers in use, I discovered that there is
> significant use of line printers due to their very low cost of
> consumables, production of a very long lasting output, unlike
> laser/thermal/inkjet printers and high reliability.
> 
> Is anyone using these in a high volume output setting (not like a
> restaurant or other low volume)?
> 
> If not using, but would like to, what is broken, missing or otherwise
> wrong with our lpd/lpr system?

The only thing wrong with lpd is nobody tedu'ed it yet.

No really, it is outdated beyond rescue. If you want to write a new
print job queueing system, sure, have fun. Maybe you can come up with a
'cups' that doesn't suck?

> 
> I do see that lpc, lpq, lprm are dinosaurs and have to be made extinct
> and replaced with something more functional with more information output
> and better capabilities.


> 
> Thanks,
> Chris Bennett

Re: Industrial use of line printers, does/would your company/organization use them with our lpd?

[Chris Bennett]

On Wed, Feb 17, 2016 at 07:51:28PM +0100, Tobias Ulmer wrote:
> 
> The only thing wrong with lpd is nobody tedu'ed it yet.
> 
> No really, it is outdated beyond rescue. If you want to write a new
> print job queueing system, sure, have fun. Maybe you can come up with a
> 'cups' that doesn't suck?
> 

Oh, I agree, it's seriously ready for display in the computer museum.
But it does work in a limited fashion.
I want something in base that handles printing.
I need a project that isn't at the skill level of pouring over code and
finding subtle errors. Way over my head to do that.
Wow all of you developers are good at that!

I understand that this is going to take a long time to accomplish.
It will need to fill a large group of users needs or it won't be kept in
base.

Chris