date:20140312


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
 ] 

John Hewson commented on PDFBOX-1977:
-

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather 
than a unit test, because it can't be used to identify regressions at the point 
they are committed, as the test data is different each time. Perhaps we need 
both kinds of test? Deterministic unit tests for catching regressions and known 
corner-cases, and randomized fuzz tests for increased coverage. What do you 
think?

{quote}
Had the seed in this test been constant, this issue would not have been found. 
It's because the seed is randomly selected that the test finally produced a 
sequence of data that provokes the bug.
{quote}

This is true, but it's also possible that a representative set of input data 
may have caught this regression at the time it was introduced.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
]

John Hewson edited comment on PDFBOX-1977 at 3/12/14 6:15 PM:
--

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather
than a unit test, because it can't be used to identify regressions at the point
they are committed, as the test data is different each time. Perhaps we need
both kinds of test? Deterministic unit tests for catching regressions and known
corner-cases, and randomized fuzz tests for increased coverage. What do you
think?

{quote}
Had the seed in this test been constant, this issue would not have been found.
It's because the seed is randomly selected that the test finally produced a
sequence of data that provokes the bug.
{quote}

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

was (Author: jahewson):
{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

This is true, but it's also possible that a representative set of input data
may have caught this regression at the time it was introduced.

LZWFilter fails / TestFilters is non-determinate

Key: PDFBOX-1977
URL: https://issues.apache.org/jira/browse/PDFBOX-1977
Project: PDFBox
Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
Labels: LZW
Fix For: 1.8.5, 2.0.0

TestFilters uses Random().nextLong() to generate a seed for random data,
which means that it is non-determinate. Depending on the seed value, the test
may fail or succeed.
Using the following seed results in the LZW filter failing:
final long seed = -6257105096642706464L;

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Need JBIG2 test image


Hi Martin,
No it's not attached, the dev mailing lists prevent this.
Btw these templates might be copyrighted. As a general rule, stuff that 
is created with thinking is copyrighted (Schöpfungshöhe in your and 
my language). A complicated test pattern would be copyrighted. And in 
Germany, every photograph is copyrighted. Google for Marions Kochbuch 
to understand what I mean :-)


Probably, Maruan's offer is the best. He's a committer so he can create 
something and give up the copyright to Apache.


Tilman

Am 12.03.2014 19:13, schrieb Martin Schröder:

2014-03-12 18:19 GMT+01:00 Tilman Hausherr thaush...@t-online.de:

I'd need a PDF with JBIG2 encoding that can be distributed. So it should not
have anything on it that is copyrighted, i.e. artwork or a real text. Just

One is attached; it's created from one of the images available on
http://jbig2dec.sourceforge.net/ubc/main.html

I should be able to produce pdfs with the images. :-)

Best
Martin

Re: Need JBIG2 test image

2014-03-12 Thread Martin Schröder

2014-03-12 19:23 GMT+01:00 Tilman Hausherr thaush...@t-online.de:
 Btw these templates might be copyrighted. As a general rule, stuff that is
 created with thinking is copyrighted (Schöpfungshöhe in your and my
 language). A complicated test pattern would be copyrighted. And in Germany,
 every photograph is copyrighted. Google for Marions Kochbuch to understand
 what I mean :-)

Hrm. The jbig2dec is now at
http://git.ghostscript.com/?p=jbig2dec.git;a=summary , so it's probably not
free enough for you.

Anyway: Give me a jbig2 and I can create pdfs of it with pdftex/luatex.

Best
   Martin

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932163#comment-13932163
 ] 

Tilman Hausherr commented on PDFBOX-1977:
-

This is getting into a philosophical discussion. But I think that both have 
their advantage, i.e. fixed tests, but also totally random tests that tell a 
seed so that they can be repeated later.

John, you didn't answer how you found this fail. I suspect that the test was 
run for a longer time, although a lucky hit might also be the reason. Anyway, 
it is great that you found it, because it showed a real problem.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Need JBIG2 test image

2014-03-12 Thread John Hewson

 No it's not attached, the dev mailing lists prevent this.
 Btw these templates might be copyrighted. As a general rule, stuff that is 
 created with thinking is copyrighted (Schöpfungshöhe in your and my 
 language). A complicated test pattern would be copyrighted. And in Germany, 
 every photograph is copyrighted. Google for Marions Kochbuch to understand 
 what I mean :-)

Yes, this is a good rule of thumb. But even when an image is under copyright 
there is the concept of “fair use”, that it may be used without permission for 
certain purposes, especially when the work is available publicly, free of 
charge - the public has important rights which are too often overlooked. 
Photographs fall under copyright in the UK also, however Google Images is still 
able to display thumbnails without asking for permission (technically in the UK 
this is “de minimis” copying as “fair use” is a US concept, but you get the 
idea).

Anyway, in this case the files look like they may be under the AGPL so we 
should probably not use them.

-- John

On 12 Mar 2014, at 11:23, Tilman Hausherr thaush...@t-online.de wrote:

 Hi Martin,
 No it's not attached, the dev mailing lists prevent this.
 Btw these templates might be copyrighted. As a general rule, stuff that is 
 created with thinking is copyrighted (Schöpfungshöhe in your and my 
 language). A complicated test pattern would be copyrighted. And in Germany, 
 every photograph is copyrighted. Google for Marions Kochbuch to understand 
 what I mean :-)
 
 Probably, Maruan's offer is the best. He's a committer so he can create 
 something and give up the copyright to Apache.
 
 Tilman
 
 Am 12.03.2014 19:13, schrieb Martin Schröder:
 2014-03-12 18:19 GMT+01:00 Tilman Hausherr thaush...@t-online.de:
 I'd need a PDF with JBIG2 encoding that can be distributed. So it should not
 have anything on it that is copyrighted, i.e. artwork or a real text. Just
 One is attached; it's created from one of the images available on
 http://jbig2dec.sourceforge.net/ubc/main.html
 
 I should be able to produce pdfs with the images. :-)
 
 Best
Martin

Re: Need JBIG2 test image


Am 12.03.2014 19:30, schrieb Martin Schröder:

Anyway: Give me a jbig2 and I can create pdfs of it with pdftex/luatex.

I don't have one :-(

Lets just wait for Maruan. But thanks for the offer, I am delighted of 
all the feedback I got.


Tilman

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
]

John Hewson edited comment on PDFBOX-1977 at 3/12/14 7:20 PM:
--

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather
than a unit test*, because it can't be used to identify regressions at the
point they are committed, as the test data is different each time. Perhaps we
need both kinds of test? Deterministic unit tests for catching regressions and
known corner-cases, and randomized fuzz tests for increased coverage. What do
you think?

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

* Meaning that when I say unit test I specifically mean regression test,
perhaps this makes me unusual.

was (Author: jahewson):
{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
]

John Hewson edited comment on PDFBOX-1977 at 3/12/14 7:21 PM:
--

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather
than a -unit test- regression test, because it can't be used to identify
regressions at the point they are committed, as the test data is different each
time. Perhaps we need both kinds of test? Deterministic unit tests for catching
regressions and known corner-cases, and randomized fuzz tests for increased
coverage. What do you think?

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

was (Author: jahewson):
{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather
than a -unit- regression test, because it can't be used to identify regressions
at the point they are committed, as the test data is different each time.
Perhaps we need both kinds of test? Deterministic unit tests for catching
regressions and known corner-cases, and randomized fuzz tests for increased
coverage. What do you think?

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
]

John Hewson edited comment on PDFBOX-1977 at 3/12/14 7:21 PM:
--

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

was (Author: jahewson):
{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

Thanks for the link, it's interesting; more what I'd call a fuzz test rather
than a unit test\*, because it can't be used to identify regressions at the
point they are committed, as the test data is different each time. Perhaps we
need both kinds of test? Deterministic unit tests for catching regressions and
known corner-cases, and randomized fuzz tests for increased coverage. What do
you think?

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

---

\* Meaning that when I say unit test I specifically mean regression test,
perhaps this makes me unusual.

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932107#comment-13932107
]

John Hewson edited comment on PDFBOX-1977 at 3/12/14 7:20 PM:
--

{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

---

\* Meaning that when I say unit test I specifically mean regression test,
perhaps this makes me unusual.

was (Author: jahewson):
{quote}
I wrote this brief blog post about Lucene's randomized tests a while back
{quote}

This is true, but it's also possible that a representative set of input data
could have caught this regression at the time it was introduced.

* Meaning that when I say unit test I specifically mean regression test,
perhaps this makes me unusual.

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932244#comment-13932244
]

Tilman Hausherr commented on PDFBOX-1975:
-

I implemented setting the dpi for JPEG images, based on code in Apache XML
graphics (hi there!). And I added a test for that dpi. This was done in rev.
1576867.

Sadly, it proves once more that java ImageIO doesn't have a general method to
set meta data.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

Key: PDFBOX-1975
URL: https://issues.apache.org/jira/browse/PDFBOX-1975
Project: PDFBox
Issue Type: Task
Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
Labels: imageio, test, tiff
Fix For: 2.0.0

Because of the problems with recent changes (see PDFBOX-1963), I will improve
the unit tests so that image resolution and compression is checked.
I found out that JPEGs don't have a resolution, BMP had the wrong resolution.
The fault wasn't in the java TIFF writer as I thought before, it is in the
java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets
them as pixels per mm instead of mm per pixel as per specification. The
JPEG writer throws an exception JFIF APP0 must be first marker after SOI.
The BMP writer can set the resolution, but the BMP reader doesn't read it.
(Some of this might be different depending on the version)

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932244#comment-13932244
]

Tilman Hausherr edited comment on PDFBOX-1975 at 3/12/14 7:36 PM:
--

I implemented setting the dpi for JPEG images, based on code in Apache XML
graphics (hi there!). And I added a test for that dpi. This was done in rev.
1576867 and 1576868.

Sadly, it proves once more that java ImageIO doesn't have a general method to
set meta data.

was (Author: tilman):
I implemented setting the dpi for JPEG images, based on code in Apache XML
graphics (hi there!). And I added a test for that dpi. This was done in rev.
1576867.

Sadly, it proves once more that java ImageIO doesn't have a general method to
set meta data.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932248#comment-13932248
 ] 

John Hewson commented on PDFBOX-1977:
-

{quote}
I like the name fuzz test!
{quote}

Yes it's fun, [Wikipedia|http://en.wikipedia.org/wiki/Fuzz_testing] has an 
article explaining the origin of the name.

{quote}
+1, we definitely need both. Whenever a bug is hit it's best to make a very 
specific non-randomized test case showing the bug, fix the bug, and then see 
that the test passes.
{quote}

