yes, because the interactive forms API in 2.0 changed :-) And the improvement is a hack for a specific case.
Maruan Am 11.10.2014 um 13:21 schrieb Tilman Hausherr <thaush...@t-online.de>: > Sure, go ahead. That is one thing I that "must" be in 2.0, because you > improved it for 1.8 only :-) > > Tilman > > Am 11.10.2014 um 13:14 schrieb Maruan Sahyoun: >> If no one else wants to work on the interactive forms part it’l take me at >> least another month to implement that correctly i.e. resolve the short >> comings of the 1.x approach. That’s mainly because appearance generation is >> only generally documented but part of the individual implementation of the >> various tools used (the ’styles’ used for the appearance like margins used, >> padding …). This is not documented. And we don’t have a good set of test >> files for various interactive form aspects. >> >> There is also a dependency on handling characters consistently when >> generating new content. IMHO I think we are still limited here when it >> comes to characters outside the ISO-8859-1 range. >> >> Maruan >> >> >> >> Am 11.10.2014 um 12:50 schrieb Tilman Hausherr <thaush...@t-online.de>: >> >>> I disagree with this. We fixed or closed about 80 issues this month but >>> most are new issues. The older an issue is, the most unlikely it can be >>> fixed. >>> >>> You labeled many a "fix version" which would mean they "must" be fixed for >>> 2.0. One example: PDFBOX-2402 >>> <https://issues.apache.org/jira/browse/PDFBOX-2402> is about a parser >>> improvement related to some bad PDFs that is relevant to one user only (I >>> will fix that one soon, I just need to create a test file, but we could as >>> well live without it). Another example was a color problem I had opened >>> (PDFBOX-2142) which is probably only relevant to rendering advertising >>> flyers. >>> >>> 2.0 is more and more becoming the "Duke Nukem Forever" of open source. I'm >>> also thinking about the new Berlin airport. Although there is one >>> difference: the people of "Duke Nukem Forever" and the new Berlin airport >>> made the mistake to announce release dates. >>> >>> I agree with Simon. 2.0 is already a massive improvement. >>> >>> We should name maybe 10 issues that "must" be solved before 2.0. I'm >>> thinking about regressions, issues were we are close to success (patterns), >>> and issues where somebody attached his name (with the meaning "I can fix >>> that and I know what has to be done"). And a short documentation about what >>> has changed. >>> >>> Tilman >>> >>> Am 11.10.2014 um 04:37 schrieb John Hewson: >>>> Hi All, >>>> >>>> I really want to give a better answer to this question, but the JIRA >>>> issues were not >>>> labelled with enough version-related information to allow me to simply >>>> view a list >>>> of issues which are due to be fixed in 2.0. >>>> >>>> As you’re probably aware, I went through pretty much all the issues and >>>> made sure >>>> that issues which definitely affect 2.0 had that in their "Affects >>>> Version/s” field. I also >>>> set the "Fix Version/s” for issues which are due to be fixed in 2.0, so >>>> for the first time >>>> we have a way to see which issues are due to be fixed. The end result is >>>> here: >>>> >>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PDFBOX%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.0.0%20ORDER%20BY%20priority%20DESC >>>> >>>> So I can now say that we have 166 issues due to be fixed in 2.0. We might >>>> want to >>>> choose to defer some of these (we’ll need to add a “Later” version to JIRA >>>> to do that) >>>> and to maybe take a look at issues which overlap with current development >>>> such as >>>> xrefs, rendering, and parsing. >>>> >>>> Cheers >>>> >>>> -- John >>>> >>>> On 10 Oct 2014, at 11:05, John Hewson <j...@jahewson.com> wrote: >>>> >>>>> Simon, >>>>> >>>>> Andreas has the best handle on this, but off the top of my head what we >>>>> need is to finish >>>>> making breaking API changes and for the code to have been stable for a >>>>> while before >>>>> making a 2.0 release. >>>>> >>>>> Improvements and fixes which still need breaking API changes include: >>>>> - Pattern rendering >>>>> - Pages resource caching (significant memory usage issues) >>>>> - Font embedding (particularly TTF) >>>>> - Parsing (Andreas?) >>>>> - Page Tree (needs completely re-writing) >>>>> - Text extraction on Java 8 (this might end up being a breaking change >>>>> to the sort) >>>>> >>>>> There’s probably more, such as work on Acroforms, and we need to have >>>>> much better >>>>> example code for 2.0 due to all the changes. >>>>> >>>>> This seems like a good time to explicitly try to make sure that we have >>>>> JIRA issues open >>>>> for all outstanding tasks, so that we can track how close 2.0 is to being >>>>> ready. The stability >>>>> of the code is a pretty good indicator - we’re not there yet. >>>>> >>>>> I’m going to open some JIRA issues. Andreas, Tilman - please open issues >>>>> for any >>>>> 2.0 features which you think we need. >>>>> >>>>> Thanks >>>>> >>>>> -- John >>>>> >>>>> On 10 Oct 2014, at 08:08, Simon Steiner <simonsteiner1...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Could you set a target date for 2.0 release. What's missing to make a >>>>>> release? >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >
