On 19/Aug/2010 01:25, Giampaolo Tomassoni wrote: >>> So, why nobody did yet do it? >>> >>> I posted a similar question in the "Android discuss" list, but nobody >>> replied. >> I'm reluctant to speculate when they chose not to answer for >> themselves. >> However, if you look at the manifest for the print.jar you will find >> that >> it imports: >> >> java.awt, >> java.awt.event, >> java.awt.font, >> java.awt.geom, >> java.awt.image, >> java.awt.image.renderable, >> java.awt.print, >> java.beans, >> java.io, >> java.lang, >> java.lang.annotation, >> java.lang.reflect, >> java.net, >> java.nio, >> java.security, >> java.text, >> java.util, >> javax.accessibility, >> javax.imageio, >> javax.swing, >> javax.swing.border, >> javax.swing.event, >> javax.swing.text, >> org.apache.harmony.awt.gl, >> org.apache.harmony.awt.gl.windows, >> org.apache.harmony.kernel.vm >> >> I'm not familiar with the set of modules that are included in Android >> but I am pretty sure some of these dependencies are not included. >> Therefore your question becomes: >> >> why nobody did yet port the print module and enough of awt, swing, >> beans, etc. to make it work? >> >> You are probably correct that porting the print module would be >> relatively trivial (since for linux it is pure java) but the same is >> likely not true of all the dependencies. > > Well, I was probably a bit too wide in scope. Porting into Android the > javax.print package means to me that only part of the package itself would > be needed. Notably, the UI stuff wouldn't. It wouldn't even need to support > any java.awt.print facility. > >>From the application standpoint, the core classes of such a printing > facility in Android would then be the PrintServiceLookup one and its non-ui > relatives (PrintService, in example), then of course Doc, DocPrintJob, > StreamPrintService+Factory and their relatives. > > Then, the basic idea would eventually be to give access to printing from > Android using most of the features available from the well-consolidated > javax.print printing API. This is for ease of use to application coders, of > course. > > 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). > > Also, a re-packaging of the javax.print package makes of course sense to me. > > But anyway, many of the javax.print classes would be simply "stolen" from > the Harmony tree. That arose my question about legal issues.
:-) You are most welcome to use any of the Harmony project's code subject to the terms of the Apache license here [1]. If you have any technical questions about the code just ask on this list. There are plenty of people to answer them (or say we don't know!) [1] http://www.apache.org/licenses/LICENSE-2.0 Regards, Tim >>> Is there any licensing issue with this? >> The license for the print module is the same as the others - ALv2. > > Which seems fine to me. > > >>> I'm quite new to the Android and Harmony world, so please forgive me >>> if I'm missing something. >> No problem. >> >> Regards, >> Mark. > > Thank you Mark. > > Giampaolo > >