Lets do that.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1978) Type1FontUtilTest is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1978:


Summary: Type1FontUtilTest is non-deterministic  (was: Type1FontUtilTest is 
non-determinate)

 Type1FontUtilTest is non-deterministic
 --

 Key: PDFBOX-1978
 URL: https://issues.apache.org/jira/browse/PDFBOX-1978
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Reporter: John Hewson

 Type1FontUtilTest uses java.util.Random to generate random test data, which 
 means that it is is non-determinate, it may fail randomly.
 We can still use java.util.Random to generate a stream of random data but it 
 must use a fixed seed value so that the test is not non-determinate.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1977) LZWFilter fails / TestFilters is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1977:


Summary: LZWFilter fails / TestFilters is non-deterministic  (was: 
LZWFilter fails / TestFilters is non-determinate)

 LZWFilter fails / TestFilters is non-deterministic
 --

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1978) Type1FontUtilTest is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1978:


Description: 
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
deterministic (regression test) functionality as well as the existing 
non-deterministic (fuzz test) functionality.

  was:
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
both a deterministic (regression test) functionality as well as the existing 
non-deterministic (fuzz test) functionality.


 Type1FontUtilTest is non-deterministic
 --

 Key: PDFBOX-1978
 URL: https://issues.apache.org/jira/browse/PDFBOX-1978
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Reporter: John Hewson

 Type1FontUtilTest uses java.util.Random to generate random test data, which 
 means that it is is non-deterministic.
 As discussed in PDFBOX-1977, we should alter this test to make sure that it 
 has deterministic (regression test) functionality as well as the existing 
 non-deterministic (fuzz test) functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1979) TypeTestingHelper is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1979:


Summary: TypeTestingHelper is non-deterministic  (was: TypeTestingHelper is 
non-determinate)

 TypeTestingHelper is non-deterministic
 --

 Key: PDFBOX-1979
 URL: https://issues.apache.org/jira/browse/PDFBOX-1979
 Project: PDFBox
  Issue Type: Bug
  Components: XmpBox
Reporter: John Hewson

 TypeTestingHelper generates random calendar data and random UUIDs for 
 testing, which means that it is non-deterministic.
 As discussed in PDFBOX-1977, we should alter this test to make sure that it 
 has deterministic (regression test) functionality as well as the existing 
 non-deterministic (fuzz test) functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1978) Type1FontUtilTest is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1978:


Description: 
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

We can still use java.util.Random to generate a stream of random data but it 
must use a fixed seed value so that the test is not non-determinate.

  was:
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-determinate, it may fail randomly.

We can still use java.util.Random to generate a stream of random data but it 
must use a fixed seed value so that the test is not non-determinate.


 Type1FontUtilTest is non-deterministic
 --

 Key: PDFBOX-1978
 URL: https://issues.apache.org/jira/browse/PDFBOX-1978
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Reporter: John Hewson

 Type1FontUtilTest uses java.util.Random to generate random test data, which 
 means that it is is non-deterministic.
 We can still use java.util.Random to generate a stream of random data but it 
 must use a fixed seed value so that the test is not non-determinate.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1978) Type1FontUtilTest is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1978:


Description: 
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
both a deterministic _regression test_ functionality as well as the existing 
non-deterministic _fuzz test_ functionality.

  was:
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

We can still use java.util.Random to generate a stream of random data but it 
must use a fixed seed value so that the test is not non-determinate.


 Type1FontUtilTest is non-deterministic
 --

 Key: PDFBOX-1978
 URL: https://issues.apache.org/jira/browse/PDFBOX-1978
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Reporter: John Hewson

 Type1FontUtilTest uses java.util.Random to generate random test data, which 
 means that it is is non-deterministic.
 As discussed in PDFBOX-1977, we should alter this test to make sure that it 
 has both a deterministic _regression test_ functionality as well as the 
 existing non-deterministic _fuzz test_ functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1978) Type1FontUtilTest is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1978:


Description: 
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
both a deterministic (regression test) functionality as well as the existing 
non-deterministic (fuzz test) functionality.

  was:
Type1FontUtilTest uses java.util.Random to generate random test data, which 
means that it is is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
both a deterministic _regression test_ functionality as well as the existing 
non-deterministic _fuzz test_ functionality.


 Type1FontUtilTest is non-deterministic
 --

 Key: PDFBOX-1978
 URL: https://issues.apache.org/jira/browse/PDFBOX-1978
 Project: PDFBox
  Issue Type: Bug
  Components: FontBox
Reporter: John Hewson

 Type1FontUtilTest uses java.util.Random to generate random test data, which 
 means that it is is non-deterministic.
 As discussed in PDFBOX-1977, we should alter this test to make sure that it 
 has both a deterministic (regression test) functionality as well as the 
 existing non-deterministic (fuzz test) functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1979) TypeTestingHelper is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1979:


Description: 
TypeTestingHelper generates random calendar data and random UUIDs for testing, 
which means that it is non-deterministic.

As discussed in PDFBOX-1977, we should alter this test to make sure that it has 
deterministic (regression test) functionality as well as the existing 
non-deterministic (fuzz test) functionality.

  was:
TypeTestingHelper generates random calendar data and random UUIDs for testing, 
which means that it is non-determinate and may pass or fail at random.

This test needs to use a representative set of test data instead of using 
random data.


 TypeTestingHelper is non-determinate
 

 Key: PDFBOX-1979
 URL: https://issues.apache.org/jira/browse/PDFBOX-1979
 Project: PDFBox
  Issue Type: Bug
  Components: XmpBox
Reporter: John Hewson

 TypeTestingHelper generates random calendar data and random UUIDs for 
 testing, which means that it is non-deterministic.
 As discussed in PDFBOX-1977, we should alter this test to make sure that it 
 has deterministic (regression test) functionality as well as the existing 
 non-deterministic (fuzz test) functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1980) TestCOSFloat is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1980:


Summary: TestCOSFloat is non-deterministic  (was: TestCOSFloat is 
non-determinate)

 TestCOSFloat is non-deterministic
 -

 Key: PDFBOX-1980
 URL: https://issues.apache.org/jira/browse/PDFBOX-1980
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: John Hewson

 TestCOSFloat generates random numbers for testing which means that it is 
 non-determinate and may pass or fail at random.
 This test needs to use a representative set of data.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1980) TestCOSFloat is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1980:


Description: 
TestCOSFloat generates random numbers for testing which means that it is 
non-deterministic.

Testing COSFloat on random data doesn't achieve much, because we know what 
numbers look like. Even taking into account the discussion in PDFBOX-1977, I 
suggest that it would be better to create a set of representative data with 
interesting edge-cases.

  was:
TestCOSFloat generates random numbers for testing which means that it is 
non-deterministic.

Testing COSFloat on random data doesn't achieve much, because we know what 
numbers look like It would be better to create a set of representative data 
with interesting edge-cases.


 TestCOSFloat is non-deterministic
 -

 Key: PDFBOX-1980
 URL: https://issues.apache.org/jira/browse/PDFBOX-1980
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: John Hewson

 TestCOSFloat generates random numbers for testing which means that it is 
 non-deterministic.
 Testing COSFloat on random data doesn't achieve much, because we know what 
 numbers look like. Even taking into account the discussion in PDFBOX-1977, I 
 suggest that it would be better to create a set of representative data with 
 interesting edge-cases.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1980) TestCOSFloat is non-deterministic


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1980:


Description: 
TestCOSFloat generates random numbers for testing which means that it is 
non-deterministic.

Testing COSFloat on random data doesn't achieve much, because we know what 
numbers look like It would be better to create a set of representative data 
with interesting edge-cases.

  was:
TestCOSFloat generates random numbers for testing which means that it is 
non-determinate and may pass or fail at random.

This test needs to use a representative set of data.


 TestCOSFloat is non-deterministic
 -

 Key: PDFBOX-1980
 URL: https://issues.apache.org/jira/browse/PDFBOX-1980
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: John Hewson

 TestCOSFloat generates random numbers for testing which means that it is 
 non-deterministic.
 Testing COSFloat on random data doesn't achieve much, because we know what 
 numbers look like It would be better to create a set of representative data 
 with interesting edge-cases.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (PDFBOX-1981) CryptographyException for file that isn't encrypted

Tilman Hausherr created PDFBOX-1981:
---

 Summary: CryptographyException for file that isn't encrypted
 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr


I get this with the attached file:

Exception in file: rennie-fresh-gebrauchsinformation.pdf
java.io.IOException: Error (CryptographyException) while creating security 
handler for decryption: The supplied password does not match either the owner 
or user password in the document
12.03.2014 20:44:06.063 ERROR [main] 
org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the object 
xref at offset 4543
at 
org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
at 
org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)

This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1981) CryptographyException for file that isn't encrypted


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-1981:


Attachment: Rennie-Fresh-gebrauchsinformation.pdf

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
  Labels: regression
 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Need JBIG2 test image


I got the image, thanks!
Tilman

Lets just wait for Maruan. But thanks for the offer, I am delighted of 
all the feedback I got.


Tilman

Re: Build Server Issues

2014-03-12 Thread Andreas Lehmkühler

Hi,

ubuntu2 has an issue with one of its discs. The slave was disabled until the 
problem is fixed.

BR
Andreas Lehmkühler


On 12. März 2014 15:06:39 MEZ, Andreas Lehmkühler andr...@lehmi.de wrote:
Hi,

Am 12.03.14 09:05, schrieb John Hewson:
 Hi All

 We’re getting lots of file system errors from the build server, for
example:


https://builds.apache.org/job/PDFBox-trunk/880/org.apache.pdfbox$fontbox/console
I've manually triggered another build but it didn't get better.

 Doesn’t have anything to do with recent changes. Maybe the disk is
full?
Yes maybe that's the reason. I've contacted the builds@ list.

 I’m off to bed :)
Sleep well :-)

 -- John

BR
Andreas Lehmkühler

[jira] [Assigned] (PDFBOX-1981) CryptographyException for file that isn't encrypted


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson reassigned PDFBOX-1981:
---

Assignee: John Hewson

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932377#comment-13932377
]

Tilman Hausherr commented on PDFBOX-1975:
-

I added a JBIG2 sample PDF to the three sample files (thanks [~msahyoun]!) in
rev 1576902.

In a next step, I will add a test that does a color count. I already have some
code for this elsewhere, but will modify it for the test.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1981) CryptographyException for file that isn't encrypted


[ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932407#comment-13932407
 ] 

John Hewson commented on PDFBOX-1981:
-

