pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hewson <j...@jahewson.com>
Subject Re: Idea: stable 2.0 versions
Date Thu, 12 Jun 2014 16:21:06 GMT
On 12 Jun 2014, at 00:43, Andreas Lehmkühler <andreas@lehmi.de> wrote:

> Hi,
> 
>> John Hewson <john@jahewson.com> hat am 12. Juni 2014 um 09:14 geschrieben:
>> 
>> 
>>> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler <andreas@lehmi.de> wrote:
>>> 
>>> Hi,
>>> 
>>> Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
>>>> Hi
>>>> 
>>>> Am 02.06.2014 um 17:59 schrieb John Hewson <john@jahewson.com>:
>>>> 
>>>>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sahyoun@fileaffairs.de>
wrote:
>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Maruan Sahyoun
>>>>>> 
>>>>>> Am 02.06.2014 um 08:59 schrieb John Hewson <john@jahewson.com>:
>>>>>> 
>>>>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <andreas@lehmi.de>
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message