Date: Sat, 18 Sep 2010 12:41:53 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer Message-ID: <201009181741.o8IHfrJq028360@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
> Date: Sat, 18 Sep 2010 08:50:30 -0400
> From: Jerry <freebsd.user@seibercom.net>
> To: FreeBSD <freebsd-questions@freebsd.org>
> Subject: Re: The nightmarish problem of installing a printer
>
> You keep insisting that it is complicated; yet, you fail to
> specifically state what it is that you are failing to comprehend. Your
> "bloat" comment makes no sense at all. What you consider "bloat"
> another user might well consider essential. Should we deny them in order
> to satisfy you?
CUPS is an overly complex attempt t provide a 'general case' solution a
problem that is, in fact, *INSOLVABLE* in the classical UNIX environment.
CUPS supports a -very- small subset of that 'general case' *beyond* that
which is supported by the traditional, and =far simpler= mechanisms.`o
And, CUPS, itself, addresses -only- one half of te underlying issue, to
start with.
The _one_ thing that CUPS does have going for it is that it allows an
application -- one which is *WRITTEN*AROUND* CUPS capabilities, to output
a 'partial' print file, and have CUPS insert the missing parts. "Nice
idea', usable only in "CUPS-aware" apps. Needless to say, there are very
few of those. So this is a 'benefit' that is of 'no benefit' to most users.
FACT: to print anything more complex than "plain ASCII' one has to have
a methodology of conveying 'formatting' information (typeface, point-size,
positioning, orientation, etc.,etc., ad nauseum) to the output device.
IN A MANNER IN WHICH THAT DEVICE UNDERSTANDS. To do -that- requires that
the software -producing- the data stream _know_ what the printer is
capable of, and how to tell it what to do. CUPS does *NOT* include any
means to get that information _to_ the output producing application. Hence
it is only 'half an answer" _at_best_. It attempts to 'work around' this
limitation in a half-assed way, by utilizing additional _external_ tools
to convert from a 'standard' means of conveying formatting information
(de jure standards of Postscript, and .PDF, and de facto standard PCL 5)
into the proprietary gobbledygook that a few specific models of printer
require. Don't have one of that handful of devices that (a) don't speak
a standard protocol ,and (b) do speak something that an 'extension' that
you _do_ have can generate, and you *still* can't print to that printer.
UNLESS it does speak a standard protocol -- in which case you don't need
CUPS at all.
Virtually _every_ application for the UNIX world outputs in one of three
formats: "Plain ASCII", "PostScript / PDF", or "HP PCL"(PCL5).
{Bleep}ing "WinPrinters" can't even print ASCII text without it having
been 'translated' by the driver available *only* from the manufacturer,
let alone being able to deal with either of the 'smarter' page formats.
If you want to play in the Unix world, having a printer that is capable
of PLAIN TEXT (ASCII) output is an absolute necessity. If you want
'formatted' output, it is necessary to have 'something' that understands
the protocol that is output by whatever you use to compose in. This can
be a device that natively "speaks the language" _or_ something for which
a 'translator" service exists. In -either- of those situations the
traditional 'lpr/lpd' print spooler is "adequate" for the task.
> What standards? Some arbitrary protocol that you or some other
> unofficial entity has determined to be the ONLY ACCEPTABLE protocol. It
> could very well be said that FreeBSD, and perhaps others, are failing
> to implement the commonly used protocols presently in effect by
> printer manufacturers. It is THEIR product. They have an ABSOLUTE right
> to create and distribute THEIR product as THEY see fit.
Yup. and if *THEY* choose to market a product that is _unusable_ by part
of their potential market, _that_too_ is their 'right'. It's nobody's
_fault_ that a product *designed* exclusively with the needs of -one-
market segment in mind is 'unusable' in a different market segment. it
_is_, however a 'reality' with which those in that 'different' market
segment must (a) be aware of, and (b) "deal with", as a part of deciding
to be _in_ that different market segment.
> The constant and repetitious rantings that manufacturers are failing to
> follow some arbitrary, self proclaimed "standard" is wearing thin.
You, Sir, fit the categorization of "he who knoweth not, and knoweth not
that he knoweth not", in the sense of the traditional Middle Eastern proverb.
(those unfamiliar with the saying are encouraged to Google the phrase.)
The issue is -not- whether the manufacturer 'follows a standard', but
whether or not the device uses a *PUBLISHED* communications protocol.
IF a device uses a "proprietary" communications protocol, one can do
the same thing *IF* ( AND *ONLY* *IF*) one has the specifications of
that protocol to work wit. There are disadvantages to writing to a
proprietary protocol -- you can talk only to things that speak that
particular language, where a 'standard' protocol allows one to talk
to any device that speaks the standard language.
LASTLY, if a device uses an *UNPUBLISHED* protocol, you are pretty much
out-of-luck trying to generate data to it _yourself_. You have to "buy
something' from somebody who -does_ know how to communicate with the
device in question. That assumes that there _is_ "somebody" who offers
such a tHing that works in the environment you need it to work in.
_All_ the so-called 'standards' *are* published, so anybody can write
stuff that output bit-streams in compliance with that standard, and
have a reasonable expectation that it will 'work' on a device that
claims to be compliant with that standard. Some have been 'formalized'
by a so-called 'standards organization', *MOST* are just "something that
the developer published for others to use", and a sufficient number of
'others' *DID*USE*IT*. The advantages to the 'community' of producing
a device that is 'compatible' with other manufacturers is immense.
Consider what would happen if every computer manufacturer used is _own_
type of connector and interface logic for their 'XSB" implementation of
"something similar to USB" -- you'd only be able to buy devices that
worked with your machine from your manufacturer. No carrying a XSB stick
from home to work, if they were 'different' kinds of machines.
> Perhaps if the FreeBSD team decided to jump on the band wagon as
> opposed to trying to reinvent the wheel, the ease of integrating
> devices into the system would be simplified and thereby enhance the
> OS's standing and acceptance.
There is *NO* fscking 'bandwagon' to "jump onto", with regard to supporting
the things various manufacturers do with low-end printers.
There are 'real' printers, that speak "some" form of a _published_
protocol, and can be used with *ANY* device that outputs data in conformance
with that *PUBLISHED* protocol,....
And then there are "WinPrinters", which use an _unpublished_ protocol
known *ONLY* to te manufacturer, and, as a result, work *ONLY* when they
are 'fed' data by a driver WRITTEN BY THE MANUFACTURER. And the -only-
drivers that that manufacturer provides are for MS-Windows. They can
make 'really inexpensive' printers 'for Windows', but they are virtually
useless _outside_ of that environment because of a LACK OF MANUFACTURER
SUPPORT. The manufacturer doesn't supply drivers for any other O/s, NOR
do they the provide the protocol information
If the manufacturer _does_not_publish_ the communications protocol (WHATEVER
it is) that a given printer uses, *and* the manufacturer does -not- provide
a 'device' driver for the operating system one is using, there is, for all
=practical= purposes, *NOTHING* that anybody can do about it.
Many/most 'winprinters' are relatively dumb raster imaging devices, with
the rasterization done _in_the_host_computer_ device-driver. *UNFORTUNATELY*
the raster data is usually _compressed_ before being sent to the printer.
using 'whatever' compression and coding scheme the manufacturer feels like
implementing. look at the specs for 'Group III' fax transmission to get an
idea of the 'games' played. RLL coding, with variable-length tokens as
stand-ins for other bit-patterns. Without access to the 'known' translation-
table of bit-patterns, you are essentially out-of-luck trying to reverse-
engineer what that data-stream represents -- since the translation-table
is *NOT* transmitted in the data stream, and without it you can't tell where
one symbol ends and the next begins. Beyond -that-, there is the issue of
any (also _undocumented_) "framing" that the manufacturer may include, to
allow detection of transmission errors, re-send requests, etc, or simply
to facilitate "ack/nak" flow control. Let alone any 'start-of-job'
initialization and/or end-of-job clean-up stuff. Parameters in which
may _entirely_ change the way the 'body data' is interpreted, just to add
to the confusion.
To "reverse engineer' the communications protocol used by any _single_ model
of 'WinPrinter' (which probably sells for under $100) is a "project" that
takes well in excess of US$50,000 of professional talent. *IF* the manu-
facurer published the protocol involved, the effort is probably only in the
'hundreds of dollars' range. If it uses a 'standard' protocol, the added
cost for a driver is probably _zero_, because it already exists.
I've *DONE* major reverse-engineering jobs, I -know- what's involved.
It's not particularly simple/easy when you have _uncompressed_ data to
work with. Add an 'unknown' form of compression, and you're eyebrows
deep in a swamp known as advanced crypto-analysis. If you're _LUCKY_
the printer is microprocessor-controlled *AND* the ROM programming is
readable. then it is 'merely' a matter of decoding what the ROM program
does. If the logic is in read-protected PLA, or, worse, ASICs, you're SOL.
It's really *REALLY* difficult to find the process to 'decode' something
when you (a) don't have the 'cleartext', and (b) can't recognize _a_ clear-
text when you encounter it.
> They again, bitching, complaining and
> blaming others is easier, and unfortunately, the common norm in today's
> society. "Never do for yourself, what you can blame on others" has
> become the new battle call.
FACT: *MANUFACTURERS* chose to go for a 'subset' of the market, where they
could offer 'especially low prices' by tailoring the device for THAT MARKET
*ONLY*. They have concluded that the 'additional profits' to be made from
selling to a 'larger' marketplace are _not_worth_the_cost_ of the additional
efforts that it takes to play in tat larger marketplace -- *even*if* that
'cost' is simply the release of the communication protocol specifications.
It *IS* their prerogative, and right, to do so.
FACT: UNIX, FreeBSD, and any other environment were GhostScript runs,
support an *AMAZINGLY*LARGE* number of 'undocumented' printers, when you
consider the fact that their communications protocols _are_ undocumented
by the manufacturer. It's true that those printers constitute a miniscule
share of the total number of *UNDOCUMENTED* printers that people might
like to use, and that the ones that -have- been 'reverse engineered' art
not the newest models on te market, but, reference to the famed 'dancing
bear', the surprising thing is not 'how many' there are, but that there _are_
any such printers supported, *AT*ALL*.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009181741.o8IHfrJq028360>