Confirmed. The cause of this regression was the I removed the following 
function:

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

with Arrays.equals and a length check. However, arraysEqual doesn't check if 
the arrays are equal! It's actually checking if the first _n_ elements are 
equal. I've fixed this and made it less confusing in revision 1576920. Thanks 
for the test case.

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1981) CryptographyException for file that isn't encrypted


[ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932407#comment-13932407
 ] 

John Hewson edited comment on PDFBOX-1981 at 3/12/14 9:27 PM:
--

Confirmed. The cause of this regression was that I removed the following 
function (and replaced it with Arrays.equals and a length check):

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

However, arraysEqual doesn't check if the arrays are equal! It's actually 
checking if the first _n_ elements are equal. I've fixed this and made it less 
confusing in revision 1576920. Thanks for the test case.


was (Author: jahewson):
Confirmed. The cause of this regression was that I removed the following 
function (replacing it with with Arrays.equals and a length check).

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

However, arraysEqual doesn't check if the arrays are equal! It's actually 
checking if the first _n_ elements are equal. I've fixed this and made it less 
confusing in revision 1576920. Thanks for the test case.

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Fix For: 2.0.0

 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1981) CryptographyException for file that isn't encrypted


[ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932407#comment-13932407
 ] 

John Hewson edited comment on PDFBOX-1981 at 3/12/14 9:26 PM:
--

Confirmed. The cause of this regression was that I removed the following 
function (replacing it with with Arrays.equals and a length check).

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

However, arraysEqual doesn't check if the arrays are equal! It's actually 
checking if the first _n_ elements are equal. I've fixed this and made it less 
confusing in revision 1576920. Thanks for the test case.


was (Author: jahewson):
Confirmed. The cause of this regression was that I removed the following 
function and replaced the following function (replacing it with with 
Arrays.equals and a length check).

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

However, arraysEqual doesn't check if the arrays are equal! It's actually 
checking if the first _n_ elements are equal. I've fixed this and made it less 
confusing in revision 1576920. Thanks for the test case.

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Fix For: 2.0.0

 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (PDFBOX-1981) CryptographyException for file that isn't encrypted


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson resolved PDFBOX-1981.
-

   Resolution: Fixed
Fix Version/s: 2.0.0

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Fix For: 2.0.0

 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1981) CryptographyException for file that isn't encrypted


[ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932407#comment-13932407
 ] 

John Hewson edited comment on PDFBOX-1981 at 3/12/14 9:25 PM:
--

Confirmed. The cause of this regression was that I replaced the following 
function with Arrays.equals and a length check:

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

However, arraysEqual doesn't check if the arrays are equal! It's actually 
checking if the first _n_ elements are equal. I've fixed this and made it less 
confusing in revision 1576920. Thanks for the test case.


was (Author: jahewson):
Confirmed. The cause of this regression that I replaced the following function:

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

with Arrays.equals and a length check. However, arraysEqual doesn't check if 
the arrays are equal! It's actually checking if the first _n_ elements are 
equal. I've fixed this and made it less confusing in revision 1576920. Thanks 
for the test case.

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Fix For: 2.0.0

 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1981) CryptographyException for file that isn't encrypted


[ 
https://issues.apache.org/jira/browse/PDFBOX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932407#comment-13932407
 ] 

John Hewson edited comment on PDFBOX-1981 at 3/12/14 9:25 PM:
--

Confirmed. The cause of this regression that I replaced the following function:

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

with Arrays.equals and a length check. However, arraysEqual doesn't check if 
the arrays are equal! It's actually checking if the first _n_ elements are 
equal. I've fixed this and made it less confusing in revision 1576920. Thanks 
for the test case.


was (Author: jahewson):
Confirmed. The cause of this regression was the I removed the following 
function:

{code}
private static final boolean arraysEqual( byte[] first, byte[] second, int 
count )
{
// both arrays have to have a minimum length of count
if (first.length  count || second.length  count)
{
return false;
}
for( int i=0; icount; i++ )
{
if( first[i] != second[i])
{
return false;
}
}
return true;
}
{code}

with Arrays.equals and a length check. However, arraysEqual doesn't check if 
the arrays are equal! It's actually checking if the first _n_ elements are 
equal. I've fixed this and made it less confusing in revision 1576920. Thanks 
for the test case.

 CryptographyException for file that isn't encrypted
 ---

 Key: PDFBOX-1981
 URL: https://issues.apache.org/jira/browse/PDFBOX-1981
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: John Hewson
  Labels: regression
 Fix For: 2.0.0

 Attachments: Rennie-Fresh-gebrauchsinformation.pdf


 I get this with the attached file:
 Exception in file: rennie-fresh-gebrauchsinformation.pdf
 java.io.IOException: Error (CryptographyException) while creating security 
 handler for decryption: The supplied password does not match either the owner 
 or user password in the document
 12.03.2014 20:44:06.063 ERROR [main] 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser:1888 - Can't find the 
 object xref at offset 4543
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.initialParse(NonSequentialPDFParser.java:444)
   at 
 org.apache.pdfbox.pdfparser.NonSequentialPDFParser.parse(NonSequentialPDFParser.java:741)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1152)
   at org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(PDDocument.java:1135)
   at pdfboxpageimageextraction.ExtractImages.doPdf(ExtractImages.java:203)
   at pdfboxpageimageextraction.ExtractImages.main(ExtractImages.java:86)
 This didn't happen ~ 2 weeks ago, so I suspect its a regression.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build became unstable: PDFBox-trunk #877

See https://builds.apache.org/job/PDFBox-trunk/877/changes

Jenkins build became unstable: PDFBox-trunk » Apache PDFBox #877

See 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$pdfbox/877/changes

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931438#comment-13931438
]

Tilman Hausherr commented on PDFBOX-1975:
-

I added JAI and levigo to the POM for test purposes only in rev 1576588.

I added levigo to enable a JBIG2 test in the near future, i.e. adding a non
copyrighted PDF file with JBIG2 to the 3 existing test files, and checking that
the result isn't empty.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression


[ 
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931450#comment-13931450
 ] 

John Hewson commented on PDFBOX-1975:
-

For 2) I meant specifically the ImageIOUtil.writeImage method which takes a 
filename, I presume that plenty of other people use the other methods, I'm just 
not sure how many people use that specific method, given that the filenames it 
produces are weird.

 Improve TestImageIOUtils unit tests to check image resolution and compression
 -

 Key: PDFBOX-1975
 URL: https://issues.apache.org/jira/browse/PDFBOX-1975
 Project: PDFBox
  Issue Type: Task
  Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
  Labels: imageio, test, tiff
 Fix For: 2.0.0


 Because of the problems with recent changes (see PDFBOX-1963), I will improve 
 the unit tests so that image resolution and compression is checked.
 I found out that JPEGs don't have a resolution, BMP had the wrong resolution. 
 The fault wasn't in the java TIFF writer as I thought before, it is in the 
 java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets 
 them as pixels per mm instead of mm per pixel as per specification. The 
 JPEG writer throws an exception JFIF APP0 must be first marker after SOI. 
 The BMP writer can set the resolution, but the BMP reader doesn't read it.
 (Some of this might be different depending on the version)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931438#comment-13931438
]

Tilman Hausherr edited comment on PDFBOX-1975 at 3/12/14 7:00 AM:
--

I added JAI and levigo to the parent POM for test purposes only in rev 1576588,
to the pdfbox POM in rev 1576598.

I added levigo to enable a JBIG2 test in the near future, i.e. adding a non
copyrighted PDF file with JBIG2 to the 3 existing test files, and checking that
the result isn't empty.

was (Author: tilman):
I added JAI and levigo to the POM for test purposes only in rev 1576588.

I added levigo to enable a JBIG2 test in the near future, i.e. adding a non
copyrighted PDF file with JBIG2 to the 3 existing test files, and checking that
the result isn't empty.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931472#comment-13931472
]

Tilman Hausherr commented on PDFBOX-1975:
-

I activated the unit tests for TIFFs in rev 1576599.

The BMP tests sometimes fail, because the BMP file is empty, so it is disabled
until I get an idea whats happening. (maybe not reentrant???)

I also notice that the GIF format isn't tested. Whats also missing is a simple
read test of the image.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Jenkins build is back to stable : PDFBox-trunk » Apache PDFBox #878

See 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$pdfbox/878/changes

Jenkins build is back to stable : PDFBox-trunk #878

See https://builds.apache.org/job/PDFBox-trunk/878/changes

[jira] [Commented] (PDFBOX-1973) Don't wrap Exceptions with COSVisitorException


[ 
https://issues.apache.org/jira/browse/PDFBOX-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931474#comment-13931474
 ] 

John Hewson commented on PDFBOX-1973:
-

SignatureException can also be removed (perhaps this is not surprising by now). 
It is thrown only twice, both times in PDDocument#addSignature.

The first use is to indicate that an attempt was made to add a signature to a 
PDF with zero pages, I've replaced this with an IllegalStateException, because 
the cause is API misuse. Perhaps a better behaviour would be to simply add a 
blank page to the document if is empty, we could consider doing this as an 
improvement.

The second use occurs when an attempt is made to add a visual signature to a 
document, but the signature content does not contain the required objects. The 
cause of this exception is, again, API misuse, specifically that invalid 
SignatureOptions were passed to the method, so I've changed this to an 
IllegalArgumentException.

Revision 1576603 makes these changes.

 Don't wrap Exceptions with COSVisitorException
 --

 Key: PDFBOX-1973
 URL: https://issues.apache.org/jira/browse/PDFBOX-1973
 Project: PDFBox
  Issue Type: Improvement
Reporter: John Hewson
Assignee: John Hewson
Priority: Minor

 COSVisitorException is redundant, it is a simple wrapper for 
 SignatureException, CryptographyException and NoSuchAlgorithmException and 
 should be replaced by those exceptions directly.
 For example, we can replace:
 public void write(PDDocument doc) throws COSVisitorException
 With:
 public void write(PDDocument doc) throws IOException, CryptographyException
 and so on...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1973) Don't wrap Exceptions with COSVisitorException


[ 
https://issues.apache.org/jira/browse/PDFBOX-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931474#comment-13931474
 ] 

John Hewson edited comment on PDFBOX-1973 at 3/12/14 7:18 AM:
--

SignatureException can also be removed (perhaps this is not surprising by now). 
It is thrown only twice, both times in PDDocument#addSignature.

The first use is to indicate that an attempt was made to add a signature to a 
PDF with zero pages, I've replaced this with an IllegalStateException, because 
the cause is API misuse. Perhaps a better behaviour would be to simply add a 
blank page to the document if it is empty, we could consider doing this as an 
improvement.

The second use occurs when an attempt is made to add a visual signature to a 
document, but the signature content does not contain the required objects. The 
cause of this exception is, again, API misuse, specifically that invalid 
SignatureOptions were passed to the method, so I've changed this to an 
IllegalArgumentException.

Revision 1576603 makes these changes.


was (Author: jahewson):
SignatureException can also be removed (perhaps this is not surprising by now). 
It is thrown only twice, both times in PDDocument#addSignature.

The first use is to indicate that an attempt was made to add a signature to a 
PDF with zero pages, I've replaced this with an IllegalStateException, because 
the cause is API misuse. Perhaps a better behaviour would be to simply add a 
blank page to the document if is empty, we could consider doing this as an 
improvement.

The second use occurs when an attempt is made to add a visual signature to a 
document, but the signature content does not contain the required objects. The 
cause of this exception is, again, API misuse, specifically that invalid 
SignatureOptions were passed to the method, so I've changed this to an 
IllegalArgumentException.

Revision 1576603 makes these changes.

 Don't wrap Exceptions with COSVisitorException
 --

 Key: PDFBOX-1973
 URL: https://issues.apache.org/jira/browse/PDFBOX-1973
 Project: PDFBox
  Issue Type: Improvement
Reporter: John Hewson
Assignee: John Hewson
Priority: Minor

 COSVisitorException is redundant, it is a simple wrapper for 
 SignatureException, CryptographyException and NoSuchAlgorithmException and 
 should be replaced by those exceptions directly.
 For example, we can replace:
 public void write(PDDocument doc) throws COSVisitorException
 With:
 public void write(PDDocument doc) throws IOException, CryptographyException
 and so on...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression


[ 
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931475#comment-13931475
 ] 

Tilman Hausherr commented on PDFBOX-1975:
-

