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 <(E-Mail Removed)> wrote:
>
> 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

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?

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)

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.

--
Warren Block * Rapid City, South Dakota * USA

Take a look at the PWG website, there might already be some stadards you can
use.

www.pwg.org

--
Christoph Lindemann
Undocumented Printing
http://undocprint.printassociates.com/


"ElderUberGeek" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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,

> I would like to enable a system to basically accept any type of printer

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
--------------------------------------------------------------