> 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 > <giampa...@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).
