You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Giampaolo Tomassoni <Gi...@Tomassoni.biz> on 2010/08/19 00:43:44 UTC

[legal?] Any implication in using Harmony's print module in Android?

Hi everybody.

I see Android misses any printing support at all, while it comes with
full-fledged networking capabilities (dialup, wifi, bluetooth).

This seems quite weird to me, even because porting there (and eventually
adapting/extending) the javax.print API module from Harmony won't seem a too
complex task to me.

So, why nobody did yet do it?

I posted a similar question in the "Android discuss" list, but nobody
replied.

Is there any licensing issue with this?

I'm quite new to the Android and Harmony world, so please forgive me if I'm
missing something.

Thank you,

Giampaolo


RE: [legal?] Any implication in using Harmony's print module in Android?

Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> I'm not comfortable with Graphics2D2PS, because most printers nowadays

Sorry, I meant:

"I'm not comfortable with PostScript, because most printers nowadays"


RE: [legal?] Any implication in using Harmony's print module in Android?

Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> 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
> <Gi...@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).


Re: [legal?] Any implication in using Harmony's print module in Android?

Posted by Andrey Pavlenko <an...@googlemail.com>.
Document rendering can be done via PostScript interface which is
already implemented in Harmony - class
org.apache.harmony.x.print.Graphics2D2PS.

On Thu, Aug 19, 2010 at 4:25 AM, Giampaolo Tomassoni
<Gi...@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).

Re: [legal?] Any implication in using Harmony's print module in Android?

Posted by Tim Ellison <t....@gmail.com>.
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
> 
> 

RE: [legal?] Any implication in using Harmony's print module in Android?

Posted by Giampaolo Tomassoni <Gi...@Tomassoni.biz>.
> > 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.


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


Re: [legal?] Any implication in using Harmony's print module in Android?

Posted by Mark Hindess <ma...@googlemail.com>.
In message <00...@biz>, "Giampaolo Tomassoni"
writes:
>
> Hi everybody.
> 
> I see Android misses any printing support at all, while it comes with
> full-fledged networking capabilities (dialup, wifi, bluetooth).
>
> This seems quite weird to me, even because porting there (and
> eventually adapting/extending) the javax.print API module from Harmony
> won't seem a too complex task to me.
> 
> 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.

> Is there any licensing issue with this?

The license for the print module is the same as the others - ALv2.

> I'm quite new to the Android and Harmony world, so please forgive me
> if I'm missing something.

No problem.

Regards,
 Mark.



Re: [legal?] Any implication in using Harmony's print module in Android?

Posted by Jesse Wilson <je...@google.com>.
Giampaolo,

The javax.print has an API
dependency<http://download.oracle.com/javase/6/docs/api/javax/print/ServiceUI.html>
on
Java AWT, which is a desktop windowing UI. This will make it quite difficult
to implement the full API on Android. If you only need a narrower API, the
job may be significantly easier.

That said, Dalvik provides
documentation<http://code.google.com/p/dalvik/wiki/JavaxPackages>for
supplementing the standard APIs.

Cheers,
Jesse