On 12 Jun 2014, at 00:43, Andreas Lehmkühler <[email protected]> wrote:
> Hi, > >> John Hewson <[email protected]> hat am 12. Juni 2014 um 09:14 geschrieben: >> >> >>> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler <[email protected]> wrote: >>> >>> Hi, >>> >>> Am 02.06.2014 18:46, schrieb Maruan Sahyoun: >>>> Hi >>>> >>>> Am 02.06.2014 um 17:59 schrieb John Hewson <[email protected]>: >>>> >>>>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <[email protected]> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> Maruan Sahyoun >>>>>> >>>>>> Am 02.06.2014 um 08:59 schrieb John Hewson <[email protected]>: >>>>>> >>>>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Am 30.05.2014 23:13, schrieb John Hewson: > > SNIP > >>>>>> There are requests for PDFBox on Android where most of awt is not >>>>>> available. >>>>> >>>>> So the ultimate goal is to have an Android release for 2.0, who's going to >>>>> do this? AWT is very deeply integrated into PD (e.g. colour spaces, >>>>> images) and also FontBox (paths). I think a workable plan for removing it >>>>> is much harder than it looks. >>>> >>>> I don’t think and didn’t want to say that an Android release shall be done >>>> for 2.0. Only wanted to provide feedback why rendering might be on it’s own >>>> module as per Andreas input. >>> Just to avoid misunderstandings. The idea is to have the option to omit >>> certain parts of PDFBox if those are not needed, e.g. for serverside >>> indexing one don't need rendering capabilities. As a side effect the >>> remaining (core) part would be more android friendly as it doesn't contains >>> that much (in a perfect world no) AWT stuff. The same is maybe true for AWS, >>> GAE or similar environments. >> >> GAE forbids even importing classes from AWT, so if there's even a single >> Rectangle or Point in core then it won't work. Likewise if core depends on >> FontBox then that will also not be able to use GeneralPath, AffineTranaform, >> etc. Android is more flexible but it has no native AWT implementation. > That's why I say android friendly. If we split up the code base, it would be > easier to figure out which parts of a module (which isn't directly connected > to > the rendering) have to be reimplemented to avoid AWT to support android, AWS, > GAE and whatever is needed/wanted. Even for those who are not that familiar > with > the code base at all. I'd not say that we should do that at all costs, but > maybe > others are interested. > > Let's see if it is possible without to much effort. Ok, so we’re trying to facilitate contributions, but there isn’t a fixed goal that we must achieve for 2.0 - that’s ok. — John
