You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Tilman Hausherr <TH...@t-online.de> on 2014/05/30 23:01:55 UTC
Idea: stable 2.0 versions
I suggest that we come up with a concept of designating "stable
versions" (or "tested versions") for the trunk and put them on the
homepage. A stable version is one with no or only minor regressions,
and/or a version that committers have found to be "good". This would be
for users of the 2.0 version who don't want to read every discussion,
and also as a hint for unhappy 1.8 users.
I suspect that other open source projects do also have rules to
designate stable versions, but I didn't look at them.
Proposed rules:
- any committer can designate any version that is older than 24 hours as
stable
- any committer can veto any version as unstable
- any version that has only positive votes is mentioned on
https://pdfbox.apache.org/downloads.html#scm
- there should be up to three versions there
Tilman
Re: Idea: stable 2.0 versions
Posted by Santosh Arakeri <sa...@gmail.com>.
Pl dont put in ur cc.
On Sat, May 31, 2014 at 2:31 AM, Tilman Hausherr <TH...@t-online.de>
wrote:
> I suggest that we come up with a concept of designating "stable versions"
> (or "tested versions") for the trunk and put them on the homepage. A stable
> version is one with no or only minor regressions, and/or a version that
> committers have found to be "good". This would be for users of the 2.0
> version who don't want to read every discussion, and also as a hint for
> unhappy 1.8 users.
>
> I suspect that other open source projects do also have rules to designate
> stable versions, but I didn't look at them.
>
> Proposed rules:
> - any committer can designate any version that is older than 24 hours as
> stable
> - any committer can veto any version as unstable
> - any version that has only positive votes is mentioned on
> https://pdfbox.apache.org/downloads.html#scm
> - there should be up to three versions there
>
> Tilman
>
>
Re: Idea: stable 2.0 versions
Posted by John Hewson <jo...@jahewson.com>.
On 12 Jun 2014, at 00:43, Andreas Lehmkühler <an...@lehmi.de> wrote:
> Hi,
>
>> John Hewson <jo...@jahewson.com> hat am 12. Juni 2014 um 09:14 geschrieben:
>>
>>
>>> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler <an...@lehmi.de> wrote:
>>>
>>> Hi,
>>>
>>> Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
>>>> Hi
>>>>
>>>> Am 02.06.2014 um 17:59 schrieb John Hewson <jo...@jahewson.com>:
>>>>
>>>>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Maruan Sahyoun
>>>>>>
>>>>>> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>>>>>>
>>>>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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
Re: Idea: stable 2.0 versions
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
> John Hewson <jo...@jahewson.com> hat am 12. Juni 2014 um 09:14 geschrieben:
>
>
> > On 10 Jun 2014, at 23:02, Andreas Lehmkuehler <an...@lehmi.de> wrote:
> >
> > Hi,
> >
> > Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
> >> Hi
> >>
> >> Am 02.06.2014 um 17:59 schrieb John Hewson <jo...@jahewson.com>:
> >>
> >>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
> >>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Maruan Sahyoun
> >>>>
> >>>> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
> >>>>
> >>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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.
> -- John
BR
Andreas Lehmkühler
Re: Idea: stable 2.0 versions
Posted by John Hewson <jo...@jahewson.com>.
> On 10 Jun 2014, at 23:02, Andreas Lehmkuehler <an...@lehmi.de> wrote:
>
> Hi,
>
> Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
>> Hi
>>
>> Am 02.06.2014 um 17:59 schrieb John Hewson <jo...@jahewson.com>:
>>
>>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> Maruan Sahyoun
>>>>
>>>> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>>>>
>>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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.
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
Re: Idea: stable 2.0 versions
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 02.06.2014 18:46, schrieb Maruan Sahyoun:
> Hi
>
> Am 02.06.2014 um 17:59 schrieb John Hewson <jo...@jahewson.com>:
>
>>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>>
>>>
>>> Hi,
>>>
>>> Maruan Sahyoun
>>>
>>> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>>>
>>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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
Re: Idea: stable 2.0 versions
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
Am 02.06.2014 um 17:59 schrieb John Hewson <jo...@jahewson.com>:
>> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>
>>
>> Hi,
>>
>> Maruan Sahyoun
>>
>> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>>
>>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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.
>
>>
>>>
>>>>
>>>> There are some changes/improvements/bugfixes I'd like to solve as well:
>>>>
>>>> - PDFBOX-922: unicode support
>>>> - PDFBOX-62: almost done
>>>> - improve the parser concerning broken XRef-tables
>
> I'm thinking of taking a look at XRefs.
>
>>>> - complete the recent font-improvements
>>>
>>> Yes, finally removing AWT fonts will be a huge improvement.
>>>
>>>> There some other more or less easy to solve candidates
>>>>
>>>> - enhance type safety
>>>> - remove dependencies
>>>> - ....
>>>>
>>>> There are some other things on our ideas list which should be postponed
>>>>
>>>> - enhanced parser (could maybe done without big refactorings, so that we don't have to wait until the next major release)
>
> Yeah, let's just makes sure the public API is nice and tight, then we can refactor the internals at will later.
>
>>>> - refactoring of COS-level object
>>>> - ....
>>>>
>>>> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>>>>
>>>> We should contact press@ in preparation of the release to phrase a press release.
>>>>
>>>>
>>>> IMHO, it could be realisitc to do a release in the summer, maybe in august.
>>>>
>>>>> -- John
>>>>
>>>> BR
>>>> Andreas Lehmkühler
>>>>>
>>>>>> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>>>>>>
>>>>>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>>>>>
>>>>>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>>>>>
>>>>>> Proposed rules:
>>>>>> - any committer can designate any version that is older than 24 hours as stable
>>>>>> - any committer can veto any version as unstable
>>>>>> - any version that has only positive votes is mentioned on
>>>>>> https://pdfbox.apache.org/downloads.html#scm
>>>>>> - there should be up to three versions there
>>>>>>
>>>>>> Tilman
>>
Re: Idea: stable 2.0 versions
Posted by John Hewson <jo...@jahewson.com>.
> On 2 Jun 2014, at 00:24, Maruan Sahyoun <sa...@fileaffairs.de> wrote:
>
> Hi,
>
> Maruan Sahyoun
>
> Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>
>>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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.
>
>>
>>>
>>> There are some changes/improvements/bugfixes I'd like to solve as well:
>>>
>>> - PDFBOX-922: unicode support
>>> - PDFBOX-62: almost done
>>> - improve the parser concerning broken XRef-tables
I'm thinking of taking a look at XRefs.
>>> - complete the recent font-improvements
>>
>> Yes, finally removing AWT fonts will be a huge improvement.
>>
>>> There some other more or less easy to solve candidates
>>>
>>> - enhance type safety
>>> - remove dependencies
>>> - ....
>>>
>>> There are some other things on our ideas list which should be postponed
>>>
>>> - enhanced parser (could maybe done without big refactorings, so that we don't have to wait until the next major release)
Yeah, let's just makes sure the public API is nice and tight, then we can refactor the internals at will later.
>>> - refactoring of COS-level object
>>> - ....
>>>
>>> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>>>
>>> We should contact press@ in preparation of the release to phrase a press release.
>>>
>>>
>>> IMHO, it could be realisitc to do a release in the summer, maybe in august.
>>>
>>>> -- John
>>>
>>> BR
>>> Andreas Lehmkühler
>>>>
>>>>> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>>>>>
>>>>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>>>>
>>>>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>>>>
>>>>> Proposed rules:
>>>>> - any committer can designate any version that is older than 24 hours as stable
>>>>> - any committer can veto any version as unstable
>>>>> - any version that has only positive votes is mentioned on
>>>>> https://pdfbox.apache.org/downloads.html#scm
>>>>> - there should be up to three versions there
>>>>>
>>>>> Tilman
>
Re: Idea: stable 2.0 versions
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi,
Maruan Sahyoun
Am 02.06.2014 um 08:59 schrieb John Hewson <jo...@jahewson.com>:
>> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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.
>
>>
>> There are some changes/improvements/bugfixes I'd like to solve as well:
>>
>> - PDFBOX-922: unicode support
>> - PDFBOX-62: almost done
>> - improve the parser concerning broken XRef-tables
>> - complete the recent font-improvements
>
> Yes, finally removing AWT fonts will be a huge improvement.
>
>> There some other more or less easy to solve candidates
>>
>> - enhance type safety
>> - remove dependencies
>> - ....
>>
>> There are some other things on our ideas list which should be postponed
>>
>> - enhanced parser (could maybe done without big refactorings, so that we don't have to wait until the next major release)
>> - refactoring of COS-level object
>> - ....
>>
>> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>>
>> We should contact press@ in preparation of the release to phrase a press release.
>>
>>
>> IMHO, it could be realisitc to do a release in the summer, maybe in august.
>>
>>> -- John
>>
>> BR
>> Andreas Lehmkühler
>>>
>>>> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>>>>
>>>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>>>
>>>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>>>
>>>> Proposed rules:
>>>> - any committer can designate any version that is older than 24 hours as stable
>>>> - any committer can veto any version as unstable
>>>> - any version that has only positive votes is mentioned on
>>>> https://pdfbox.apache.org/downloads.html#scm
>>>> - there should be up to three versions there
>>>>
>>>> Tilman
>>
Re: Idea: stable 2.0 versions
Posted by John Hewson <jo...@jahewson.com>.
> On 1 Jun 2014, at 06:03, Andreas Lehmkuehler <an...@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 some changes/improvements/bugfixes I'd like to solve as well:
>
> - PDFBOX-922: unicode support
> - PDFBOX-62: almost done
> - improve the parser concerning broken XRef-tables
> - complete the recent font-improvements
Yes, finally removing AWT fonts will be a huge improvement.
> There some other more or less easy to solve candidates
>
> - enhance type safety
> - remove dependencies
> - ....
>
> There are some other things on our ideas list which should be postponed
>
> - enhanced parser (could maybe done without big refactorings, so that we don't have to wait until the next major release)
> - refactoring of COS-level object
> - ....
>
> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>
> We should contact press@ in preparation of the release to phrase a press release.
>
>
> IMHO, it could be realisitc to do a release in the summer, maybe in august.
>
>> -- John
>
> BR
> Andreas Lehmkühler
>>
>>> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>>>
>>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>>
>>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>>
>>> Proposed rules:
>>> - any committer can designate any version that is older than 24 hours as stable
>>> - any committer can veto any version as unstable
>>> - any version that has only positive votes is mentioned on
>>> https://pdfbox.apache.org/downloads.html#scm
>>> - there should be up to three versions there
>>>
>>> Tilman
>
Re: Idea: stable 2.0 versions
Posted by James Green <ja...@gmail.com>.
Andreas,
Has there been discussion of PDFBOX-1586 as yet? This is the second bug for
which we are having to maintain an internal fork of PDFBox for. I do not
have the knowledge necessary to resolve it myself so I'm rather hanging on
the core developers I'm afraid.
Thanks,
James
On 2 June 2014 09:11, Tilman Hausherr <TH...@t-online.de> wrote:
> Am 01.06.2014 19:57, schrieb Maruan Sahyoun:
>
> Hi
>>
>> Am 01.06.2014 um 18:51 schrieb Tilman Hausherr <TH...@t-online.de>:
>>
>> Am 01.06.2014 15:46, schrieb Maruan Sahyoun:
>>>
>>>> There is one important thing we have to do before releasing 2.0, an
>>>>>> upgrade guide including updated docs.
>>>>>>
>>>>> could handle that. Would need some input about major changes as a
>>>> starting point as I din’t follow all breaking changes.
>>>>
>>>> Here are the ones I know about:
>>>
>>> old => new
>>>
>>> PDXObjectForm => PDFormXObject
>>> PDXObjectImage => PDImageXObject
>>> PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage()
>>> PDXObjectImage.getRGBImage() => PDImageXObject.getImage()
>>>
>>> ???? => PDFPrinter(PDDocument, ....).print(PDDocument,PrinterJob, …)
>>>
>> AFAIK this was PDDocument.print()
>>
>
> Yes indeed.
>
> Got another:
>
> 1.8:
> public void processStream( PDPage aPage, PDResources resources, COSStream
> cosStream )
> public void processSubStream(PDPage aPage, PDResources resources,
> COSStream cosStream)
>
> 2.0:
> public void processStream(PDResources resources, COSStream cosStream,
> PDRectangle drawingSize, int rotation)
> public void processSubStream(PDResources resources, COSStream cosStream)
>
>
>
>
Re: Idea: stable 2.0 versions
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 01.06.2014 19:57, schrieb Maruan Sahyoun:
> Hi
>
> Am 01.06.2014 um 18:51 schrieb Tilman Hausherr <TH...@t-online.de>:
>
>> Am 01.06.2014 15:46, schrieb Maruan Sahyoun:
>>>>> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>>> could handle that. Would need some input about major changes as a starting point as I din’t follow all breaking changes.
>>>
>> Here are the ones I know about:
>>
>> old => new
>>
>> PDXObjectForm => PDFormXObject
>> PDXObjectImage => PDImageXObject
>> PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage()
>> PDXObjectImage.getRGBImage() => PDImageXObject.getImage()
>>
>> ???? => PDFPrinter(PDDocument, ....).print(PDDocument,PrinterJob, …)
> AFAIK this was PDDocument.print()
Yes indeed.
Got another:
1.8:
public void processStream( PDPage aPage, PDResources resources,
COSStream cosStream )
public void processSubStream(PDPage aPage, PDResources resources,
COSStream cosStream)
2.0:
public void processStream(PDResources resources, COSStream cosStream,
PDRectangle drawingSize, int rotation)
public void processSubStream(PDResources resources, COSStream cosStream)
Re: Idea: stable 2.0 versions
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
Am 01.06.2014 um 18:51 schrieb Tilman Hausherr <TH...@t-online.de>:
> Am 01.06.2014 15:46, schrieb Maruan Sahyoun:
>>> >
>>> >There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
>> could handle that. Would need some input about major changes as a starting point as I din’t follow all breaking changes.
>>
>
> Here are the ones I know about:
>
> old => new
>
> PDXObjectForm => PDFormXObject
> PDXObjectImage => PDImageXObject
> PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage()
> PDXObjectImage.getRGBImage() => PDImageXObject.getImage()
>
> ???? => PDFPrinter(PDDocument, ....).print(PDDocument,PrinterJob, …)
AFAIK this was PDDocument.print()
Re: Idea: stable 2.0 versions
Posted by Tilman Hausherr <TH...@t-online.de>.
Am 01.06.2014 15:46, schrieb Maruan Sahyoun:
>> >
>> >There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
> could handle that. Would need some input about major changes as a starting point as I din’t follow all breaking changes.
>
Here are the ones I know about:
old => new
PDXObjectForm => PDFormXObject
PDXObjectImage => PDImageXObject
PDPage.convertToImage() => PDFRenderer(PDDocument).renderImage()
PDXObjectImage.getRGBImage() => PDImageXObject.getImage()
???? => PDFPrinter(PDDocument, ....).print(PDDocument,PrinterJob, ...)
Re: Idea: stable 2.0 versions
Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi
Am 01.06.2014 um 15:03 schrieb Andreas Lehmkuehler <an...@lehmi.de>:
> 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.
>
>> 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
could handle that
> - update bouncy castle
> - split the pdfbox module in at least 2 modules (core and rendering)
would break into pdfbox-core (parsing and COS), pdfbox-pd (PD model) and pdfbox-rendering.
>
> There are some changes/improvements/bugfixes I'd like to solve as well:
>
> - PDFBOX-922: unicode support
one of the most important missing basic features affecting forms handling, updating a pdf with non ISO chars …..
> - PDFBOX-62: almost done
> - improve the parser concerning broken XRef-tables
> - complete the recent font-improvements
>
> There some other more or less easy to solve candidates
>
> - enhance type safety
> - remove dependencies
> - ....
>
> There are some other things on our ideas list which should be postponed
>
> - enhanced parser (could maybe done without big refactorings, so that we don't have to wait until the next major release)
+1 to postpone it (haven’t go any feedback on the lexer yet). At least it could be done wo affecting the PD model.
> - refactoring of COS-level object
+1 to postpone it as this should be done together with the parsing
> - ....
>
> There is one important thing we have to do before releasing 2.0, an upgrade guide including updated docs.
could handle that. Would need some input about major changes as a starting point as I din’t follow all breaking changes.
>
> We should contact press@ in preparation of the release to phrase a press release.
>
>
> IMHO, it could be realisitc to do a release in the summer, maybe in august.
>
>> — John
WRT a roadmap I’d think it would be very good to come up with one but that would mean to agree on a set of features/changes upfront for a specific release. Don’t know if that is doable. E.g. a lot of the new/improved functionality is around rendering which is a very important functionality as this is a very common use case. On the other hand that hasn’t been on the ideas page.
>
> BR
> Andreas Lehmkühler
>>
>> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>>
>>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>>
>>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>>
>>> Proposed rules:
>>> - any committer can designate any version that is older than 24 hours as stable
>>> - any committer can veto any version as unstable
>>> - any version that has only positive votes is mentioned on
>>> https://pdfbox.apache.org/downloads.html#scm
>>> - there should be up to three versions there
>>>
>>> Tilman
>>>
>>
>>
>
Re: Idea: stable 2.0 versions
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
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.
> 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)
There are some changes/improvements/bugfixes I'd like to solve as well:
- PDFBOX-922: unicode support
- PDFBOX-62: almost done
- improve the parser concerning broken XRef-tables
- complete the recent font-improvements
There some other more or less easy to solve candidates
- enhance type safety
- remove dependencies
- ....
There are some other things on our ideas list which should be postponed
- enhanced parser (could maybe done without big refactorings, so that we don't
have to wait until the next major release)
- refactoring of COS-level object
- ....
There is one important thing we have to do before releasing 2.0, an upgrade
guide including updated docs.
We should contact press@ in preparation of the release to phrase a press release.
IMHO, it could be realisitc to do a release in the summer, maybe in august.
> -- John
BR
Andreas Lehmkühler
>
> On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
>
>> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>>
>> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>>
>> Proposed rules:
>> - any committer can designate any version that is older than 24 hours as stable
>> - any committer can veto any version as unstable
>> - any version that has only positive votes is mentioned on
>> https://pdfbox.apache.org/downloads.html#scm
>> - there should be up to three versions there
>>
>> Tilman
>>
>
>
Re: Idea: stable 2.0 versions
Posted by John Hewson <jo...@jahewson.com>.
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.
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?
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...
-- John
On 30 May 2014, at 14:01, Tilman Hausherr <TH...@t-online.de> wrote:
> I suggest that we come up with a concept of designating "stable versions" (or "tested versions") for the trunk and put them on the homepage. A stable version is one with no or only minor regressions, and/or a version that committers have found to be "good". This would be for users of the 2.0 version who don't want to read every discussion, and also as a hint for unhappy 1.8 users.
>
> I suspect that other open source projects do also have rules to designate stable versions, but I didn't look at them.
>
> Proposed rules:
> - any committer can designate any version that is older than 24 hours as stable
> - any committer can veto any version as unstable
> - any version that has only positive votes is mentioned on
> https://pdfbox.apache.org/downloads.html#scm
> - there should be up to three versions there
>
> Tilman
>