Re: [DISCUSS] Switch to java 1.6
Hi, one thing we might want to consider is Java support on Android. Looking at some issues in Jira people are using PDfBox on Android devices. Some of the older Android versions are in line with 1.5. Don't know if a) we should target Android and b) which version we should support as a minimum requirement. BR Maruan Sahyoun Am 28.04.2013 um 19:35 schrieb Andreas Lehmkuehler : > Hi, > > there was already a discussion about switching to java 1.6. As this is a very > important topic I'd like to move the discussion to a separate thread. > > There are a lot of good reasons to switch to java 1.6 and until now everybody > agrees to do the switch. > > Is there anybody who has at least one good reason not to go on and switch to > java 1.6? > > BR > Andreas Lehmkühler
Re: [DISCUSS] Switch to java 1.6
Hi, Am 28.04.2013 22:11, schrieb Alin Mazilu: Hello, I got one: JavaFX. I use PDFBox in projects that use JavaFX 1.7/1.8. The discussion is about the minimum requirements, so that I can't see any blocker here. Alin On Sun, Apr 28, 2013 at 1:35 PM, Andreas Lehmkuehler wrote: Hi, there was already a discussion about switching to java 1.6. As this is a very important topic I'd like to move the discussion to a separate thread. There are a lot of good reasons to switch to java 1.6 and until now everybody agrees to do the switch. Is there anybody who has at least one good reason not to go on and switch to java 1.6? BR Andreas Lehmkühler BR Andreas Lehmkühler
Re: [DISCUSS] Switch to java 1.6
Hello, I got one: JavaFX. I use PDFBox in projects that use JavaFX 1.7/1.8. Alin On Sun, Apr 28, 2013 at 1:35 PM, Andreas Lehmkuehler wrote: > Hi, > > there was already a discussion about switching to java 1.6. As this is a > very > important topic I'd like to move the discussion to a separate thread. > > There are a lot of good reasons to switch to java 1.6 and until now > everybody > agrees to do the switch. > > Is there anybody who has at least one good reason not to go on and switch > to > java 1.6? > > BR > Andreas Lehmkühler >
[DISCUSS] Switch to java 1.6
Hi, there was already a discussion about switching to java 1.6. As this is a very important topic I'd like to move the discussion to a separate thread. There are a lot of good reasons to switch to java 1.6 and until now everybody agrees to do the switch. Is there anybody who has at least one good reason not to go on and switch to java 1.6? BR Andreas Lehmkühler
[jira] [Updated] (PDFBOX-1584) Add unit test for RandomAccessFileOutputStream
[ https://issues.apache.org/jira/browse/PDFBOX-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Kjellberg updated PDFBOX-1584: -- Attachment: TestRandomAccessFileOutputStream_diff.txt > Add unit test for RandomAccessFileOutputStream > -- > > Key: PDFBOX-1584 > URL: https://issues.apache.org/jira/browse/PDFBOX-1584 > Project: PDFBox > Issue Type: Test > Components: Parsing >Affects Versions: 1.8.1 >Reporter: Fredrik Kjellberg >Priority: Minor > Attachments: TestRandomAccessFileOutputStream_diff.txt > > > This patch includes a unit test for RandomAccessFileOutputStream -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1584) Add unit test for RandomAccessFileOutputStream
Fredrik Kjellberg created PDFBOX-1584: - Summary: Add unit test for RandomAccessFileOutputStream Key: PDFBOX-1584 URL: https://issues.apache.org/jira/browse/PDFBOX-1584 Project: PDFBox Issue Type: Test Components: Parsing Affects Versions: 1.8.1 Reporter: Fredrik Kjellberg Priority: Minor This patch includes a unit test for RandomAccessFileOutputStream -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Trunk is now 2.0.0-SNAPSHOT
Hi, I've updated the trunk version to 2.0.0-SNAPSHOT after achieving lazy consensus about our next big goal. I've renamed the 1.9.0 JIRA version to 1.8.2. BR Andreas Lehmkühler
[jira] [Resolved] (PDFBOX-1583) wasted work in PDDocument.addSignature(...)
[ https://issues.apache.org/jira/browse/PDFBOX-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Lehmkühler resolved PDFBOX-1583. Resolution: Fixed Fix Version/s: 1.8.2 Assignee: Andreas Lehmkühler I added the patch in revision 1476795 as proposed. Thanks for the contribution > wasted work in PDDocument.addSignature(...) > --- > > Key: PDFBOX-1583 > URL: https://issues.apache.org/jira/browse/PDFBOX-1583 > Project: PDFBox > Issue Type: Bug >Affects Versions: 1.8.1 >Reporter: Adrian Nistor >Assignee: Andreas Lehmkühler > Labels: patch > Fix For: 1.8.2 > > Attachments: patch.diff > > > The problem appears in version 1.8.1 and in revision 1476791. I > attached a one-line patch that fixes it. This problem is similar to > the already fixed PDFBOX-1447 and PDFBOX-1457. > In method "PDDocument.addSignature", the loop over "cosObjects" should > break immediately after "annotNotFound" and "sigFieldNotFound" are set > to "false". All the iterations after "annotNotFound" and > "sigFieldNotFound" are set to "false" do not perform any useful work > because the two "if" statements performing useful work depend on > "annotNotFound" and "sigFieldNotFound". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1583) wasted work in PDDocument.addSignature(...)
Adrian Nistor created PDFBOX-1583: - Summary: wasted work in PDDocument.addSignature(...) Key: PDFBOX-1583 URL: https://issues.apache.org/jira/browse/PDFBOX-1583 Project: PDFBox Issue Type: Bug Affects Versions: 1.8.1 Reporter: Adrian Nistor Attachments: patch.diff The problem appears in version 1.8.1 and in revision 1476791. I attached a one-line patch that fixes it. This problem is similar to the already fixed PDFBOX-1447 and PDFBOX-1457. In method "PDDocument.addSignature", the loop over "cosObjects" should break immediately after "annotNotFound" and "sigFieldNotFound" are set to "false". All the iterations after "annotNotFound" and "sigFieldNotFound" are set to "false" do not perform any useful work because the two "if" statements performing useful work depend on "annotNotFound" and "sigFieldNotFound". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1583) wasted work in PDDocument.addSignature(...)
[ https://issues.apache.org/jira/browse/PDFBOX-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Nistor updated PDFBOX-1583: -- Attachment: patch.diff patch > wasted work in PDDocument.addSignature(...) > --- > > Key: PDFBOX-1583 > URL: https://issues.apache.org/jira/browse/PDFBOX-1583 > Project: PDFBox > Issue Type: Bug >Affects Versions: 1.8.1 >Reporter: Adrian Nistor > Labels: patch > Attachments: patch.diff > > > The problem appears in version 1.8.1 and in revision 1476791. I > attached a one-line patch that fixes it. This problem is similar to > the already fixed PDFBOX-1447 and PDFBOX-1457. > In method "PDDocument.addSignature", the loop over "cosObjects" should > break immediately after "annotNotFound" and "sigFieldNotFound" are set > to "false". All the iterations after "annotNotFound" and > "sigFieldNotFound" are set to "false" do not perform any useful work > because the two "if" statements performing useful work depend on > "annotNotFound" and "sigFieldNotFound". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1582) Issues with available() and skip() on RandomAccessFileInputStream
[ https://issues.apache.org/jira/browse/PDFBOX-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Kjellberg updated PDFBOX-1582: -- Attachment: TestRandomAccessFileInputStream_diff.txt > Issues with available() and skip() on RandomAccessFileInputStream > - > > Key: PDFBOX-1582 > URL: https://issues.apache.org/jira/browse/PDFBOX-1582 > Project: PDFBox > Issue Type: Test > Components: Parsing >Affects Versions: 1.8.1 >Reporter: Fredrik Kjellberg >Priority: Minor > Attachments: TestRandomAccessFileInputStream_diff.txt > > > I'm trying to track down a strange bug when parsing PDF files on the IBM JDK > that sometimes is giving me stack traces from RandomAccessFile classes. I > started by writing unit tests for the PDFBox classes to verify their behavior > and found a few issues. Can someone more familiar with the PDFBox code base > please check the unit test I wrote and give advise on how it is supposed to > work? I've added a TODO for each line where I'm in doubt what should be > returned. > This unit test is for RandomAccessFileInputStream where I've found a few > issues. The first is what available() is supposed to return if the input > stream tries to go beyond the EOF of the underlying file? When reading single > bytes it count down while still returning -1 and when reading a buffer, it is > returning what it think is left. The JDK documentation states that > available() may not return the absolute truth, so perhaps returning what it > think is left is okay, but it shouldn't count down in single reads beyond > EOF? Maybe it should be set to zero once a read beyond the EOF is detected? > Another issue is with skip() where the JDK documentation states that it > should return the actual number of bytes skipped. When skipping beyond the > EOF of the file, it does not return the actual number of skipped bytes. Also > the underlying file is not updated with the new position. Is this correct > behavior? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1582) Issues with available() and skip() on RandomAccessFileInputStream
Fredrik Kjellberg created PDFBOX-1582: - Summary: Issues with available() and skip() on RandomAccessFileInputStream Key: PDFBOX-1582 URL: https://issues.apache.org/jira/browse/PDFBOX-1582 Project: PDFBox Issue Type: Test Components: Parsing Affects Versions: 1.8.1 Reporter: Fredrik Kjellberg Priority: Minor I'm trying to track down a strange bug when parsing PDF files on the IBM JDK that sometimes is giving me stack traces from RandomAccessFile classes. I started by writing unit tests for the PDFBox classes to verify their behavior and found a few issues. Can someone more familiar with the PDFBox code base please check the unit test I wrote and give advise on how it is supposed to work? I've added a TODO for each line where I'm in doubt what should be returned. This unit test is for RandomAccessFileInputStream where I've found a few issues. The first is what available() is supposed to return if the input stream tries to go beyond the EOF of the underlying file? When reading single bytes it count down while still returning -1 and when reading a buffer, it is returning what it think is left. The JDK documentation states that available() may not return the absolute truth, so perhaps returning what it think is left is okay, but it shouldn't count down in single reads beyond EOF? Maybe it should be set to zero once a read beyond the EOF is detected? Another issue is with skip() where the JDK documentation states that it should return the actual number of bytes skipped. When skipping beyond the EOF of the file, it does not return the actual number of skipped bytes. Also the underlying file is not updated with the new position. Is this correct behavior? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1336) JVM Crashes on Linux OS + Sun JVM + PDFBox
[ https://issues.apache.org/jira/browse/PDFBOX-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644013#comment-13644013 ] Christian Kohlschütter commented on PDFBOX-1336: I guess PDFBOX-1580 fixes this issue. > JVM Crashes on Linux OS + Sun JVM + PDFBox > -- > > Key: PDFBOX-1336 > URL: https://issues.apache.org/jira/browse/PDFBOX-1336 > Project: PDFBox > Issue Type: Bug >Affects Versions: 1.7.0 > Environment: CentOS 5.6 > Sun JVM Java version: 6 update 31 > Tomcat 7.0.26 >Reporter: Ann Addicks >Priority: Critical > Attachments: hs_err_pid16603.log, pdfcrowd_1334685364.pdf > > > A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x796af64d, pid=16603, tid=2021653392 > # > # JRE version: 6.0_31-b04 > # Java VM: Java HotSpot(TM) Server VM (20.6-b01 mixed mode linux-x86 ) > # Problematic frame: > # C [libfontmanager.so+0x1e64d] imaginary long double+0x7d > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > I can provide the full error, please let me know. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (PDFBOX-1336) JVM Crashes on Linux OS + Sun JVM + PDFBox
[ https://issues.apache.org/jira/browse/PDFBOX-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644013#comment-13644013 ] Christian Kohlschütter edited comment on PDFBOX-1336 at 4/28/13 2:07 PM: - I guess PDFBOX-1580 fixes the crash. was (Author: c...@newsclub.de): I guess PDFBOX-1580 fixes this issue. > JVM Crashes on Linux OS + Sun JVM + PDFBox > -- > > Key: PDFBOX-1336 > URL: https://issues.apache.org/jira/browse/PDFBOX-1336 > Project: PDFBox > Issue Type: Bug >Affects Versions: 1.7.0 > Environment: CentOS 5.6 > Sun JVM Java version: 6 update 31 > Tomcat 7.0.26 >Reporter: Ann Addicks >Priority: Critical > Attachments: hs_err_pid16603.log, pdfcrowd_1334685364.pdf > > > A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x796af64d, pid=16603, tid=2021653392 > # > # JRE version: 6.0_31-b04 > # Java VM: Java HotSpot(TM) Server VM (20.6-b01 mixed mode linux-x86 ) > # Problematic frame: > # C [libfontmanager.so+0x1e64d] imaginary long double+0x7d > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > I can provide the full error, please let me know. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1426) JVM crashes when trying to process the attached pdf's
[ https://issues.apache.org/jira/browse/PDFBOX-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644012#comment-13644012 ] Christian Kohlschütter commented on PDFBOX-1426: Maybe PDFBOX-1580 fixes this issue as well? > JVM crashes when trying to process the attached pdf's > - > > Key: PDFBOX-1426 > URL: https://issues.apache.org/jira/browse/PDFBOX-1426 > Project: PDFBox > Issue Type: Bug >Affects Versions: 1.7.1 > Environment: OS: Windows Server 2003 family Build 3790 Service Pack 2 >Reporter: Alejandro Cerdas >Priority: Critical > Labels: patch > Attachments: Delta Ticket.pdf, MERX Subscription Fee - Final.pdf > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d703bf9, pid=5384, > tid=4788 > # > # JRE version: 6.0_18-b07 > # Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode windows-x86 ) > # Problematic frame: > # C [fontmanager.dll+0x13bf9] > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > --- T H R E A D --- > Current thread (0x6a057400): JavaThread "ajp-127.0.0.1-8009-11" daemon > [_thread_in_native, id=4788, stack(0x6cf1,0x6cf6)] > siginfo: ExceptionCode=0xc005, reading address 0x0010 > Registers: > EAX=0x, EBX=0x, ECX=0x000a, EDX=0x69b1c6c8 > ESP=0x6cf5e89c, EBP=0x6cf5e8b4, ESI=0x6aadfdd0, EDI=0x6aadfdd0 > EIP=0x6d703bf9, EFLAGS=0x00010246 > Top of Stack: (sp=0x6cf5e89c) > 0x6cf5e89c: 6aadfdd0 636d6170 6aadfdd0 > 0x6cf5e8ac: 6d703d33 685e4130 6cf5e924 6d6f3ced > 0x6cf5e8bc: 6aadfdd0 0062 6cf5e920 > 0x6cf5e8cc: 6aadfdd0 685e4130 0001 > 0x6cf5e8dc: 0007 > 0x6cf5e8ec: 6a8a3840 > 0x6cf5e8fc: 6a8a3c98 > 0x6cf5e90c: 6a8a3838 > Instructions: (pc=0x6d703bf9) > 0x6d703be9: 75 51 57 68 70 61 6d 63 56 e8 6f fd ff ff 6a 00 > 0x6d703bf9: ff 70 10 ff 70 0c ff b6 88 00 00 00 ff b6 90 00 > Stack: [0x6cf1,0x6cf6], sp=0x6cf5e89c, free space=13a6cf5e3d8k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [fontmanager.dll+0x13bf9] > C [fontmanager.dll+0x3ced] > C [fontmanager.dll+0x3da3] > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j sun.font.FileFont.getGlyphImage(JI)J+0 > J sun.font.FileFontStrike.getGlyphMetrics(IZ)Ljava/awt/geom/Point2D$Float; > J sun.font.FileFontStrike.getGlyphMetrics(I)Ljava/awt/geom/Point2D$Float; > J sun.font.StandardGlyphVector.initPositions()V > J > sun.font.GlyphList.setFromGlyphVector(Lsun/java2d/loops/FontInfo;Ljava/awt/font/GlyphVector;FF)V > J > sun.java2d.pipe.GlyphListPipe.drawGlyphVector(Lsun/java2d/SunGraphics2D;Ljava/awt/font/GlyphVector;FF)V > j > sun.java2d.pipe.ValidatePipe.drawGlyphVector(Lsun/java2d/SunGraphics2D;Ljava/awt/font/GlyphVector;FF)V+17 > J sun.java2d.SunGraphics2D.drawGlyphVector(Ljava/awt/font/GlyphVector;FF)V > j > org.apache.pdfbox.pdmodel.font.PDSimpleFont.writeFont(Ljava/awt/Graphics2D;Ljava/awt/geom/AffineTransform;FFLjava/awt/font/GlyphVector;)V+63 > j > org.apache.pdfbox.pdmodel.font.PDSimpleFont.drawString(Ljava/lang/String;[ILjava/awt/Graphics;FLjava/awt/geom/AffineTransform;FF)V+253 > j > org.apache.pdfbox.pdfviewer.PageDrawer.processTextPosition(Lorg/apache/pdfbox/util/TextPosition;)V+436 > J org.apache.pdfbox.util.PDFStreamEngine.processEncodedText([B)V > J > org.apache.pdfbox.util.operator.ShowTextGlyph.process(Lorg/apache/pdfbox/util/PDFOperator;Ljava/util/List;)V > J > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(Lorg/apache/pdfbox/cos/COSStream;)V > j > org.apache.pdfbox.util.PDFStreamEngine.processSubStream(Lorg/apache/pdfbox/pdmodel/PDPage;Lorg/apache/pdfbox/pdmodel/PDResources;Lorg/apache/pdfbox/cos/COSStream;)V+20 > j > org.apache.pdfbox.util.PDFStreamEngine.processStream(Lorg/apache/pdfbox/pdmodel/PDPage;Lorg/apache/pdfbox/pdmodel/PDResources;Lorg/apache/pdfbox/cos/COSStream;)V+43 > j > org.apache.pdfbox.pdfviewer.PageDrawer.drawPage(Ljava/awt/Graphics;Lorg/apache/pdfbox/pdmodel/PDPage;Ljava/awt/Dimension;)V+80 > j > org.apache.pdfbox.pdmodel.PDPage.convertToImage(II)Ljava/awt/image/BufferedImage;+200 > j > org.apache.pdfbox.pdmodel.PDPage.convertToImage()Ljava/awt/image/BufferedImage;+6 > j > com.otgs.ecom.utils.PdfProcessing.getPageAsImage(I)Ljava/awt/image/BufferedImage;+29 > j com.otgs.ecom.utils.ThumbnailGenerator.getPreviewForPD