John, your code
{code}
if (!new File(outDir).mkdirs())
{
throw new IOException(could not create output directory);
}
{code}
results in a fail on my own computer, when I do build and not clean and 
build.

 Improve TestImageIOUtils unit tests to check image resolution and compression
 -

 Key: PDFBOX-1975
 URL: https://issues.apache.org/jira/browse/PDFBOX-1975
 Project: PDFBox
  Issue Type: Task
  Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
  Labels: imageio, test, tiff
 Fix For: 2.0.0


 Because of the problems with recent changes (see PDFBOX-1963), I will improve 
 the unit tests so that image resolution and compression is checked.
 I found out that JPEGs don't have a resolution, BMP had the wrong resolution. 
 The fault wasn't in the java TIFF writer as I thought before, it is in the 
 java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets 
 them as pixels per mm instead of mm per pixel as per specification. The 
 JPEG writer throws an exception JFIF APP0 must be first marker after SOI. 
 The BMP writer can set the resolution, but the BMP reader doesn't read it.
 (Some of this might be different depending on the version)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1973) Exception Refactoring (Don't wrap Exceptions with COSVisitorException)


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1973:


Summary: Exception Refactoring (Don't wrap Exceptions with 
COSVisitorException)  (was: Don't wrap Exceptions with COSVisitorException)

 Exception Refactoring (Don't wrap Exceptions with COSVisitorException)
 --

 Key: PDFBOX-1973
 URL: https://issues.apache.org/jira/browse/PDFBOX-1973
 Project: PDFBox
  Issue Type: Improvement
Reporter: John Hewson
Assignee: John Hewson
Priority: Minor

 COSVisitorException is redundant, it is a simple wrapper for 
 SignatureException, CryptographyException and NoSuchAlgorithmException and 
 should be replaced by those exceptions directly.
 For example, we can replace:
 public void write(PDDocument doc) throws COSVisitorException
 With:
 public void write(PDDocument doc) throws IOException, CryptographyException
 and so on...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1973) Exception Refactoring (Don't wrap Exceptions with COSVisitorException)


[ 
https://issues.apache.org/jira/browse/PDFBOX-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931487#comment-13931487
 ] 

John Hewson commented on PDFBOX-1973:
-

Given that OutlineNotLocalException is now the only remaining non-deprecated 
checked exception in the org.apache.pdfbox.exceptions it's worth reviewing its 
functionality. OutlineNotLocalException is thrown only once, in 
PDOutlineItem#findDestinationPage to indicate that the outline has an action 
but that it does not have a page destination (e.g. a URI).

However, when an outline does not have an action, null is returned to indicate 
that there is no destination page. This is not so different from the case where 
the outline has an action but its destination is not a page, triggering a 
OutlineNotLocalException. Instead of throwing OutlineNotLocalException we 
should just return null as happens anyway for outlines without actions. This 
means that OutlineNotLocalException can be removed entirely.

Revision 1576610 makes this change.

 Exception Refactoring (Don't wrap Exceptions with COSVisitorException)
 --

 Key: PDFBOX-1973
 URL: https://issues.apache.org/jira/browse/PDFBOX-1973
 Project: PDFBox
  Issue Type: Improvement
Reporter: John Hewson
Assignee: John Hewson
Priority: Minor

 COSVisitorException is redundant, it is a simple wrapper for 
 SignatureException, CryptographyException and NoSuchAlgorithmException and 
 should be replaced by those exceptions directly.
 For example, we can replace:
 public void write(PDDocument doc) throws COSVisitorException
 With:
 public void write(PDDocument doc) throws IOException, CryptographyException
 and so on...



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931498#comment-13931498
 ] 

Tilman Hausherr commented on PDFBOX-1977:
-

Ouch :-( The decoded stream has a bonus of two extra bytes.


 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: John Hewson

 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Build failed in Jenkins: PDFBox-trunk #880

See https://builds.apache.org/job/PDFBox-trunk/880/changes

Changes:

[jahewson] PDFBOX-1973: Marked InvalidPasswordException as deprecated

[jahewson] PDFBOX-1973: Replace OutlineNotLocalException with null return value

[jahewson] PDFBOX-1973: Replace SignatureException with IllegalStateException 
and IllegalArgumentException

[tilman] PDFBOX-1975: activated unit tests for TIFF (resolution and compression)

--
Started by an SCM change
Building remotely on ubuntu2 in workspace 
https://builds.apache.org/job/PDFBox-trunk/ws/
Updating http://svn.apache.org/repos/asf/pdfbox/trunk at revision 
'2014-03-12T07:58:50.033 +'
U 
examples/src/main/java/org/apache/pdfbox/examples/signature/CreateVisibleSignature.java
U 
examples/src/main/java/org/apache/pdfbox/examples/signature/CreateSignature.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/CreateBlankPDF.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/CreateLandscapePDF.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/HelloWorldType1AfmPfb.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/HelloWorld.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/EmbeddedFiles.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/AddMessageToEachPage.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/ImageToPDF.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/UsingTextMatrix.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/ShowColorBoxes.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/RubberStampWithImage.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/AddImageToPDF.java
U 
examples/src/main/java/org/apache/pdfbox/examples/pdmodel/HelloWorldTTF.java
U 
examples/src/main/java/org/apache/pdfbox/examples/persistence/CopyDoc.java
U examples/src/main/java/org/apache/pdfbox/examples/fdf/SetField.java
U 
examples/src/test/java/org/apache/pdfbox/examples/pdmodel/TestRubberStampWithImage.java
U pdfbox/src/test/java/org/apache/pdfbox/cos/TestCOSString.java
U pdfbox/src/test/java/org/apache/pdfbox/cos/TestCOSBase.java
U pdfbox/src/test/java/org/apache/pdfbox/pdmodel/TestPDDocument.java
U 
pdfbox/src/test/java/org/apache/pdfbox/encryption/TestPublicKeyEncryption.java
U pdfbox/src/test/java/org/apache/pdfbox/util/TestLayerUtility.java
U pdfbox/src/test/java/org/apache/pdfbox/util/TestImageIOUtils.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSObject.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/ICOSVisitor.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSBase.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSArray.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSDocument.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSStream.java
U pdfbox/src/main/java/org/apache/pdfbox/cos/COSDictionary.java
U pdfbox/src/main/java/org/apache/pdfbox/pdmodel/PDDocument.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/common/COSStreamArray.java
U pdfbox/src/main/java/org/apache/pdfbox/pdmodel/fdf/FDFDocument.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/interactive/documentnavigation/outline/PDOutlineItem.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/interactive/digitalsignature/visible/PDVisibleSigProperties.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/interactive/digitalsignature/visible/PDFTemplateCreator.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/interactive/digitalsignature/visible/PDFTemplateStructure.java
U 
pdfbox/src/main/java/org/apache/pdfbox/pdmodel/interactive/digitalsignature/SignatureInterface.java
U pdfbox/src/main/java/org/apache/pdfbox/pdfwriter/COSWriter.java
U pdfbox/src/main/java/org/apache/pdfbox/util/PDFMergerUtility.java
D 
pdfbox/src/main/java/org/apache/pdfbox/exceptions/OutlineNotLocalException.java
D 
pdfbox/src/main/java/org/apache/pdfbox/exceptions/SignatureException.java
U 
pdfbox/src/main/java/org/apache/pdfbox/exceptions/InvalidPasswordException.java
U tools/src/main/java/org/apache/pdfbox/tools/PDFSplit.java
U tools/src/main/java/org/apache/pdfbox/tools/WriteDecodedDoc.java
U tools/src/main/java/org/apache/pdfbox/tools/OverlayPDF.java
At revision 1576626
Parsing POMs
maven3-agent.jar already up to date
maven3-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[trunk] $ /home/hudson/tools/java/latest1.6/bin/java -Xmx1g 
-XX:MaxPermSize=300m -cp

Build failed in Jenkins: PDFBox-trunk » Apache FontBox #880

See https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/880/

--
[INFO] 
[INFO] 
[INFO] Building Apache FontBox 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ fontbox ---
[INFO] Deleting 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target
[TASKS] Scanning folder 
'https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/' 
for files matching the pattern '**/*.java' - excludes: 
[TASKS] Found 84 files to scan for tasks
Found 11 open tasks.
[TASKS] Computing warning deltas based on reference build #878
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ fontbox ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ fontbox 
---
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/src/main/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ fontbox ---
[INFO] Compiling 80 source files to 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
fontbox ---
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
fontbox ---
[INFO] Compiling 4 source files to 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ fontbox ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports

---
 T E S T S
---
Running org.apache.fontbox.cff.Type1FontUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec
Exception in thread ThreadedStreamConsumer 
org.apache.maven.surefire.util.NestedRuntimeException: null; nested exception 
is org.apache.maven.surefire.report.ReporterException: Unable to create file 
for report: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports/org.apache.fontbox.cff.Type1FontUtilTest.txt
 (No such file or directory); nested exception is 
java.io.FileNotFoundException: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports/org.apache.fontbox.cff.Type1FontUtilTest.txt
 (No such file or directory)
org.apache.maven.surefire.report.ReporterException: Unable to create file for 
report: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports/org.apache.fontbox.cff.Type1FontUtilTest.txt
 (No such file or directory); nested exception is 
java.io.FileNotFoundException: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports/org.apache.fontbox.cff.Type1FontUtilTest.txt
 (No such file or directory)
java.io.FileNotFoundException: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/ws/target/surefire-reports/org.apache.fontbox.cff.Type1FontUtilTest.txt
 (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:194)
at java.io.FileOutputStream.init(FileOutputStream.java:145)
at java.io.FileWriter.init(FileWriter.java:73)
at 
org.apache.maven.plugin.surefire.report.FileReporter.testSetStarting(FileReporter.java:70)
at 
org.apache.maven.plugin.surefire.report.FileReporter.testSetCompleted(FileReporter.java:105)
at 
org.apache.maven.plugin.surefire.report.TestSetRunListener.testSetCompleted(TestSetRunListener.java:129)
at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:94)
at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
at java.lang.Thread.run(Thread.java:662)

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results

Build Server Issues

2014-03-12 Thread John Hewson

Hi All

We’re getting lots of file system errors from the build server, for example:

https://builds.apache.org/job/PDFBox-trunk/880/org.apache.pdfbox$fontbox/console

Doesn’t have anything to do with recent changes. Maybe the disk is full?

I’m off to bed :)

-- John

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression


[ 
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931509#comment-13931509
 ] 

John Hewson commented on PDFBOX-1975:
-

Argh, I always do mvn clean install, as does the build server. Maybe replace 
it with:

{code}
new File(outDir).mkdirs();
if (!new File(outDir).exists())
{
throw new IOException(could not create output directory);
}
{code}


 Improve TestImageIOUtils unit tests to check image resolution and compression
 -

 Key: PDFBOX-1975
 URL: https://issues.apache.org/jira/browse/PDFBOX-1975
 Project: PDFBox
  Issue Type: Task
  Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
  Labels: imageio, test, tiff
 Fix For: 2.0.0


 Because of the problems with recent changes (see PDFBOX-1963), I will improve 
 the unit tests so that image resolution and compression is checked.
 I found out that JPEGs don't have a resolution, BMP had the wrong resolution. 
 The fault wasn't in the java TIFF writer as I thought before, it is in the 
 java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets 
 them as pixels per mm instead of mm per pixel as per specification. The 
 JPEG writer throws an exception JFIF APP0 must be first marker after SOI. 
 The BMP writer can set the resolution, but the BMP reader doesn't read it.
 (Some of this might be different depending on the version)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1976) DocumentEncryption and PDFEncryption are deprecated and should be removed


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1976:


Summary: DocumentEncryption and PDFEncryption are deprecated and should be 
removed  (was: DocumentEncryption and DocumentEncryption are deprecated and 
should be removed)

 DocumentEncryption and PDFEncryption are deprecated and should be removed
 -

 Key: PDFBOX-1976
 URL: https://issues.apache.org/jira/browse/PDFBOX-1976
 Project: PDFBox
  Issue Type: Improvement
  Components: PDModel
Affects Versions: 2.0.0
Reporter: John Hewson
Priority: Minor

 DocumentEncryption and PDFEncryption in org.apache.pdfbox.encryption are 
 deprecated and should be removed in 2.0.0.
 The ARCFour class can then be made package-private in 
 org.apache.pdfbox.pdmodel.encryption.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [GSoC 2014]Implement shading with Coons and tensor-product patch meshes

2014-03-12 Thread Thimal Kempitiya

Hi Tilman,

 Thanks for the feedback. What you mean by the function calculations is it
function evaluation method can you please give more information on it.

About the proposal what advise can you give, is there specific way that
pdfbox expect apart form the gsoc format and is there any sample proposal
that we can get idea about writing proposal.


On Sun, Mar 9, 2014 at 8:42 PM, Tilman Hausherr thaush...@t-online.dewrote:

 Hello,

 Yes this is an interesting idea. It would save the recalculation of y1y0
 * (y + j - coords[1]) everytime. (Unless the java compiler detects this
 already)
 But don't expect too much from it - I believe more time is lost in
 function calculation (at least for types 1, 2 and 3 where functions are
 mandatory).

 Tilman


 Am 09.03.2014 15:12, schrieb Thimal Kempitiya:

  Thanks Tilman

 for optimization  in speed I think we need to facus on methods which use
 again and again like getRaster

 for the axial shading part current implementation in the getRaster method
 we calculate the x' value for the raster inside the for by for loop

   for (int j = 0; j  h; j++)
  {
  for (int i = 0; i  w; i++)
  {
  useBackground = false;
  double inputValue = x1x0 * (x + i - coords[0]);
  inputValue += y1y0 * (y + j - coords[1]);

 but all the time changing happen in the i and j values and they vary from
 0jh and 0iw
 so the contribution form i and j values can be calculation in separate 2
 for loops which run from 0 to h and 0 to w and calculate these values
 separately and put them in 2 arrays and when we need to evaluate we can
 add
 to the input value

 this will reduce the calculations inside the for by for loop and put them
 inside a 2 for loops this may be speed up the axial shading

 what you think about it


 On Fri, Mar 7, 2014 at 11:44 PM, Tilman Hausherr thaush...@t-online.de
 wrote:

  Am 07.03.2014 15:03, schrieb Thimal Kempitiya:

   Thanks Tilman for the feedback

 http://www.particleincell.com/blog/2012/quad-interpolation/ seems like
 opposite of what we are going need to check whether its work with this
 by
 implementing it (but can easily implement if we used library with matrix
 manipulations)

  This is really up to you :-)  Re: the pure math parts, its rather me
 who
 is learning something.

 Re: library, you can use the java standard library, or any library with
 Apache license or compatible license.



  can I know more about the optional part in the issue

 Optional:
 Review and optimize the complete shading package; implement cubic spline
 interpolation for type 0 (sampled) functions.

 where I can get more information about the cubic spline interpolation
 for
 type 0 (sampled) functions and in what aspects do you expect the
 optimization.

  Optimization for speed. Especially the axial shading. It gets slow when
 the shaded area is very large.

 The cubic spline interpolation is mentioned in the PDF spec at the type 0
 (sampled) functions, it is the part where order = 3. In the PDF spec,
 search for it, or for Additional entries specific to a type 0 function
 dictionary. Its really just a nice to have and of low priority.
 There's
 a note from adobe telling that it is not done for printing.

 Tilman





 On Tue, Mar 4, 2014 at 10:13 PM, Tilman Hausherr thaush...@t-online.de

 wrote:

   Am 04.03.2014 15:19, schrieb Thimal Kempitiya:

Hi,

  I checked the code related to the shading and studied the pdf spec
 related
 to the type 6. As I see it is going same as the type 4
From what I feel this is need to be done correct me if I'm wrong
 first need to get the 12 control points and colors related to each
 unit
 from stream

   Yes


create the 4 cubic Bézier curves which are boundaries of each patch
 (
 to

  find a Bézier curve it need 4 control points, two points are part of
 the
 curve )

   Yes, although they are not painted as a curve, the curve is part of
 a

 formula to find out whether a point is inside or outside the patch.

given point need to find the point which patch (I think this can be

  done[1]http://en.wikipedia.org/wiki/Plane_%28geometry%29but need

 research on that)
 find the color of the point using bi linear interpolation

   Probably. Although I'm not sure if the bilinear interpolation is the

 same
 as used for a rectangle.
 http://www.particleincell.com/blog/2012/quad-interpolation/
 I also don't know if the curves needs to be taken into account.


This has the same structure as the other shading types but need to

  structure to keep Bézier curves and patches
 and patches are connected as in the type4

   Yes, the data structure is similar. You can use existing code and do

 lot
 of copy  paste there, although there is some rearrangement needed as
 there
 are more points.



   I have to study the type 7 but I think its similar to this

   According to the spec, type 6 is a special case of type 7. I cannot

 tell
 whether it is enough to

Jenkins build is back to normal : PDFBox-trunk » Apache FontBox #881

See https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$fontbox/881/

Build failed in Jenkins: PDFBox-trunk » Apache JempBox #881

See https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/881/

--
[INFO] 
[INFO] 
[INFO] Building Apache JempBox 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ jempbox ---
[INFO] Deleting 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/target
[TASKS] Scanning folder 
'https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/' 
for files matching the pattern '**/*.java' - excludes: 
[TASKS] Found 27 files to scan for tasks
Found 4 open tasks.
[TASKS] Computing warning deltas based on reference build #878
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ jempbox ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ jempbox 
---
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/src/main/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ jempbox ---
[INFO] Compiling 24 source files to 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
jempbox ---
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/src/test/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
jempbox ---
[INFO] Compiling 3 source files to 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/target/test-classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] Failure executing javac, but could not parse the error:
javac: directory not found: 
https://builds.apache.org/job/PDFBox-trunk/org.apache.pdfbox$jempbox/ws/target/generated-test-sources/test-annotations
Usage: javac options source files
use -help for a list of possible options

[INFO] 1 error
[INFO] -

Build failed in Jenkins: PDFBox-trunk #881

See https://builds.apache.org/job/PDFBox-trunk/881/

--
Started by user lehmi
Building remotely on ubuntu2 in workspace 
https://builds.apache.org/job/PDFBox-trunk/ws/
Updating http://svn.apache.org/repos/asf/pdfbox/trunk at revision 
'2014-03-12T13:51:07.829 +'
At revision 1576739
no change for http://svn.apache.org/repos/asf/pdfbox/trunk since the previous 
build
Parsing POMs
maven3-agent.jar already up to date
maven3-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[trunk] $ /home/hudson/tools/java/latest1.6/bin/java -Xmx1g 
-XX:MaxPermSize=300m -cp 
/home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main 
/home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5
 /home/hudson/jenkins-slave/slave.jar 
/home/jenkins/jenkins-slave/maven3-interceptor.jar 
/home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 42344
===[JENKINS REMOTIchannel started
NG CAPACITY]===   log4j:WARN No appenders could be found for logger 
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
Executing Maven:  -B -f 
https://builds.apache.org/job/PDFBox-trunk/ws/trunk/pom.xml 
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 clean 
deploy -Ppedantic
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] PDFBox parent
[INFO] Apache FontBox
[INFO] Apache JempBox
[INFO] Apache XmpBox
[INFO] Apache PDFBox
[INFO] Apache Preflight
[INFO] Apache Preflight application
[INFO] Apache PDFBox webapp
[INFO] Apache PDFBox tools
[INFO] Apache PDFBox application
[INFO] Apache PDFBox examples
[INFO] PDFBox reactor
[INFO] 
[INFO] 
[INFO] Building PDFBox parent 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ pdfbox-parent ---
[INFO] Deleting 
https://builds.apache.org/job/PDFBox-trunk/ws/trunk/parent/target
[TASKS] Scanning folder 
'https://builds.apache.org/job/PDFBox-trunk/ws/trunk/parent' for files 
matching the pattern '**/*.java' - excludes: 
[TASKS] Found 0 files to scan for tasks
Found 0 open tasks.
[TASKS] Computing warning deltas based on reference build #880
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ pdfbox-parent 
---
[INFO] 
[INFO] --- maven-site-plugin:3.2:attach-descriptor (attach-descriptor) @ 
pdfbox-parent ---
[INFO] 
[INFO] --- apache-rat-plugin:0.10:check (default) @ pdfbox-parent ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: release.properties
[INFO] 1 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 1 licence.
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ pdfbox-parent 
---
[INFO] Installing 
https://builds.apache.org/job/PDFBox-trunk/ws/trunk/parent/pom.xml to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/pdfbox-parent-2.0.0-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ pdfbox-parent ---
Downloading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml
Downloaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml
 (611 B at 0.2 KB/sec)
