[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpprintipp] Remote print to a receipt printer
From: |
Thomas Harding |
Subject: |
Re: [Phpprintipp] Remote print to a receipt printer |
Date: |
Tue, 12 Feb 2013 20:56:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121123 Icedove/10.0.11 |
Le 12/02/2013 13:34, Harvey Magana a écrit :
Hello Author,
Hi, coder :)
I am in need of guidance with yourPHP::PRINT::IPP. I would like to
know if I can use this for remote print to a receipt printer. I have
made a deli website and the owner would like the web order results to
print to a thermal receipt printer at his deli. I am using oop php,
have created the database, and am working on the programming to create
the form, but will soon hit the point where the results need to be
sent to the printer. If you can let me know if this can be done that
would be great. Thanks in advance.
Answer is verbose, and my English is tedious...
IPP is just a transport layer (underlying one is http / tcp 631), with
meta-informations : how to handle the document/media, instructions to
print the job... (among other operations).
If your needs are just to fill the printer, you can also use "print /
lpr", tcp 515.
PHP::PRINT::IPP is *only* an IPP v1.1 *client*. Most of professional
printers has a built-in IPP server for years. *Only a few will handle
directly several types of documents (such as PostScript)*.
In most cases you'll need an IPP server which handles the file formats
to print to fill the printer with its built-in print printer's language,
such as HPGL (note any printer, with except for garbage WinPrinter ones,
will handle ASCII text, and there is a mode in php::print::ipp for that,
which offers notably a form-feed character).
So, at option, you'll need :
* a print server with IPP v1.1 capability, such as CUPS (work at least
on any UNIX and Mac OSX -- Apple did buy the CUPS code to the original
author and uses and maintain it :).
CUPS follows IPP v1.1 guidance and handles numerous file
formats,
even automagically with "application/octet-stream" as
mime-type
*if you didn't done the setup to pass
application/octet-stream as throughput* (in most case : that setup is
done to handle MS-Windows clients)
if that kind of setup has been done, you'll need at
least to pass the convenient mime-type, such as "application/pdf",
"application/postscript" or "image/png", and I'm unsure how it works...
* or the printer itself has an IPP1.1 built-in print server and you
can fill it with a document it handles (eg: postscript to a postscript
capable printer).
In most cases, built-in print servers does not follows IPP v1.1
guidance and handles only printer's language for
"application/octet-stream" mime-type -- such as HPGL, also plain ASCII text.
* if a printer has no network capability, you can use some cheap print
servers, such as TrendNet TE100... at least the "P1P" parallel version
(5 years ago) works perfectly *in combination* with a CUPS server (and
CUPS comes with any GNU/Linux distro). I used successfully a TrendNet
P1P directly for ASCII text with an old Epson printer.
==================
* for your purpose (thermal, direct printing through a cheap IPP print
server), the probability is : you done a bitmap coming with the
printer's specifical stream instructions (up to your programing, in
accordance with the printer documentation), then pass it through an IPP
request. Simply fill the cheap print server with
"application/octet-stream" as mime-type (possibly aliased
document_format, please take a look at http://phpprintipp.nongnu.org,
there is a link to online doc).
==================
Best Regards,
TSFH