The nightmarish problem of installing a printer

[Robert Bonomi]

> From owner-freebsd-questions at freebsd.org  Wed Sep 22 12:25:37 2010
> Date: Wed, 22 Sep 2010 10:27:05 -0700
> From: David Brodbeck <gull at gull.us>
> To: freebsd-questions at freebsd.org
> Subject: Re: The nightmarish problem of installing a printer
>
> On Tue, Sep 21, 2010 at 5:24 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> w=
> rote:
> > A) *THEY* developed the interface specifications. They license printer
> > manufacurers to build to it. =A0 They _would_ obejct if somebody used
> > their technology to compete against them.
> >
> > B) As it is, to _use_ one of those printers, you *HAVE*TO*BY* a MS O/S.
> > =A0 if one could use those printers -without- a MS O/S, that is a
> > =A0 'provable' loss in MS O/S sales -- one sales loss for -each- non-MS
> > =A0 system that has such a printer attached.
>
> If this were true, and there really were a big conspiracy on
> Microsoft's part to make manufacturers only support Windows, then you
> wouldn't see cheap printers that support both Windows and MacOS X.  In
> reality, such printers are pretty easy to find.

NICE STRAWMAN.  But that was -not- the point of the discussion that I
was addressing.  The QUESTION ASKED was 'why would Microsoft object if
somebody else implemented -their- printer-driver technology.  And the
answer to -that- question -is- found in 'simple economics' -- if somebody
did so, it would represent a 'potential loss' in MS operating system
sales.

The potential threat of MS taking issue (and possible legal action) against
someone who develops a usable 'windows clone' printing subsystem, is not
'in iteself' a 'deal breaker' that preents it from happening.  It is mrerely
"more nails" in the lid of the coffin.  Eliminate the other barriers and you
still have that one to worry about.  eliminate -only- it, and the coffin
lid is -still- nailed down.

MS knows better than to try to dictate what markets printer manufacturers
can build for.  if a manufacturer wants to develop for a _competing_ market
using _competing_ technology, "no problem".  If a manufacturer wanted to
develop for a competing (with oter microsoft produts -- i.e. were every 
sale of the 'competing' product is a potential 'lost sale' of a MS product)
market, *using*MICROSOFT's*tecnology,  the "big problem".  

NOTE WELL I did -not- claim there is any 'conspiracy'  on MS's part to
force printer manuracturers into only supporting window.  There isn't.

Printer manufacturers _chose_ to roll out devices that work only when
coupled with host-based software that they provie for Windows, and 
Windows *ONLY*.  They have, probably rightly, concluded that the -cost-
of providing drivers for other environments (or even the cost of 
making the specifications avaialable) is more than the profits that 
that (relatively speaking) small number of additional sales would 
bring in.  They build for their 'primary market', and if cost-minimization
for -that- market means that the device is 'unusable' in a niche market
that would bring in minimal revenues, they =don't=care=.  Regardless
of how 'inconvenient' it is for the users _in_ that niche 'market.

There's also another thing going on with regard to the low-end inkjet
printers.

What does it tell you when you can buy a _new_  printer, _with_ a set
of ink cartridge for roughly 50% more than the cost of a set of replacement
cartriges?  Hint, it's the same strategy that King Gilette used to sell 
safety razors.

The 'total cost of ownership' of an inkjet printer is _obscene_ when figured
on a per-page basis, with highly intermittant use. Used 'reglarly but lightly'
the cost of ownership is merely riciculously high. But the customers _don't_
tink about te purchases that way.  If the purchase price is rock bottom, "who
cares" about the 'operating cost' applies. unless they're using it regularly
enough that they see ink as an expence at least monthly.

"Guess why" printer manufactures now put 'smart chips' _in_ the cartridge so 
that when the page count has been reached, it _stops_working even if there 
are 'consumables' still in the package.  Aw, shucks, you can't _re-fill_
that cartridge with cheap ink. "Guess who" is crying all theway to the banke
over -that- little problem. <wry grin>

Summary: the obstacles to developing a 'shim'/'wrapper' around a Windows
printer driver to allow te use of cheap 'Winprinters' in a Unix environment.

1) the 'appication side' interface it would  is incompatbile with  *every*
   existing Unix application that produces print output.

2) providing a lowlevel /'translator' to map between the output calls that
   existant print-producing packages usa and the windows environment 
   'expects'  is an enitre _additional_ undertaking that would have to be
   done.

3) (2) _cannot_ be done 'perfectly' there are concepts on the Unix side
   for which there are -no- windows equivalents.  And vice-versa.

4) WINDOWS applications are the only things that directly produce output
   'compatible' with this new printing system.
    (a) absent the translator discueesed in (2), the a unix app has to be
        re-wrritten to take advantage of the 'new' printer.
    (b) a 'windows' app already knows how to talk to this kind of printer
	but tht's no -help since te _rest_ of the app still needs a 
	windows interface.

5) you'r tryin to catch a moving target -- witout a *LOT* of co-ordinated,
   directed and team-oriented expertise, the target will change faster than
   the solution beiing built.   it doesn't do -anybody- any good to prouce
   a technical tour-de-force, if by the time it's completed nobody is selling
   printers compatible with that 'obselete' tecnology.

6) hang a "Winprinter" off a unix box _wih_ a shim wrapper, and yo've
   got a 'solution looking for a problem, because _nothing_ on the 
   applications side can talk to it, see 2),3) and 4) above.

7) you -do- run a risk of legal action from Microsoft. unless you pay to
   license the interface technology.  There are software patents and 'trade
   secrets' (divulged only non-disclosure agreements) involved.


Colllectively, the above reasons constitute an overwelming rational for
-not- tackling such a project -- those with the required skill-sets are
well aware how large -each- of those mountains is, and have chosen -not-
to expend the effort.

If there is someone out there who believes it _can_ be done, with a rational
expenditure of time and effort, They are strongly encouraged to GO DO IT.

Those who merely want to "bitch and moan" about ow 'other people' aren't
'moving fast enough' on their pet issue of the day  might want to think
about what *they* could do to 'make it happen'.  For starters, it is a
simple fact that any sizable project gets done _far_faster_ with 'funding'
than it does *without* it.  Want it done 'sooner'?  Start a fund-raising
project among like-minded users.  Six figures (left of the decimal point,
_not_ counting leading zeroes:) would be a good starting point.  Manage
*that* and you'll be the "E.F. Hutton" (c.f. the 80', 90's add campaign)
of the unix world.  otherwise.....

Those who "don't know what they don't know" about the subject, because tey
do _NOT_ have the skills to tackle it themselves, are cordially requested
to STFU, and go _learn_ what they need to know to tackle it.