Uploading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/pdfbox-parent-2.0.0-20140312.135244-234.pom
Uploaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/pdfbox-parent-2.0.0-20140312.135244-234.pom
 (10 KB at 31.8 KB/sec)
Downloading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/maven-metadata.xml
Downloaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/maven-metadata.xml
 (390 B at 1.7 KB/sec)
Uploading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml
Uploaded: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml
 (611 B at 2.2 KB/sec)
Uploading: 
https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/maven-metadata.xml
Uploaded:

Re: Build Server Issues

2014-03-12 Thread Andreas Lehmkühler


Hi,

Am 12.03.14 09:05, schrieb John Hewson:

Hi All

We’re getting lots of file system errors from the build server, for example:

https://builds.apache.org/job/PDFBox-trunk/880/org.apache.pdfbox$fontbox/console

I've manually triggered another build but it didn't get better.


Doesn’t have anything to do with recent changes. Maybe the disk is full?

Yes maybe that's the reason. I've contacted the builds@ list.


I’m off to bed :)

Sleep well :-)


-- John


BR
Andreas Lehmkühler

Re: email removal

2014-03-12 Thread Andreas Lehmkühler


Hi,

Am 11.03.14 22:43, schrieb WR Mettler:

Hello,

I need to get my email address removed from your distribution list.

How do I do that?


see http://pdfbox.apache.org/mailinglists.html


Thank you,

image001 http://www.desotosystems.com/

Bill Mettler

DeSoto Systems, Inc.

3080 Stage Post Dr.

Suite  # 108

Bartlett, TN 38133-4035

Phone: (901) 386-4293

Fax : (901) 386-3606

wrmett...@desotosystems.com

www.desotosystems.com




BR
Andreas Lehmkühler

Re: advanced signatures - the feature plans

2014-03-12 Thread Vakhtang koroghlishvili

Hello again,


This message acknowledges receipt of your ICLA, which has been filed in
the Apache Software Foundation records.
If you have been invited as a committer, please advise the project PMC that
your ICLA has been filed.


Vakhtang


On Mon, Mar 10, 2014 at 10:58 AM, Tilman Hausherr thaush...@t-online.dewrote:

 Hello Vakhtang,

 I remember you from some time ago without details, and that one of the
 committers was very satisfied with your code. Maybe that person will come
 back later, the weekend seems to be very quiet here.

 I'm answering you that you don't get frustrated. A few thoughts:

 - did Andreas already make you sign a CLA ( https://www.apache.org/
 licenses/ ) ? This is required when you submit real code, i.e. not just a
 small bugfix.
 - what JIRA issues are still open that you wish to have committed? Please
 name the ones with the smallest code first
 - if not already there and if possible / applicable, attach a test PDF
 (that isn't copyrighted except by you) or a unit test or whatever . This is
 just a general thought, e.g. you wrote code to create a new type of
 signature for a PDF. Then (if possible) you should also create a unit test
 that creates a signature for that PDF (if possible without user
 interaction), verifies that signature, modifies the PDF, and verifies the
 signature again and of course fails.
 - make sure that your code works with the current trunk, a lot was
 changed, although not related to signatures

 Tilman

 Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:

 Hello,

 how are you? :)

 You know , that I have already fix and implement some issues and new
 features which was about digital signature. I have already  created
 another
 new features too but I don't know  if I should create this patches in the
 pdfbox example project. I think, it's time to create another project named
 sign-box or something like that.  At the moment I have time and I can
 create that project  with very good  design architect and show you a patch
 or comitters  can create that project with existence features and then we
 will add new features step by step.

 I will write here, what we have at the moment, and what can we add too:

 At the moment, if we want to use pdfbox for the document signing , we can
 only do that thing:

 1. create basic digital signature with the time of CPU. *done*
 2. create digital signature with visible signature. *done* -that was my

 first contribution :-)

 This is very poor functionality and is not easy to use. It's just in the
 project named examples. It must have very easy API, as we sad before.

 I have implement and  add another functionality  nd created patches  some
 of them. some patches of new features is not updated in the jira, because
 I
 don't now  whether this must be in the example project or not.  So, at the
 moment I have that functionality:


 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
 signing
 time.  *done*


 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
 server time. Already *implemented* - I have uploaded a patch in our jira,

 some classes are in the pdfbox project and some classes are in the
 example project.

 3. signing document with timestamp server.  Already *implemented* and
 patch

 is uploaded in a jira ...

 4. creted document secure store and PADES LTV profile implementation
 (advanced signatures!).  I have already *implemented* this. I can create

 patch in the example project or create patch for sign-box too :) Tell me
 and I will create patch for one of them :)

 5. certificate chain verification  while signing process, against OCSP,
 CRL
 protocols (with advanced ocsp, crl certificate verifications too!) - I
 have
 already *implemented* this.

 I can create patch in the example project or create patch for sign-box and
 etc.. :-) :-) :-)


 Finally,   I want tell you that I like that project and I want to help you
 as I can.   I'm very well with digital signatures and I have very good
 experience with this. So, if you need, please tell me what should I do for
 this apache project?  :) I am with you :)

 Best regards,

Re: advanced signatures - the feature plans

2014-03-12 Thread John Hewson

Great, I will take a look at your patches today.

Thanks!

-- John

 On 12 Mar 2014, at 07:10, Vakhtang koroghlishvili 
 vakhtang.koroghlishv...@gmail.com wrote:
 
 Hello again,
 
 
 This message acknowledges receipt of your ICLA, which has been filed in
 the Apache Software Foundation records.
 If you have been invited as a committer, please advise the project PMC that
 your ICLA has been filed.
 
 
 Vakhtang
 
 
 On Mon, Mar 10, 2014 at 10:58 AM, Tilman Hausherr 
 thaush...@t-online.dewrote:
 
 Hello Vakhtang,
 
 I remember you from some time ago without details, and that one of the
 committers was very satisfied with your code. Maybe that person will come
 back later, the weekend seems to be very quiet here.
 
 I'm answering you that you don't get frustrated. A few thoughts:
 
 - did Andreas already make you sign a CLA ( https://www.apache.org/
 licenses/ ) ? This is required when you submit real code, i.e. not just a
 small bugfix.
 - what JIRA issues are still open that you wish to have committed? Please
 name the ones with the smallest code first
 - if not already there and if possible / applicable, attach a test PDF
 (that isn't copyrighted except by you) or a unit test or whatever . This is
 just a general thought, e.g. you wrote code to create a new type of
 signature for a PDF. Then (if possible) you should also create a unit test
 that creates a signature for that PDF (if possible without user
 interaction), verifies that signature, modifies the PDF, and verifies the
 signature again and of course fails.
 - make sure that your code works with the current trunk, a lot was
 changed, although not related to signatures
 
 Tilman
 
 Am 09.03.2014 18:21, schrieb Vakhtang koroghlishvili:
 
 Hello,
 
 how are you? :)
 
 You know , that I have already fix and implement some issues and new
 features which was about digital signature. I have already  created
 another
 new features too but I don't know  if I should create this patches in the
 pdfbox example project. I think, it's time to create another project named
 sign-box or something like that.  At the moment I have time and I can
 create that project  with very good  design architect and show you a patch
 or comitters  can create that project with existence features and then we
 will add new features step by step.
 
 I will write here, what we have at the moment, and what can we add too:
 
 At the moment, if we want to use pdfbox for the document signing , we can
 only do that thing:
 
 1. create basic digital signature with the time of CPU. *done*
 2. create digital signature with visible signature. *done* -that was my
 
 first contribution :-)
 
 This is very poor functionality and is not easy to use. It's just in the
 project named examples. It must have very easy API, as we sad before.
 
 I have implement and  add another functionality  nd created patches  some
 of them. some patches of new features is not updated in the jira, because
 I
 don't now  whether this must be in the example project or not.  So, at the
 moment I have that functionality:
 
 
 1. signing document with PADES-BES or PADES-BASIC profile, with CPU
 signing
 time.  *done*
 
 
 2. signing document with PADES-BES or PADES-BASIC profile, with timeStamp
 server time. Already *implemented* - I have uploaded a patch in our jira,
 
 some classes are in the pdfbox project and some classes are in the
 example project.
 
 3. signing document with timestamp server.  Already *implemented* and
 patch
 
 is uploaded in a jira ...
 
 4. creted document secure store and PADES LTV profile implementation
 (advanced signatures!).  I have already *implemented* this. I can create
 
 patch in the example project or create patch for sign-box too :) Tell me
 and I will create patch for one of them :)
 
 5. certificate chain verification  while signing process, against OCSP,
 CRL
 protocols (with advanced ocsp, crl certificate verifications too!) - I
 have
 already *implemented* this.
 
 I can create patch in the example project or create patch for sign-box and
 etc.. :-) :-) :-)
 
 
 Finally,   I want tell you that I like that project and I want to help you
 as I can.   I'm very well with digital signatures and I have very good
 experience with this. So, if you need, please tell me what should I do for
 this apache project?  :) I am with you :)
 
 Best regards,

[jira] [Assigned] (PDFBOX-1848) Time Stamp Document Level Sigature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson reassigned PDFBOX-1848:
---

