harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giampaolo Tomassoni" <Giampa...@Tomassoni.biz>
Subject RE: [legal?] Any implication in using Harmony's print module in Android?
Date Fri, 20 Aug 2010 08:31:24 GMT
> Document rendering can be done via PostScript interface which is
> already implemented in Harmony - class
> org.apache.harmony.x.print.Graphics2D2PS.

Unfortunately, Graphics2D2PS doesn't fit the Android environment because the latter misses
a Graphics2D class. Perhaps it could be eventually adapted to work on android.graphics.Canvas
instead. however, I'm not comfortable with Graphics2D2PS, because most printers nowadays don't
directly implement it: low cost units are more akin to embed a PCL parser, instead. Which
is why I was thinking of Apache FOP. Also, some printer (mostly bluetooth-enabled ones) should
also embed an XHTML-Print parser, which is a much less memory-demanding PDL than PostScript.

Anyway, to me the first goal for a printing framework in Android is printer detection and
connection capability: being Android mostly used in mobile devices, this is a very important
task to accomplish. You can't simply setup your printer in Android once and print many times
there... I'm dreaming of a multi-protocol approach, in which IPP, ZeroConf (mDNS), and Bluetooth
(BPP) interoperate to get the list of printers available to the user.

The imaging phase is, of course, important, but I would prefer to leverage on the javax.print.StreamPrintServiceFactory
approach in order to provide different StreamPrintService providers ranging from simple ones
(i.e.: smaller footprint, simple connect-and-send-app-data) to most complex ones (i.e.: bigger
footprint, adapt-app-data-to-printer). Application writers may then decide to detect only
printers supporting the printing format their application produces, or instead detect a wider
range of printers, produce an FOP, XHTML-Print or SVG source document and then allow the printing
environment (to attempt) to adapt that source to the printer the user likes.

This is because Android devices may range from very simple toy-phones to more powerful units,
so not every device may support a full-fledged printing environment.

> On Thu, Aug 19, 2010 at 4:25 AM, Giampaolo Tomassoni
> <Giampaolo@tomassoni.biz> wrote:
> > Document rendering could even use a completely different approach
> then the
> > AWT-based one, in example an application could use Apache FOP to
> allow
> > rendering in the printer's PDL. Or instead an application could
> simply
> > discover printers accepting a specific PDF (XHTML-Print, in example).

View raw message