harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [legal?] Any implication in using Harmony's print module in Android?
Date Thu, 19 Aug 2010 02:09:47 GMT
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
> 
> 

Mime
View raw message