Assignee: John Hewson

 Time Stamp Document Level Sigature
 --

 Key: PDFBOX-1848
 URL: https://issues.apache.org/jira/browse/PDFBOX-1848
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 1.8.4, 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Attachments: CreateTSASignature.java.patch, 
 TSA-SIG-LOOKS-LIKE-THIS.png


 We need TSA Document Level signature modulo too!
 At the moment we sign document with our certificate. But... sometimes we need 
 to sign document with TSA too. This is important part of signing. Sometimes 
 this is very very very important- for instance when we will implement PAdES 4 
 profile this module will be essential. without that Document Secure Store 
 will not work :)
 I'm working on this improvement. I'will finish this soon. It's almost done. I 
 only must add some java docs, and might be I change architect design and etc..
 So, please assign this it to me :) I will upload patch as soon as possible :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (PDFBOX-1847) TSA Time Signature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson reassigned PDFBOX-1847:
---

Assignee: John Hewson

 TSA Time Signature
 --

 Key: PDFBOX-1847
 URL: https://issues.apache.org/jira/browse/PDFBOX-1847
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 1.8.4, 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Attachments: CreateSignature-updated.java.patch, 
 TSATimeSignature.patch, resultOfSigning.jpg


 When we was signing document, we was using time from our time. For more 
 security we can use Time Stamp server. 
 Trusted timestamping is the process of securely keeping track of the 
 creation and modification time of a document. Security here means that no one 
 — not even the owner of the document — should be able to change it once it 
 has been recorded provided that the timestamper's integrity is never 
 compromised.(wiki)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (PDFBOX-1847) TSA Time Signature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1847:


Comment: was deleted

(was: We need to wait until Vakhtang has a signed CLA on file before this patch 
can be applied.)

 TSA Time Signature
 --

 Key: PDFBOX-1847
 URL: https://issues.apache.org/jira/browse/PDFBOX-1847
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 1.8.4, 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Attachments: CreateSignature-updated.java.patch, 
 TSATimeSignature.patch, resultOfSigning.jpg


 When we was signing document, we was using time from our time. For more 
 security we can use Time Stamp server. 
 Trusted timestamping is the process of securely keeping track of the 
 creation and modification time of a document. Security here means that no one 
 — not even the owner of the document — should be able to change it once it 
 has been recorded provided that the timestamper's integrity is never 
 compromised.(wiki)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (PDFBOX-1848) Time Stamp Document Level Sigature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1848:


Comment: was deleted

(was: We need to wait until Vakhtang has a signed CLA on file before this patch 
can be applied.)

 Time Stamp Document Level Sigature
 --

 Key: PDFBOX-1848
 URL: https://issues.apache.org/jira/browse/PDFBOX-1848
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 1.8.4, 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Attachments: CreateTSASignature.java.patch, 
 TSA-SIG-LOOKS-LIKE-THIS.png


 We need TSA Document Level signature modulo too!
 At the moment we sign document with our certificate. But... sometimes we need 
 to sign document with TSA too. This is important part of signing. Sometimes 
 this is very very very important- for instance when we will implement PAdES 4 
 profile this module will be essential. without that Document Secure Store 
 will not work :)
 I'm working on this improvement. I'will finish this soon. It's almost done. I 
 only must add some java docs, and might be I change architect design and etc..
 So, please assign this it to me :) I will upload patch as soon as possible :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1848) Time Stamp Document Level Sigature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1848:


Affects Version/s: (was: 1.8.4)

 Time Stamp Document Level Sigature
 --

 Key: PDFBOX-1848
 URL: https://issues.apache.org/jira/browse/PDFBOX-1848
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Attachments: CreateTSASignature.java.patch, 
 TSA-SIG-LOOKS-LIKE-THIS.png


 We need TSA Document Level signature modulo too!
 At the moment we sign document with our certificate. But... sometimes we need 
 to sign document with TSA too. This is important part of signing. Sometimes 
 this is very very very important- for instance when we will implement PAdES 4 
 profile this module will be essential. without that Document Secure Store 
 will not work :)
 I'm working on this improvement. I'will finish this soon. It's almost done. I 
 only must add some java docs, and might be I change architect design and etc..
 So, please assign this it to me :) I will upload patch as soon as possible :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1847) TSA Time Signature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1847:


Affects Version/s: (was: 1.8.4)

 TSA Time Signature
 --

 Key: PDFBOX-1847
 URL: https://issues.apache.org/jira/browse/PDFBOX-1847
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Fix For: 2.0.0

 Attachments: CreateSignature-updated.java.patch, 
 TSATimeSignature.patch, resultOfSigning.jpg


 When we was signing document, we was using time from our time. For more 
 security we can use Time Stamp server. 
 Trusted timestamping is the process of securely keeping track of the 
 creation and modification time of a document. Security here means that no one 
 — not even the owner of the document — should be able to change it once it 
 has been recorded provided that the timestamper's integrity is never 
 compromised.(wiki)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1848) Time Stamp Document Level Sigature


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Hewson updated PDFBOX-1848:


Fix Version/s: 2.0.0

 Time Stamp Document Level Sigature
 --

 Key: PDFBOX-1848
 URL: https://issues.apache.org/jira/browse/PDFBOX-1848
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Fix For: 2.0.0

 Attachments: CreateTSASignature.java.patch, 
 TSA-SIG-LOOKS-LIKE-THIS.png


 We need TSA Document Level signature modulo too!
 At the moment we sign document with our certificate. But... sometimes we need 
 to sign document with TSA too. This is important part of signing. Sometimes 
 this is very very very important- for instance when we will implement PAdES 4 
 profile this module will be essential. without that Document Secure Store 
 will not work :)
 I'm working on this improvement. I'will finish this soon. It's almost done. I 
 only must add some java docs, and might be I change architect design and etc..
 So, please assign this it to me :) I will upload patch as soon as possible :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-1977:


Affects Version/s: 1.8.4

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-1977:


Affects Version/s: (was: 1.8.4)
   1.8.5

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr reassigned PDFBOX-1977:
---

Assignee: Tilman Hausherr

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-1977:


Fix Version/s: 2.0.0
   1.8.5

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression


[ 
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931982#comment-13931982
 ] 

Tilman Hausherr commented on PDFBOX-1975:
-

outdir problem fixed in rev 1576815 as described. 

 Improve TestImageIOUtils unit tests to check image resolution and compression
 -

 Key: PDFBOX-1975
 URL: https://issues.apache.org/jira/browse/PDFBOX-1975
 Project: PDFBox
  Issue Type: Task
  Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
  Labels: imageio, test, tiff
 Fix For: 2.0.0


 Because of the problems with recent changes (see PDFBOX-1963), I will improve 
 the unit tests so that image resolution and compression is checked.
 I found out that JPEGs don't have a resolution, BMP had the wrong resolution. 
 The fault wasn't in the java TIFF writer as I thought before, it is in the 
 java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets 
 them as pixels per mm instead of mm per pixel as per specification. The 
 JPEG writer throws an exception JFIF APP0 must be first marker after SOI. 
 The BMP writer can set the resolution, but the BMP reader doesn't read it.
 (Some of this might be different depending on the version)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression


[ 
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931988#comment-13931988
 ] 

Tilman Hausherr commented on PDFBOX-1975:
-

I also added writing a GIF file in rev 1576817.

 Improve TestImageIOUtils unit tests to check image resolution and compression
 -

 Key: PDFBOX-1975
 URL: https://issues.apache.org/jira/browse/PDFBOX-1975
 Project: PDFBox
  Issue Type: Task
  Components: Utilities
Affects Versions: 2.0.0
Reporter: Tilman Hausherr
Assignee: Tilman Hausherr
Priority: Minor
  Labels: imageio, test, tiff
 Fix For: 2.0.0


 Because of the problems with recent changes (see PDFBOX-1963), I will improve 
 the unit tests so that image resolution and compression is checked.
 I found out that JPEGs don't have a resolution, BMP had the wrong resolution. 
 The fault wasn't in the java TIFF writer as I thought before, it is in the 
 java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets 
 them as pixels per mm instead of mm per pixel as per specification. The 
 JPEG writer throws an exception JFIF APP0 must be first marker after SOI. 
 The BMP writer can set the resolution, but the BMP reader doesn't read it.
 (Some of this might be different depending on the version)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1847) TSA Time Signature


[ 
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931975#comment-13931975
 ] 

John Hewson commented on PDFBOX-1847:
-

Just to recap out discussion on the mailing list: this patch is going to go 
into a new singing module:

{quote}
*Vakhtang Koroghlishvili:*
I think, it's time to create another project named sign-box or something like 
that.  At the moment I have time and I can create that project  with very good  
design architect and show you a patch or comitters  can create that project 
with existence features and then we will add new features step by step.
{quote}

and the existing non-core signing classes will be moved there too.

For anyone wondering why we would want to move the signing classes, one reason 
is that they are not part of the PDF specification. The spec defines a generic 
plug-in framework for signatures with some basic built-in functionality, but 
nothing beyond that. Instead, there are various third party signing standards, 
such as [PAdES|http://en.wikipedia.org/wiki/PAdES].

 TSA Time Signature
 --

 Key: PDFBOX-1847
 URL: https://issues.apache.org/jira/browse/PDFBOX-1847
 Project: PDFBox
  Issue Type: Improvement
  Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
 Fix For: 2.0.0

 Attachments: CreateSignature-updated.java.patch, 
 TSATimeSignature.patch, resultOfSigning.jpg


 When we was signing document, we was using time from our time. For more 
 security we can use Time Stamp server. 
 Trusted timestamping is the process of securely keeping track of the 
 creation and modification time of a document. Security here means that no one 
 — not even the owner of the document — should be able to change it once it 
 has been recorded provided that the timestamper's integrity is never 
 compromised.(wiki)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1847) TSA Time Signature

[
https://issues.apache.org/jira/browse/PDFBOX-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931975#comment-13931975
]

John Hewson edited comment on PDFBOX-1847 at 3/12/14 4:49 PM:
--

Just to recap our discussion on the mailing list: this patch is going to go
into a new singing module:

{quote}
*Vakhtang Koroghlishvili:*
I think, it's time to create another project named sign-box or something like
that. At the moment I have time and I can create that project with very good
design architect and show you a patch or comitters can create that project
with existence features and then we will add new features step by step.
{quote}

and the existing non-core signing classes will be moved there too.

