> 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: >>>>>>> I think the risk of creating the impression that 2.0 is stable is too >>>>>>> high. The real problem >>>>>>> is that 2.0 has been too long in development, there were frustrated >>>>>>> users asking a year >>>>>>> ago about when it would be released. >>>>>> The biggest issue is, that we can't name a version stable without an >>>>>> official release. >>>>> >>>>> Seems like there could be some "release candidates" at some point soon... >>>>> not quite yet. >>>>> >>>>>> >>>>>>> Perhaps it’s time to push for a release of 2.0 and aim for a more >>>>>>> frequent release cycle >>>>>>> after that, to avoid repeating the situation where the stable and trunk >>>>>>> versions are >>>>>>> years apart? >>>>>> +1, it's time to go for release, not tomorrow or next week, but we >>>>>> should start to do some planning. >>>>>> >>>>>>> What is holding back 2.0? What features are we *really* holding out on? >>>>>>> Can we put >>>>>>> together a roadmap - our users often ask for one... >>>>>> I already had a starting discussion with Maruan two weeks ago at a f2f >>>>>> meeting. >>>>>> >>>>>> I'd like to add those changes which include api changes so what we >>>>>> haven't to wait until the next major release, at least those changes >>>>>> which are not that big, such as >>>>>> >>>>>> - solving the jempbox/xmpbox issue >>>>>> - update bouncy castle >>>>>> - split the pdfbox module in at least 2 modules (core and rendering) >>>>> >>>>> Splitting the rendering code into a module isn't really a feature... is >>>>> there a higher-level goal? If so, is it achievable for a 2.0 release in >>>>> the near future? >>>> >>>> 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. -- John
