Hi,
Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
Hi
Am 02.06.2014 um 17:59 schrieb John Hewson <j...@jahewson.com>:
On 2 Jun 2014, at 00:24, Maruan Sahyoun <sahy...@fileaffairs.de> wrote:
Hi,
Maruan Sahyoun
Am 02.06.2014 um 08:59 schrieb John Hewson <j...@jahewson.com>:
On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <andr...@lehmi.de> 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.
BR
Andreas Lehmkühler