For anyone wondering why we would want to move the signing classes, one reason
is that they are not part of the PDF specification. The spec defines a generic
plug-in framework for signatures with some basic built-in functionality, but
nothing beyond that. Instead, there are various third party signing standards,
such as [PAdES|http://en.wikipedia.org/wiki/PAdES].

was (Author: jahewson):
Just to recap out discussion on the mailing list: this patch is going to go
into a new singing module:

and the existing non-core signing classes will be moved there too.

TSA Time Signature
--

Key: PDFBOX-1847
URL: https://issues.apache.org/jira/browse/PDFBOX-1847
Project: PDFBox
Issue Type: Improvement
Components: Signing
Affects Versions: 2.0.0
Reporter: vakhtang koroghlishvili
Assignee: John Hewson
Fix For: 2.0.0

Attachments: CreateSignature-updated.java.patch,
TSATimeSignature.patch, resultOfSigning.jpg

When we was signing document, we was using time from our time. For more
security we can use Time Stamp server.
Trusted timestamping is the process of securely keeping track of the
creation and modification time of a document. Security here means that no one
— not even the owner of the document — should be able to change it once it
has been recorded provided that the timestamper's integrity is never
compromised.(wiki)

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

2014-03-12 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931990#comment-13931990
 ] 

Michael McCandless commented on PDFBOX-1977:


It's intentional that the test picks a random seed, and it then prints the seed 
if there is an error, so we get better test coverage without losing 
reproducibility.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932011#comment-13932011
 ] 

Tilman Hausherr commented on PDFBOX-1977:
-

My mistake (in the encoder) was not to check the bit chunk size after writing 
the last output code and before writing the EOD code. Since the decoder doesn't 
know that an EOD is coming, it had adjusted its own bit chunk size. I fixed 
this and also modified some code per DRY and optimized a bit. Done in rev 
1576820 for the trunk and rev 1576821 for the 1.8 branch.

Any suggestions for the random seed? I'd take System.getCurrentMillis().

Btw, how long did you run your own test until you got this fail?

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932011#comment-13932011
]

Tilman Hausherr edited comment on PDFBOX-1977 at 3/12/14 5:07 PM:
--

My mistake (in the encoder) was not to check the bit chunk size after writing
the last output code and before writing the EOD code. Since the decoder doesn't
know that an EOD is coming, it had adjusted its own bit chunk size. I fixed
this and also modified some code per DRY and optimized a bit. Done in rev
1576820 for the trunk and rev 1576821 for the 1.8 branch.

Any suggestions for the random seed? I'd take System.getCurrentMillis().

Btw, how long did you run your own test with real random until you got this
fail?

was (Author: tilman):
My mistake (in the encoder) was not to check the bit chunk size after writing
the last output code and before writing the EOD code. Since the decoder doesn't
know that an EOD is coming, it had adjusted its own bit chunk size. I fixed
this and also modified some code per DRY and optimized a bit. Done in rev
1576820 for the trunk and rev 1576821 for the 1.8 branch.

Any suggestions for the random seed? I'd take System.getCurrentMillis().

Btw, how long did you run your own test until you got this fail?

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

2014-03-12 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932018#comment-13932018
 ] 

Michael McCandless commented on PDFBOX-1977:


I think just leave the random seed as it's now done?

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:11 PM:
--

[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be a constant. 
Better still, the test could be run on a set of representative data.


was (Author: jahewson):
[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be fixed. Better 
still, the test could be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:11 PM:
--

[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be fixed. Better 
still, the test could be run on a set of representative data.


was (Author: jahewson):
[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be deterministic. 
Better still, the test could be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


 [ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tilman Hausherr updated PDFBOX-1977:


Comment: was deleted

(was: Ouch :-( The decoded stream has a bonus of two extra bytes.
)

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson commented on PDFBOX-1977:
-

[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be deterministic. 
Better still, the test could be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932017#comment-13932017
 ] 

Tilman Hausherr commented on PDFBOX-1977:
-

[~mikemccand] The problem was that the test didn't pick a random seed to start 
:-(

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

[
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932011#comment-13932011
]

Tilman Hausherr edited comment on PDFBOX-1977 at 3/12/14 5:14 PM:
--

Any suggestions for the -random- seed? -I'd take System.getCurrentMillis().-

Btw, how long did you run your own test with real random until you got this
fail?

Any suggestions for the random seed? I'd take System.getCurrentMillis().

Btw, how long did you run your own test with real random until you got this
fail?

LZWFilter fails / TestFilters is non-determinate

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:17 PM:
--

The test does use a random seed, but [unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.


was (Author: jahewson):
The test does use a random seed, but [Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:17 PM:
--

The test does use a random seed, but [Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.


was (Author: jahewson):
[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:19 PM:
--

The test does use a random seed, but [unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data. Perhaps there is 
another open source LZW library which has a set of high-quality test data?


was (Author: jahewson):
The test does use a random seed, but [unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Need JBIG2 test image


Hello all,

I'd need a PDF with JBIG2 encoding that can be distributed. So it should 
not have anything on it that is copyrighted, i.e. artwork or a real 
text. Just some random lines or a lorem ipsum text. The image should be 
black  white, i.e. not have other elements in it that have a color like 
a watermark. Some unserviced Xerox copiers might produce such images, or 
some software from Adobe, IRIS etc. If you have such a file, sent it to 
me, tilman at snafu dot de, not to the list.


I want to use this PDF for a unit test that checks whether the PDF is 
decoded with the JBIG2 plugin. A fail would be an empty image. This way 
we check that the JBIG2 plugin is properly attached.


Tilman

[jira] [Comment Edited] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932020#comment-13932020
 ] 

John Hewson edited comment on PDFBOX-1977 at 3/12/14 5:13 PM:
--

[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be constant. Better 
still, the test should be run on a set of representative data.


was (Author: jahewson):
[Unit tests should not be 
non-deterministic|http://martinfowler.com/articles/nonDeterminism.html]. The 
data can be generated using Random() but the seed needs to be a constant. 
Better still, the test could be run on a set of representative data.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1975) Improve TestImageIOUtils unit tests to check image resolution and compression

[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932044#comment-13932044
]

Tilman Hausherr commented on PDFBOX-1975:
-

I changed PhotometricInterpretation to WhiteIsZero in the TIFFUtil class
because Windows XP couldn't thumbnail / display the BlackIsZero encoding
properly. This may be a regression but that solution above is as good. This was
done in rev. 1576828.

Improve TestImageIOUtils unit tests to check image resolution and compression
-

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (PDFBOX-1977) LZWFilter fails / TestFilters is non-determinate

2014-03-12 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/PDFBOX-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932046#comment-13932046
 ] 

Michael McCandless commented on PDFBOX-1977:


[~tilman] I'm confused: the test seems to do 10 iterations, picking a random 
seed every time, and then if there is a failure, it reports which seed leads to 
the failure?

[~jahewson] I agree tests must be deterministic, and, with the specified seed, 
this test is.  The randomization allows us to test a wide range of data without 
sacrificing reproducibility.  In Lucene we make heavy use of this, picking 
random codecs, random documents, etc. ... Lucene's testing framework has since 
been factored out as a separate project: 
https://github.com/carrotsearch/randomizedtesting

I wrote this brief blog post about Lucene's randomized tests a while back: 
http://blog.mikemccandless.com/2011/03/your-test-cases-should-sometimes-fail.html

Had the seed in this test been constant, this issue would not have been found.  
It's because the seed is randomly selected that the test finally produced a 
sequence of data that provokes the bug.

 LZWFilter fails / TestFilters is non-determinate
 

 Key: PDFBOX-1977
 URL: https://issues.apache.org/jira/browse/PDFBOX-1977
 Project: PDFBox
  Issue Type: Bug
Affects Versions: 1.8.5, 2.0.0
Reporter: John Hewson
Assignee: Tilman Hausherr
  Labels: LZW
 Fix For: 1.8.5, 2.0.0


 TestFilters uses Random().nextLong() to generate a seed for random data, 
 which means that it is non-determinate. Depending on the seed value, the test 
 may fail or succeed.
 Using the following seed results in the LZW filter failing:
 final long seed = -6257105096642706464L;



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Need JBIG2 test image

2014-03-12 Thread Alin Mazilu

I have a scanned accident police reports that have people names, addresses
and phone numbers in them. I had a problem printing these files with pdfbox
and I had to improvise by using a command prompt print utility as a
Process. I could maybe give you one if you agree not to release it to the
public.

Alin


On Wed, Mar 12, 2014 at 1:19 PM, Tilman Hausherr thaush...@t-online.dewrote:

 Hello all,

 I'd need a PDF with JBIG2 encoding that can be distributed. So it should
 not have anything on it that is copyrighted, i.e. artwork or a real text.
 Just some random lines or a lorem ipsum text. The image should be black 
 white, i.e. not have other elements in it that have a color like a
 watermark. Some unserviced Xerox copiers might produce such images, or some
 software from Adobe, IRIS etc. If you have such a file, sent it to me,
 tilman at snafu dot de, not to the list.

 I want to use this PDF for a unit test that checks whether the PDF is
 decoded with the JBIG2 plugin. A fail would be an empty image. This way we
 check that the JBIG2 plugin is properly attached.

 Tilman

Re: Need JBIG2 test image


No, the file would of course be public.

I can still have a look about whether PDFBOX can now handle these files, 
however I suspect that this would bring you in trouble with the law even 
if I promise you all you want.


PDFBOX does support JBIG2, you need the levigo plugin.

Tilman

Am 12.03.2014 18:33, schrieb Alin Mazilu:

I have a scanned accident police reports that have people names, addresses
and phone numbers in them. I had a problem printing these files with pdfbox
and I had to improvise by using a command prompt print utility as a
Process. I could maybe give you one if you agree not to release it to the
public.

Alin


On Wed, Mar 12, 2014 at 1:19 PM, Tilman Hausherr thaush...@t-online.dewrote:


Hello all,

I'd need a PDF with JBIG2 encoding that can be distributed. So it should
not have anything on it that is copyrighted, i.e. artwork or a real text.
Just some random lines or a lorem ipsum text. The image should be black 
white, i.e. not have other elements in it that have a color like a
watermark. Some unserviced Xerox copiers might produce such images, or some
software from Adobe, IRIS etc. If you have such a file, sent it to me,
tilman at snafu dot de, not to the list.

I want to use this PDF for a unit test that checks whether the PDF is
decoded with the JBIG2 plugin. A fail would be an empty image. This way we
check that the JBIG2 plugin is properly attached.

Tilman

Jenkins build is back to normal : PDFBox-trunk #882

See https://builds.apache.org/job/PDFBox-trunk/882/changes

Jenkins build is back to normal : PDFBox-trunk » Apache JempBox #882