Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2012 14:14:47 +0100
From:      Polytropon <freebsd@edvax.de>
To:        FreeBSD <freebsd-questions@freebsd.org>
Subject:   Re: MFC 7840W under CUPS
Message-ID:  <20120217141447.b99dda33.freebsd@edvax.de>
In-Reply-To: <20120212100038.412369e7@scorpio>
References:  <fc3bb6c7b4bf770606b95d2514e8863a@mail.a4a.de> <20120211231729.d4ad2f8d.freebsd@edvax.de> <20120212083327.0a3b5c52@scorpio> <4F37CBC2.7060609@herveybayaustralia.com.au> <20120212100038.412369e7@scorpio>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Feb 2012 10:00:38 -0500, Jerry wrote:
> It appears that "ps" is no-longer the format of choice but is being
> replaced by PDF, a format that is natively supported by many printers.

Jerry, I wanted to point out that PS still seems to be the
format that _applications_ use as output format for printing.
Even though especially office applications (such as Abiword
or LibreOffice) have a built-in PDF file generator, the printing
output that is sent to the printing subsystem (lpr, CUPS, whatever)
is in PS format and gets converted to what the printer needs
by the proper printer filter ("driver").

The "print to file" output method typically creates PS, at
least on UNIX, Linux, MacOS X and other operating system
families.

If printers would natively support PDF data instead of unknown
arbitrary commands to move the printing head - things would be
MUCH LESS complicated on the OS's side. Data just needs to be
generated in PDF natively, or converted from PS to PDF (simple
task) by the printer filter, and then just sent to a specific
network address (just as netcat could do). That would nearly
eliminate the need for printer drivers I think. The only thing
that comes to my mind is... how does it handle duplexing and
other printer-HARDWARE specific things? Can they also be "coded"
in a PDF file?

Really, I like the approach of having PDF as a universal "printer
language" (even though it's not 100% safe from a security point
of view, but that doesn't matter on the home consumer market
anyway). It would remove any need complicated things like (in
my opinion) the CUPS configuration. You just need to enter the
IP of the printer - done; and it doesn't even matter of this
is a wired or wireless connection! Maybe even lowest-end USB
devices can accept a PDF "data stream"...

Think about that:

	% netcat 192.168.123.456 < /tmp/printing.pdf

or even

	% cat /tmp/inkpee.pdf > /dev/ulpt0

to make the printer start printing...

With standardized PDF "instructions", there would be no need
for artificial OS barriers. PDF is known. No need to port any
drivers, to create wrappers or jump though hoops.

Note that the system's DEFAULT printing facility (the printer
spooler) would be a perfect means to plug in. Printer "filters"
could be easily implemented, i. e. only _one_ filter needs to
be present: one that converts an application's PS to PDF and
the send it to the printer's local port or IP address. All the
parts needed for that task are already present (and have been
for many years).

Would be interesting to see how this develops. Thanks for sharing
that info, sounds really good.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120217141447.b99dda33.freebsd>