Creating a generic printer interface (encapsulating a printer driver)?

  • Thread starter Thread starter ElderUberGeek
  • Start date Start date
E

ElderUberGeek

I would like to enable a system to basically accept any type of printer
(well, within limits, as it is a POS). As such, I would like to
encapsulate the printer driver's specific API and expose a generic one
(effectively mediating between the driver and the application). This
was the application only has to know one type of interface and printers
can be switched at will. Of course one would have to write a pice of
glue to encapsulate the specific driver, but I hope with sufficient
insentive the manufacture might do that.

So:

- Is this a good design/idea?
- What would a "standard" simplified API look like?
- How much effort would it be to encapsulate a given driver
(hard/medium/easy)

Thanks
 
ElderUberGeek said:
I would like to enable a system to basically accept any type of printer
(well, within limits, as it is a POS). As such, I would like to
Click to expand...

Let's assume that means "Point Of Sale" rather than the first thing
that came to mind.
encapsulate the printer driver's specific API and expose a generic one
(effectively mediating between the driver and the application). This
was the application only has to know one type of interface and printers
can be switched at will. Of course one would have to write a pice of
glue to encapsulate the specific driver, but I hope with sufficient
insentive the manufacture might do that.

So:

- Is this a good design/idea?
Click to expand...

It's a desirable goal, both for end users and the system vendor. Maybe
for printer vendors, if you can convince them the extra work would sell
more printers.
- What would a "standard" simplified API look like?
- How much effort would it be to encapsulate a given driver
(hard/medium/easy)
Click to expand...

Look at existing designs:

Windows has been doing this for years (although there were other systems
that did it before Windows). An advantage here is that printer
manufacturers will actually produce Windows drivers, while requests for
drivers for other operating systems are generally met with cow-like
blank stares.

For Unix, applications generally produce device-indepent PostScript
output and any of a number of printing systems either send it directly
to PS-capable printers, or render it to something a non-PS printer can
handle and then send it on.

There's the approach of the application creating XML or SGML or some
other type of markup code, and then running this through a converter
that feeds into one of the examples above. This design lends itself to
an end user possibly being able to come up with their own drivers after
support for the application goes away.
 
ElderUberGeek,
I would like to enable a system to basically accept any type of printer
Click to expand...

are you talking about legacy systems ?

If so, you may want to have a look at Printfil.

Kind regards,
Davide Guolo
--------------------------------------------------------------
Printfil - Windows Printing System for Applications
http://www.printfil.com
Odbc4All - Connection to ODBC Data Sources for any Application
http://www.guolo.com/odbc4all
--------------------------------------------------------------
 
Back
Top