On 02/17/12 23:14, Polytropon wrote:
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.
PDF is not exactly PS, but it does use a subset of the instructions. As
near as I can tell this is how they're using it, as it is only 1.7 or so
onwards.
The other thing you will notice is that its mostly on MFC's, so I
believe they're using the PS chipset to encode a scanned doc to PDF; I'm
not sure it works the other way around, and I may even be wrong about
what they're doing but I think it is very suspect.
A PS chipset is only an interpreter - it cannot normally encode PS, only
read a PS stream and rasterise it. But they may have extended it in only
this case. As for printing PDF, maybe... time will only tell.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
