[jira] [Commented] (PDFBOX-1511) pdfMerger App produces Garbage
[ https://issues.apache.org/jira/browse/PDFBOX-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096670#comment-14096670 ] Tilman Hausherr commented on PDFBOX-1511: - I'll do it tonight. pdfMerger App produces Garbage -- Key: PDFBOX-1511 URL: https://issues.apache.org/jira/browse/PDFBOX-1511 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.7.1 Environment: Win XP; Windows Server 2008 R2; java version 1.6.0_21, Reporter: Michael Huber Fix For: 1.8.7, 2.0.0 Attachments: 078117u1.pdf, 078117u2.pdf, 078118.pdf, 1.pdf, 2.pdf, PDFMergerUtility.java, PDFMergerUtility.java.diff, PdfRenderer.java, targetPdfMergeJava.pdf, targetPdfMergeUtilityApp.pdf pdfbox Utility pdfMerger produces a merged document containing garbage. All merged pdf files are contained but Strings are destroyed. The source pdf files are created with graphviz and are readable without error or disturbance both with Acrobat X and pdfbox pdfDebug Utility. Another astounding thing is that a handcoded merger using pdfMergerUtility class works fine when run within Eclipse Juno and creates same garbage when run from cmd line (pls. see attached source PdfRenderer.java) I checked everything that comes in mind to find the differences, e.g. Java version, encoding/codepage issues, memory settings, found nothing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-2261) Extremely long hang during getFields() on a few PDF files
[ https://issues.apache.org/jira/browse/PDFBOX-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096671#comment-14096671 ] Andreas Lehmkühler commented on PDFBOX-2261: I guess we all have to same idea and I'm going to take care about that. Thanks for your input! Extremely long hang during getFields() on a few PDF files - Key: PDFBOX-2261 URL: https://issues.apache.org/jira/browse/PDFBOX-2261 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 1.8.6 Reporter: Tim Allison Assignee: Andreas Lehmkühler Priority: Minor Fix For: 2.0.0 Attachments: 966679.pdf, RadioButtons.pdf, screenshot-pdfdebugger.png When I run oap.examples.fdf.PrintFields from trunk, the code seems to hang during acroForm.getFields(). This is a heavy load hang. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: PDFBox 1.8.7 release?
I’d like to include PDFBOX-2249 - should be ready by then. Am 14.08.2014 um 09:08 schrieb Andreas Lehmkühler andr...@lehmi.de: Andreas Lehmkühler andr...@lehmi.de hat am 7. August 2014 um 12:35 geschrieben: Hi, there is already a number of solved issues and I guess it's time for a new bugfix release. I'm working on PDFBOX-2250 and I'd like to finish that first but how about a new release in 2 or 3 weeks from now? WDYT? As there weren't any objections I'm targeting the first week of september to cut the release. BR Andreas Lehmkühler
[jira] [Commented] (PDFBOX-1511) pdfMerger App produces Garbage
[ https://issues.apache.org/jira/browse/PDFBOX-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097173#comment-14097173 ] ASF subversion and git services commented on PDFBOX-1511: - Commit 1617990 from [~tilman] in branch 'pdfbox/branches/1.8' [ https://svn.apache.org/r1617990 ] PDFBOX-1511: don't share resources between different source files, as suggested by Kirk Haines pdfMerger App produces Garbage -- Key: PDFBOX-1511 URL: https://issues.apache.org/jira/browse/PDFBOX-1511 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.7.1 Environment: Win XP; Windows Server 2008 R2; java version 1.6.0_21, Reporter: Michael Huber Fix For: 1.8.7, 2.0.0 Attachments: 078117u1.pdf, 078117u2.pdf, 078118.pdf, 1.pdf, 2.pdf, PDFMergerUtility.java, PDFMergerUtility.java.diff, PdfRenderer.java, targetPdfMergeJava.pdf, targetPdfMergeUtilityApp.pdf pdfbox Utility pdfMerger produces a merged document containing garbage. All merged pdf files are contained but Strings are destroyed. The source pdf files are created with graphviz and are readable without error or disturbance both with Acrobat X and pdfbox pdfDebug Utility. Another astounding thing is that a handcoded merger using pdfMergerUtility class works fine when run within Eclipse Juno and creates same garbage when run from cmd line (pls. see attached source PdfRenderer.java) I checked everything that comes in mind to find the differences, e.g. Java version, encoding/codepage issues, memory settings, found nothing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1511) pdfMerger App produces Garbage
[
https://issues.apache.org/jira/browse/PDFBOX-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097192#comment-14097192
]
Maruan Sahyoun commented on PDFBOX-1511:
[~tilman] Just to ensure that I understand you correctly. You mean the files
according to
{quote}
- a file with global resources
- to create an uncompressed copy where we shuffle the names of the resources
- merge it and see what happens.
{quote}
correct?
pdfMerger App produces Garbage
--
Key: PDFBOX-1511
URL: https://issues.apache.org/jira/browse/PDFBOX-1511
Project: PDFBox
Issue Type: Bug
Components: Utilities
Affects Versions: 1.7.1
Environment: Win XP; Windows Server 2008 R2; java version 1.6.0_21,
Reporter: Michael Huber
Fix For: 1.8.7, 2.0.0
Attachments: 078117u1.pdf, 078117u2.pdf, 078118.pdf, 1.pdf, 2.pdf,
PDFMergerUtility.java, PDFMergerUtility.java.diff, PdfRenderer.java,
targetPdfMergeJava.pdf, targetPdfMergeUtilityApp.pdf
pdfbox Utility pdfMerger produces a merged document containing garbage. All
merged pdf files are contained but Strings are destroyed.
The source pdf files are created with graphviz and are readable without error
or disturbance both with Acrobat X and pdfbox pdfDebug Utility.
Another astounding thing is that a handcoded merger using pdfMergerUtility
class works fine when run within Eclipse Juno and creates same garbage when
run from cmd line (pls. see attached source PdfRenderer.java)
I checked everything that comes in mind to find the differences, e.g. Java
version, encoding/codepage issues, memory settings, found nothing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PDFBOX-1511) pdfMerger App produces Garbage
[ https://issues.apache.org/jira/browse/PDFBOX-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097200#comment-14097200 ] Tilman Hausherr commented on PDFBOX-1511: - Yes. The resources that we shuffle should be of the same kind, i.e. only fonts, or only images. pdfMerger App produces Garbage -- Key: PDFBOX-1511 URL: https://issues.apache.org/jira/browse/PDFBOX-1511 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.7.1 Environment: Win XP; Windows Server 2008 R2; java version 1.6.0_21, Reporter: Michael Huber Fix For: 1.8.7, 2.0.0 Attachments: 078117u1.pdf, 078117u2.pdf, 078118.pdf, 1.pdf, 2.pdf, PDFMergerUtility.java, PDFMergerUtility.java.diff, PdfRenderer.java, targetPdfMergeJava.pdf, targetPdfMergeUtilityApp.pdf pdfbox Utility pdfMerger produces a merged document containing garbage. All merged pdf files are contained but Strings are destroyed. The source pdf files are created with graphviz and are readable without error or disturbance both with Acrobat X and pdfbox pdfDebug Utility. Another astounding thing is that a handcoded merger using pdfMergerUtility class works fine when run within Eclipse Juno and creates same garbage when run from cmd line (pls. see attached source PdfRenderer.java) I checked everything that comes in mind to find the differences, e.g. Java version, encoding/codepage issues, memory settings, found nothing. -- This message was sent by Atlassian JIRA (v6.2#6252)
Jenkins build is back to normal : PDFBox 1.8.x (JDK7) » Apache Preflight #60
See https://builds.apache.org/job/PDFBox%201.8.x%20(JDK7)/org.apache.pdfbox$preflight/60/
Jenkins build is back to normal : PDFBox 1.8.x (JDK7) #60
See https://builds.apache.org/job/PDFBox%201.8.x%20(JDK7)/60/changes
Jenkins build is back to normal : PDFBox 1.8.x #243
See https://builds.apache.org/job/PDFBox%201.8.x/243/changes
Re: PDFBox 1.8.7 release?
On 14 Aug 2014, at 00:06, Andreas Lehmkühler andr...@lehmi.de wrote: Hi, Maruan Sahyoun sahy...@fileaffairs.de hat am 11. August 2014 um 19:18 geschrieben: Am 11.08.2014 um 18:59 schrieb Andreas Lehmkuehler andr...@lehmi.de: Hi, Am 11.08.2014 18:35, schrieb John Hewson: Andreas, What I had been thinking was that now that 2.0 is getting closer that me wight want to do less with 1.8, but I agree with you that we don’t need any fixed rules, staying flexible is better. It sounds like we might want to think about some guidelines for 1.8 after 2.0 is released to avoid a “Windows XP” situation, but we’re not at that point yet. Yes, good point. Hopefully 1.8.7 will be the last 1.8 release before 2.0 :-) As 2.0 breaks the current API (which is intended) I suspect that there will be bugfixes for 1.8 needed for some time. Of course, but we shouldn't make it to easy for users to stay with the 1.8 version once 2.0 is out. We should limit that support to bugfixes for bigger issues and shouldn't include any new features. I guess that's what John has in his mind saying that we should avoid a Windows XP situation. Exactly. Users who are happy with 1.8 and want to stick with it can do so, the jars will always be available. But users who want change will have to do their part and move to 2.0, because PDFBox committers are too limited a resource. Critical bug fixes and security fixes are the exception, but these should be kept to a minimum. Microsoft supported Windows XP for 12 years, with no real benefit - everyone had to migrate off it anyway, deferring the task ultimately made it bigger. -- John BR Andreas Lehmkühler Cheers -- John BR Andreas Lehmkühler On 11 Aug 2014, at 03:57, Andreas Lehmkühler andr...@lehmi.de wrote: Hi, John Hewson j...@jahewson.com hat am 7. August 2014 um 18:48 geschrieben: Perhaps we should stop adding new features to 1.8, and only fix the most problematic bugs? We never were that strict about the contents of a bugfix release in the past. We always added some improvements or new features. Most of them were small and/or hadn't a huge impact on the code/functionality. Some were added because people were eagerly waiting for them. There aren't any rules what to add or not and IMHO we don't need any. BR Andreas Lehmkühler -- John On 7 Aug 2014, at 09:11, Tilman Hausherr thaush...@t-online.de wrote: +1 but after I've ported the GSoC2014-improved shading package to 1.8 Tilman Am 07.08.2014 12:35, schrieb Andreas Lehmkühler: Hi, there is already a number of solved issues and I guess it's time for a new bugfix release. I'm working on PDFBOX-2250 and I'd like to finish that first but how about a new release in 2 or 3 weeks from now? WDYT? BR Andreas Lehmkühler
