[jira] [Comment Edited] (PDFBOX-2844) Printing has bigger margins than expected

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609608#comment-14609608
 ] 

John Hewson edited comment on PDFBOX-2844 at 7/1/15 6:15 AM:
-

I'm thinking we need to make some changes to PDFPrinter, because it's fairly 
clear from the mailing list that the current API is confusing. As you say, not 
a good user experience. The code I posted actually requires the custom paper to 
then be passed to PDFPrinter, as the result of defaultPage() is a new object 
each time - but our custom paper API is confusing too, so I think we should fix 
the whole thing.

As far as I can tell the issue which confuses people is that our print() and 
silentPrint() methods are non-standard and obscure the underlying Java API. I 
think we should simply provide a PDFPageable class and have that be all. That 
way users can use the Java printing APIs and understand what they're doing, and 
it will be very easy for them to do custom stuff if they wish. We can include 
some code to set the margins to a minimum too, in our example, which users can 
copy if they wish. Thoughts?


was (Author: jahewson):
I'm thinking we need to make some changes to PDFPrinter, because it's fairly 
clear from the mailing list that the current API is confusing. As you say, not 
a good user experience. The code I posted actually requires the custom paper to 
then be passed to PDFPrinter, as the result of defaultPage() is a new object 
each time - but our custom paper API is confusing too, so I think we should fix 
the whole thing.

As far as I can tell the issue which confuses people is that our print() and 
silentPrint() methods are non-standard and obscure the underlying Java API. I 
think we should simply provide a PDFPageable class and have that be all. That 
way users can use the Java printing APIs and understand what they're doing, and 
it will be very easy for to do custom stuff if they wish. We can include some 
code to set the margins to a minimum too, in our example, which users can copy 
if they wish. Thoughts?

> Printing has bigger margins than expected
> -
>
> Key: PDFBOX-2844
> URL: https://issues.apache.org/jira/browse/PDFBOX-2844
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: PDFBOX-2844.pdf
>
>
> Printing the attached file from PDFReader brings larger margins than 
> expected, and larger than with Adobe Reader. Doing the same with 1.8 has the 
> expected margins (but bad fonts).
> From Александр Свиридов / Alex Sviridov in the mailing list:
> {quote}
> I printed this pdf file with Adobe Reader in mode 100%. And as expected left 
> and right margins are about 2cm. In comparison when I print using pdfbox left 
> margin is 4.5cm, right about 3.5cm.
> The code I use :
> {code}
> PrinterJob job = PrinterJob.getPrinterJob();
> Paper paper=new Paper();
> paper.setSize(72d*8.267d, 72d*11.692);
> PDFPrinter pDFPrinter=new PDFPrinter(document,Scaling.SCALE_TO_FIT, 
> Orientation.PORTRAIT,paper);
> pDFPrinter.silentPrint(job);
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2844) Printing has bigger margins than expected

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609608#comment-14609608
 ] 

John Hewson commented on PDFBOX-2844:
-

I'm thinking we need to make some changes to PDFPrinter, because it's fairly 
clear from the mailing list that the current API is confusing. As you say, not 
a good user experience. The code I posted actually requires the custom paper to 
then be passed to PDFPrinter, as the result of defaultPage() is a new object 
each time - but our custom paper API is confusing too, so I think we should fix 
the whole thing.

As far as I can tell the issue which confuses people is that our print() and 
silentPrint() methods are non-standard and obscure the underlying Java API. I 
think we should simply provide a PDFPageable class and have that be all. That 
way users can use the Java printing APIs and understand what they're doing, and 
it will be very easy for to do custom stuff if they wish. We can include some 
code to set the margins to a minimum too, in our example, which users can copy 
if they wish. Thoughts?

> Printing has bigger margins than expected
> -
>
> Key: PDFBOX-2844
> URL: https://issues.apache.org/jira/browse/PDFBOX-2844
> Project: PDFBox
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: PDFBOX-2844.pdf
>
>
> Printing the attached file from PDFReader brings larger margins than 
> expected, and larger than with Adobe Reader. Doing the same with 1.8 has the 
> expected margins (but bad fonts).
> From Александр Свиридов / Alex Sviridov in the mailing list:
> {quote}
> I printed this pdf file with Adobe Reader in mode 100%. And as expected left 
> and right margins are about 2cm. In comparison when I print using pdfbox left 
> margin is 4.5cm, right about 3.5cm.
> The code I use :
> {code}
> PrinterJob job = PrinterJob.getPrinterJob();
> Paper paper=new Paper();
> paper.setSize(72d*8.267d, 72d*11.692);
> PDFPrinter pDFPrinter=new PDFPrinter(document,Scaling.SCALE_TO_FIT, 
> Orientation.PORTRAIT,paper);
> pDFPrinter.silentPrint(job);
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2849) implement appearance generation for buttons

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609453#comment-14609453
 ] 

John Hewson commented on PDFBOX-2849:
-

Unless NeedAppearances is set, of course.

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2849) implement appearance generation for buttons

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609446#comment-14609446
 ] 

John Hewson commented on PDFBOX-2849:
-

That's correct, NeedAppearances means that there are no appearances - anyone 
reading the PDF will need to generate them themselves. So NeedAppearances = 
false means the PDF must contain appearances, so we have to generate them. 
Confusing, isn't it?

I think what we need is another line of code in that method which skips 
constructAppearances() if there is already an AP stream. Unless, as Maruan 
said, if it's a variable text field.

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2849) implement appearance generation for buttons

[John Hewson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609438#comment-14609438
 ] 

John Hewson commented on PDFBOX-2849:
-

Sometimes the appearance is missing so we'd need to generate one in that case 
too.

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to normal : PDFBox-trunk (JDK 1.6.0 unlimited security) » Apache PDFBox tools #9

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is unstable: PDFBox-trunk (JDK 1.6.0 unlimited security) #9

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build became unstable: PDFBox-trunk (JDK 1.6.0 unlimited security) » Apache PDFBox #9

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is back to normal : PDFBox-trunk » Apache PDFBox tools #2262

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is unstable: PDFBox-trunk #2262

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-trunk » Apache PDFBox #2262

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609068#comment-14609068
 ] 

ASF subversion and git services commented on PDFBOX-2847:
-

Commit 1688518 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1688518 ]

PDFBOX-2847: no scratchFile for command line utility

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Fix For: 1.8.10, 2.0.0
>
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2849) implement appearance generation for buttons

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609063#comment-14609063
 ] 

Tilman Hausherr commented on PDFBOX-2849:
-

I'll leave that to you... btw, I found this in PDTerminalField:
{code}
protected final void applyChange() throws IOException
{
if (!acroForm.getNeedAppearances())
{
constructAppearances();
}
// if we supported JavaScript we would raise a field changed event here
}
{code}
Is this correct or is the "!" wrong?

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Build failed in Jenkins: PDFBox-trunk #2261

[Apache Jenkins Server]

See 

Changes:

[tilman] PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by 
Jim deVos

[tilman] PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by 
Jim deVos

--
[...truncated 1349 lines...]
[INFO] 
[INFO] --- maven-bundle-plugin:2.5.3:deploy (default-deploy) @ preflight ---
[INFO] Remote OBR update disabled (enable with -DremoteOBR)
[INFO] 
[INFO] 
[INFO] Building Apache Preflight application 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ preflight-app ---
[TASKS] Scanning folder 
' 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 #2260
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ preflight-app 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
preflight-app ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ preflight-app 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
preflight-app ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
preflight-app ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ preflight-app ---
[JENKINS] Recording test results[INFO] 
[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ preflight-app ---

[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Unused 
Private-Package instructions, no such package(s) on the class path: [!*]
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.pdmodel.common,  has 1,  private references 
[org.apache.fontbox.util], 
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.pdmodel.font,  has 7,  private references 
[org.apache.fontbox.cmap, org.apache.fontbox.type1, org.apache.fontbox.ttf, 
org.apache.fontbox.util, org.apache.fontbox.cff, org.apache.fontbox.afm, 
org.apache.fontbox], 
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.pdmodel.font.encoding,  has 2,  private references 
[org.apache.fontbox.encoding, org.apache.fontbox.afm], 
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.preflight,  has 1,  private references [org.apache.xmpbox], 
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.preflight.font.util,  has 1,  private references 
[org.apache.xmpbox], 
[WARNING] Bundle org.apache.pdfbox:preflight-app:bundle:2.0.0-SNAPSHOT : Export 
org.apache.pdfbox.preflight.metadata,  has 2,  private references 
[org.apache.xmpbox.schema, org.apache.xmpbox], 
[INFO] 
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
preflight-app ---
[WARNING] Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo
[INFO] 
[INFO] --- maven-source-plugin:2.3:jar (attach-sources) @ preflight-app ---
[INFO] Building jar: 

[INFO] 
[INFO] --- apache-rat-plugin:0.11:check (default) @ preflight-app ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: release.properties
[INFO] 3 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.5.2:install (default-install) @ preflight-app 
---
[INFO] Installing 

 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/pdfbox/preflight-app/2.0.0-SNAPSHOT/preflight-app-2.0.0-SNAPSHOT.jar
[INFO] Installing 
 to 
/home/jenkins/jenkins-slave/maven-repositories/0/org/apache/pdfbox/preflight-app/2.0.0-SNAPSHOT/preflight-app-2.0.0-SNAPSHOT.po

Jenkins build is still unstable: PDFBox-trunk » Apache PDFBox #2261

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Build failed in Jenkins: PDFBox-trunk » Apache PDFBox tools #2261

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache PDFBox tools 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ pdfbox-tools ---
[TASKS] Scanning folder 
'
 for files matching the pattern '**/*.java' - excludes: 
[TASKS] Found 62 files to scan for tasks
Found 4 open tasks.
[TASKS] Computing warning deltas based on reference build #2260
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ pdfbox-tools 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
pdfbox-tools ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 13 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ pdfbox-tools 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 58 source files to 

[INFO] -
[WARNING] COMPILATION WARNING : 
[INFO] -
[WARNING] bootstrap class path not set in conjunction with -source 1.6
[WARNING] 
:
 Some input files use unchecked or unsafe operations.
[WARNING] 
:
 Recompile with -Xlint:unchecked for details.
[INFO] 3 warnings 
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[67,15]
 method mergeDocuments in class org.apache.pdfbox.multipdf.PDFMergerUtility 
cannot be applied to given types;
  required: boolean
  found: no arguments
  reason: actual and formal argument lists differ in length
[INFO] 1 error
[INFO] -

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Closed] (PDFBOX-2848) Could not find font: /Courier for PDTextField

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr closed PDFBOX-2848.
---
Resolution: Duplicate

> Could not find font: /Courier for PDTextField
> -
>
> Key: PDFBOX-2848
> URL: https://issues.apache.org/jira/browse/PDFBOX-2848
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.011.Name");
> PDTextField newTextField = (PDTextField) newField;
> newTextField.setValue("huhu");
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.io.IOException: Could not find font: /Courier
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.getFont(PDAppearanceString.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.copyNeededResourcesTo(PDAppearanceString.java:175)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:130)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2849) implement appearance generation for buttons

[Maruan Sahyoun (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609048#comment-14609048
 ] 

Maruan Sahyoun commented on PDFBOX-2849:


For existing PDButton fields PDButton fields an appearance generation shouldn't 
be necessary as 'only' the correct appearance has to be set for display as can 
bee seen by the above code. Appearance generation when setting a value is only 
necessary for variable text fields.

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2848) Could not find font: /Courier for PDTextField

[Maruan Sahyoun (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609038#comment-14609038
 ] 

Maruan Sahyoun commented on PDFBOX-2848:


This is because the field does set the font Courier within the default 
appearance string but doesn't have the font resource nor does any of the 
parents or the AcroForm itself.

Acrobat is able to handle that but we are currently not. See also PDFBOX-2661 
and PDFBOX-2662

> Could not find font: /Courier for PDTextField
> -
>
> Key: PDFBOX-2848
> URL: https://issues.apache.org/jira/browse/PDFBOX-2848
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.011.Name");
> PDTextField newTextField = (PDTextField) newField;
> newTextField.setValue("huhu");
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.io.IOException: Could not find font: /Courier
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.getFont(PDAppearanceString.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.copyNeededResourcesTo(PDAppearanceString.java:175)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:130)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2849) implement appearance generation for buttons

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2849:

Description: 
This code
{code}
PDField newField = 
tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
PDCheckbox newCheckBoxField = (PDCheckbox) newField;
newCheckBoxField.check();
{code}
brings this exception:
{code}
Exception in thread "main" java.lang.UnsupportedOperationException: not 
implemented
at 
org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
{code}
what did work is this:
{code}
newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
{code}

  was:
This code
{code}
PDField newField = 
tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
PDCheckbox newCheckBoxField = (PDCheckbox) newField;
newCheckBoxField.check();
{code}
brings this exception:
{code}
Exception in thread "main" java.lang.UnsupportedOperationException: not 
implemented
at 
org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
{code}
what did work (although not for every checkbox) is this:
{code}
newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
{code}


> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2849) implement appearance generation for buttons

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2849:

Summary: implement appearance generation for buttons  (was: appearance 
generation for buttons)

> implement appearance generation for buttons
> ---
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work (although not for every checkbox) is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2849) appearance generation for buttons

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2849:

Attachment: TestTemplate.pdf

> appearance generation for buttons
> -
>
> Key: PDFBOX-2849
> URL: https://issues.apache.org/jira/browse/PDFBOX-2849
> Project: PDFBox
>  Issue Type: Sub-task
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Fix For: 2.0.0
>
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
> PDCheckbox newCheckBoxField = (PDCheckbox) newField;
> newCheckBoxField.check();
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.lang.UnsupportedOperationException: not 
> implemented
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
> {code}
> what did work (although not for every checkbox) is this:
> {code}
> newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
> newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-2849) appearance generation for buttons

[Tilman Hausherr (JIRA)]

Tilman Hausherr created PDFBOX-2849:
---

 Summary: appearance generation for buttons
 Key: PDFBOX-2849
 URL: https://issues.apache.org/jira/browse/PDFBOX-2849
 Project: PDFBox
  Issue Type: Sub-task
  Components: AcroForm
Affects Versions: 2.0.0
Reporter: Tilman Hausherr


This code
{code}
PDField newField = 
tplDoc.getDocumentCatalog().getAcroForm().getField("01.20.Entry1");
PDCheckbox newCheckBoxField = (PDCheckbox) newField;
newCheckBoxField.check();
{code}
brings this exception:
{code}
Exception in thread "main" java.lang.UnsupportedOperationException: not 
implemented
at 
org.apache.pdfbox.pdmodel.interactive.form.PDButton.constructAppearances(PDButton.java:225)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.setValue(PDCheckbox.java:128)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox.check(PDCheckbox.java:71)
{code}
what did work (although not for every checkbox) is this:
{code}
newCheckBoxField.getCOSObject().setItem(COSName.V, vValue);
newCheckBoxField.getCOSObject().setItem(COSName.AS, asValue);
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2848) Could not find font: /Courier for PDTextField

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2848:

Attachment: TestTemplate.pdf

> Could not find font: /Courier for PDTextField
> -
>
> Key: PDFBOX-2848
> URL: https://issues.apache.org/jira/browse/PDFBOX-2848
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.0
>Reporter: Tilman Hausherr
> Attachments: TestTemplate.pdf
>
>
> This code
> {code}
> PDField newField = 
> tplDoc.getDocumentCatalog().getAcroForm().getField("01.011.Name");
> PDTextField newTextField = (PDTextField) newField;
> newTextField.setValue("huhu");
> {code}
> brings this exception:
> {code}
> Exception in thread "main" java.io.IOException: Could not find font: /Courier
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.getFont(PDAppearanceString.java:128)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.copyNeededResourcesTo(PDAppearanceString.java:175)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:130)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Created] (PDFBOX-2848) Could not find font: /Courier for PDTextField

[Tilman Hausherr (JIRA)]

Tilman Hausherr created PDFBOX-2848:
---

 Summary: Could not find font: /Courier for PDTextField
 Key: PDFBOX-2848
 URL: https://issues.apache.org/jira/browse/PDFBOX-2848
 Project: PDFBox
  Issue Type: Bug
  Components: AcroForm
Affects Versions: 2.0.0
Reporter: Tilman Hausherr


This code
{code}
PDField newField = 
tplDoc.getDocumentCatalog().getAcroForm().getField("01.011.Name");
PDTextField newTextField = (PDTextField) newField;
newTextField.setValue("huhu");
{code}
brings this exception:
{code}
Exception in thread "main" java.io.IOException: Could not find font: /Courier
at 
org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.getFont(PDAppearanceString.java:128)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.copyNeededResourcesTo(PDAppearanceString.java:175)
at 
org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:130)
at 
org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
at 
org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Build failed in Jenkins: PDFBox-trunk (JDK 1.6.0 unlimited security) » Apache PDFBox tools #8

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building Apache PDFBox tools 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ pdfbox-tools ---
[TASKS] Scanning folder 
'
 for files matching the pattern '**/*.java' - excludes: 
[TASKS] Found 62 files to scan for tasks
Found 4 open tasks.
[TASKS] Computing warning deltas based on reference build #7
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ pdfbox-tools 
---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
pdfbox-tools ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 13 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ pdfbox-tools 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 58 source files to 

[INFO] -
[WARNING] COMPILATION WARNING : 
[INFO] -
[WARNING] Note: Some input files use unchecked or unsafe operations.
[WARNING] Note: Recompile with -Xlint:unchecked for details.
[INFO] 2 warnings 
[INFO] -
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[67,15]
 mergeDocuments(boolean) in org.apache.pdfbox.multipdf.PDFMergerUtility cannot 
be applied to ()
[INFO] 1 error
[INFO] -

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Build failed in Jenkins: PDFBox-trunk (JDK 1.6.0 unlimited security) #8

[Apache Jenkins Server]

See 


Changes:

[tilman] PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by 
Jim deVos

[tilman] PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by 
Jim deVos

--
[...truncated 1123 lines...]
Tests run: 289, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 183.099 sec - 
in org.apache.pdfbox.preflight.TestIsartor
Running org.apache.pdfbox.preflight.action.pdfa1b.TestSubmitAction
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestSubmitAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestForbiddenAction
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestForbiddenAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestThreadAction
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestThreadAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestHideAction
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestHideAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestNamedAction
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestNamedAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestGotoAction
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestGotoAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestGotoRemoteAction
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestGotoRemoteAction
Running org.apache.pdfbox.preflight.action.pdfa1b.TestUriAction
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec - in 
org.apache.pdfbox.preflight.action.pdfa1b.TestUriAction
Running org.apache.pdfbox.preflight.TestValidDirectory
System property 'pdfa.valid' not defined, will not run TestValidaDirectory
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.TestValidDirectory
Running org.apache.pdfbox.preflight.utils.TestCOSUtils
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
org.apache.pdfbox.preflight.utils.TestCOSUtils
Running org.apache.pdfbox.preflight.TestInvalidDirectory
System property 'pdfa.invalid' not defined, will not run TestValidaDirectory
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.TestInvalidDirectory
Running org.apache.pdfbox.preflight.TestPreflightPath
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.TestPreflightPath
Running org.apache.pdfbox.preflight.TestPreflightConfiguration
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.TestPreflightConfiguration
Running org.apache.pdfbox.preflight.parser.TestXmlResultParser
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec - in 
org.apache.pdfbox.preflight.parser.TestXmlResultParser
Running org.apache.pdfbox.preflight.parser.TestPreflightConfiguration
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
org.apache.pdfbox.preflight.parser.TestPreflightConfiguration

Results :

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

[JENKINS] Recording test results
[INFO] 
[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ preflight ---
[INFO] 
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
preflight ---
[WARNING] Failed to getClass for org.apache.maven.plugin.source.SourceJarMojo
[INFO] 
[INFO] --- maven-source-plugin:2.3:jar (attach-sources) @ preflight ---
[INFO] Building jar: 

[INFO] 
[INFO] 
[INFO] Building Apache Preflight application 2.0.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ preflight-app ---
[TASKS] Scanning folder 
'
 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 #7
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ preflight-app 
---
[INF

[jira] [Resolved] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr resolved PDFBOX-2847.
-
   Resolution: Fixed
Fix Version/s: 2.0.0
   1.8.10

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Fix For: 1.8.10, 2.0.0
>
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr updated PDFBOX-2847:

Affects Version/s: 2.0.0
   1.8.10

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608974#comment-14608974
 ] 

ASF subversion and git services commented on PDFBOX-2847:
-

Commit 1688514 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1688514 ]

PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by Jim deVos

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9, 1.8.10, 2.0.0
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608972#comment-14608972
 ] 

ASF subversion and git services commented on PDFBOX-2847:
-

Commit 1688513 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1688513 ]

PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by Jim deVos

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-trunk #2260

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Jenkins build is still unstable: PDFBox-trunk » Apache PDFBox #2260

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2530) Improve PDFDebugger

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608825#comment-14608825
 ] 

ASF subversion and git services commented on PDFBOX-2530:
-

Commit 1688502 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1688502 ]

PDFBOX-2530: fix typo

> Improve PDFDebugger
> ---
>
> Key: PDFBOX-2530
> URL: https://issues.apache.org/jira/browse/PDFBOX-2530
> Project: PDFBox
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 1.8.8, 2.0.0
>Reporter: Tilman Hausherr
>Assignee: khyrul bashar
>  Labels: gsoc2015
> Attachments: BracketsColorChooser.png, DeviceNCS.diff, 
> FlagBitsPane-26-06-2015.diff, Flag_bits_showing_feature-redesigned.diff, 
> Flag_bits_showing_feature.diff, K4SystemFontsNotEmbeded218.pdf, 
> PDFDebugger_StatusBar.png, PDFDebugger_StatusBar_01.png, indexedcs.diff, 
> openSelectedPath.diff, parent_node_redirect.diff, 
> parent_node_redirect_expand_disabled.diff, removed_redundant_codes.patch, 
> separationCS.diff, sonarqube_warning_resolve.diff, tree.diff, 
> treestatus.diff, treestatuspane.diff
>
>
> (This is an idea for the [Google Summer of Code 
> 2015|https://www.google-melange.com/])
> Our command line utility PDFDebugger (part of the command line pdfbox-app get 
> it [here|https://pdfbox.apache.org/downloads.html], read description 
> [here|https://pdfbox.apache.org/commandline/], see the source code 
> [here|https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFDebugger.java?view=markup&sortby=date])
>  needs some improvements:
>- hex view
>- view of non printable characters
>- saving streams
>- binary copy & paste
>- ✓ Create a status line that shows where we are in the tree. (Like in the 
> Windows REGEDIT)
>- ✓ Copy the current tree string into the clipboard (useful in discussions 
> about details of a PDF)
>- ✓ (Optional, not sure if easy) Jump to specific place in the tree by 
> entering tree string
>- ability to search in streams (very useful for content streams and meta 
> data)
>- show images that are streams
>- ✓ show PDIndexed color lookup table, show the index value, the base and 
> RGB color value sets when the mouse moves
>- ✓ show PDSeparation color
>- ✓ show PDDeviceN colors
>- optional, idea should be developed a bit: show meaningful explanation on 
> some attributes, e.g. "appearance stream" when hovering over /AP
>- show font encodings and characters
>- display flag bits (e.g. Annotation flags) in a way that is easy to 
> understand. There are probably others, I assume that the main work needs to 
> be done only once
>- edit attributes (should be possible to enter values as decimal, hex or 
> binary)
>- edit streams, while keeping or changing the compression filter
>- save altered PDF 
>- color mark of certain PDF operators, especially Q...q and text operators 
> (BT...ET). Ideally, it should help the user understand the "bracketing" of 
> these operators, i.e. understand where a sequence starts and where it ends. 
> (See "operator summary" in the PDF Spec) Other "important" operators I can 
> think of are the matrix, font and color operators. A cool advanced thing 
> would be to show the current color or the font in a popup when hovering above 
> such an operator.
> To see a product with a similar purpose that is better than PDFDebugger, 
> watch [this video|https://www.youtube.com/watch?v=g-QcU9B4qMc].
> I'm not asking to implement a clone of that product (I don't use it, all I 
> know is that video), but we at PDFBox really need something that makes PDF 
> debugging easier. As an example of how the current PDFDebugger prevented me 
> from finding a bug quickly, see PDFBOX-2401 and search for "PDFDebugger".
> Prerequisites:
> - java programming, especially the GUI components
> - the ability to understand existing source code
> Using external software components is possible (must have Apache License or a 
> compatible one), but should be decided on a case-by-case basis, we don't want 
> to get too big.
> Development strategy: go from the easy to the difficult. The wished features 
> are already sorted this way (mostly).
> Get introduced: [download the source code with 
> svn|https://pdfbox.apache.org/downloads.html#scm] and build it with maven. 
> Run PDFDebugger and view some PDFs to see the components of a PDF. Start with 
> the file of PDFBOX-2401. Read up something about the structure of PDF on the 
> web or from the [PDF 
> Specification|https://www.adobe.com/devnet/pdf/pdf_reference.html].
> Mentor: Tilman Hausherr (European timezone, languages: german, english, 
> french). To see the GSoC2014 project I mentored, go to PDFBOX-1915.



--
This message was sen

[jira] [Resolved] (PDFBOX-1453) NPE saving modified encrypted document

[JIRA]

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

Andreas Lehmkühler resolved PDFBOX-1453.

Resolution: Fixed

I've added the additional logging as proposed by [~tilman]

Set to resolved.

> NPE saving modified encrypted document
> --
>
> Key: PDFBOX-1453
> URL: https://issues.apache.org/jira/browse/PDFBOX-1453
> Project: PDFBox
>  Issue Type: Bug
>  Components: Crypto, Writing
>Affects Versions: 1.8.7, 1.8.9, 1.8.10, 2.0.0
>Reporter: Andrea Vacondio
>Assignee: Andreas Lehmkühler
> Fix For: 1.8.10
>
> Attachments: TestEnc.zip
>
>
> I posted this on the mailing list but got no answer. I'm describing here some 
> behaviors that are triggering NPE when saving a modified pdf document.
> What I'm trying to do is to open an encrypted document, modify it, save it 
> back (I attached my test project). The three tests I made they all end up 
> with a NPE but they work if I turn on setAllSecurityToBeRemoved (and I don't 
> want security to be removed).
> First test: 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Second test 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded but not decrypted 
> 3- permissions.isOwnerPermission() is true, why? I didn't provide any owner 
> pwd I should not have owner permissions. 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Third test 
> 1- input is a doc encrypted with owner pwd having NO permission. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct
>  4- permissions.canModify() is true, why? I can modify the doc because I have 
> owner permission but the Modify should be off.
>  5- modify the doc and save throws a NPE which is NOT correct 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Updated] (PDFBOX-1453) NPE saving modified encrypted document

[JIRA]

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

Andreas Lehmkühler updated PDFBOX-1453:
---
Fix Version/s: (was: 2.0.0)
   1.8.10

> NPE saving modified encrypted document
> --
>
> Key: PDFBOX-1453
> URL: https://issues.apache.org/jira/browse/PDFBOX-1453
> Project: PDFBox
>  Issue Type: Bug
>  Components: Crypto, Writing
>Affects Versions: 1.8.7, 1.8.9, 1.8.10, 2.0.0
>Reporter: Andrea Vacondio
>Assignee: Andreas Lehmkühler
> Fix For: 1.8.10
>
> Attachments: TestEnc.zip
>
>
> I posted this on the mailing list but got no answer. I'm describing here some 
> behaviors that are triggering NPE when saving a modified pdf document.
> What I'm trying to do is to open an encrypted document, modify it, save it 
> back (I attached my test project). The three tests I made they all end up 
> with a NPE but they work if I turn on setAllSecurityToBeRemoved (and I don't 
> want security to be removed).
> First test: 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Second test 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded but not decrypted 
> 3- permissions.isOwnerPermission() is true, why? I didn't provide any owner 
> pwd I should not have owner permissions. 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Third test 
> 1- input is a doc encrypted with owner pwd having NO permission. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct
>  4- permissions.canModify() is true, why? I can modify the doc because I have 
> owner permission but the Modify should be off.
>  5- modify the doc and save throws a NPE which is NOT correct 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-1453) NPE saving modified encrypted document

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608765#comment-14608765
 ] 

ASF subversion and git services commented on PDFBOX-1453:
-

Commit 1688495 from [~lehmi] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1688495 ]

PDFBOX-1453: added info log if the access permission is accessed without 
decrypting an encrypted pdf as proposed by Tilman Hausherr

> NPE saving modified encrypted document
> --
>
> Key: PDFBOX-1453
> URL: https://issues.apache.org/jira/browse/PDFBOX-1453
> Project: PDFBox
>  Issue Type: Bug
>  Components: Crypto, Writing
>Affects Versions: 1.8.7, 1.8.9, 1.8.10, 2.0.0
>Reporter: Andrea Vacondio
>Assignee: Andreas Lehmkühler
> Fix For: 2.0.0
>
> Attachments: TestEnc.zip
>
>
> I posted this on the mailing list but got no answer. I'm describing here some 
> behaviors that are triggering NPE when saving a modified pdf document.
> What I'm trying to do is to open an encrypted document, modify it, save it 
> back (I attached my test project). The three tests I made they all end up 
> with a NPE but they work if I turn on setAllSecurityToBeRemoved (and I don't 
> want security to be removed).
> First test: 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Second test 
> 1- input is a doc encrypted with owner pwd having the modify permission on. 
> 2- The document is loaded but not decrypted 
> 3- permissions.isOwnerPermission() is true, why? I didn't provide any owner 
> pwd I should not have owner permissions. 
> 4- permissions.canModify() is true which is correct 
> 5- modify the doc and save throws a NPE which is NOT correct
> Third test 
> 1- input is a doc encrypted with owner pwd having NO permission. 
> 2- The document is loaded and decrypted using owner pwd. 
> 3- permissions.isOwnerPermission() is true which is correct
>  4- permissions.canModify() is true, why? I can modify the doc because I have 
> owner permission but the Modify should be off.
>  5- modify the doc and save throws a NPE which is NOT correct 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Jim deVos (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608756#comment-14608756
 ] 

Jim deVos commented on PDFBOX-2847:
---

Great to hear, thanks so much for the quick response.

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2846) setValue failing with font issues.

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608417#comment-14608417
 ] 

Tilman Hausherr commented on PDFBOX-2846:
-

It works fine for me on Windows 7 with this code:
{code}
PDDocumentCatalog catalog = doc.getDocumentCatalog();
PDAcroForm acroForm = catalog.getAcroForm();
PDTextField fieldtest = (PDTextField) acroForm.getField("certNo");
fieldtest.setValue("test Something");
{code}
One difference to your code: a cast to PDTextField. But if the wikipedia 
article on groovy is correct, you used dynamic typing, so it doesn't matter. 
Make sure you have the latest version, there were some changes in fontbox 
recently.

If it still doesn't work, maybe it happens only on Ubuntu :-( To verify this, 
could you temporarly replace your font with one from a W7 system? The file is 
in \Windows\Fonts\arialbd.ttf . Re the OSX problem, is there more in the stack 
trace, e.g. a "caused by" part?

> setValue failing with font issues.
> --
>
> Key: PDFBOX-2846
> URL: https://issues.apache.org/jira/browse/PDFBOX-2846
> Project: PDFBox
>  Issue Type: Bug
>  Components: AcroForm
>Affects Versions: 2.0.0
> Environment: Ubuntu, Java 7 & OS X Java 7
>Reporter: Aaron Eischeid
> Attachments: Pulmotil_VFD_Swine_Template.pdf
>
>
> attempting to upgrade from 1.8.9 to 2.0.0 and Working with the snapshot 
> builds I am bumping into what might be a bug regarding fonts.
> trying to setValue on a PDTextField object. If the value contains a space 
> char I get an error.
> on Ubuntu my stacktrace is: 
> {code}
> No glyph for U+0020 in font Arial-BoldMT. Stacktrace follows:
> java.lang.IllegalArgumentException: No glyph for U+0020 in font Arial-BoldMT
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.encode(PDTrueTypeFont.java:297)
>   at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:282)
>   at org.apache.pdfbox.pdmodel.font.PDFont.getStringWidth(PDFont.java:311)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PlainText$Paragraph.getLines(PlainText.java:169)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:177)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:246)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:152)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
> ...
> {code}
> On OS X the stacktrace is : 
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.pdfbox.pdmodel.font.FontMapper$DefaultFontProvider
>   at 
> org.apache.pdfbox.pdmodel.font.FontMapper.getProvider(FontMapper.java:99)
>   at 
> org.apache.pdfbox.pdmodel.font.FontMapper.findFont(FontMapper.java:428)
>   at 
> org.apache.pdfbox.pdmodel.font.FontMapper.getTrueTypeFont(FontMapper.java:326)
>   at 
> org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.(PDTrueTypeFont.java:155)
>   at 
> org.apache.pdfbox.pdmodel.font.PDFontFactory.createFont(PDFontFactory.java:75)
>   at org.apache.pdfbox.pdmodel.PDResources.getFont(PDResources.java:96)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDAppearanceString.copyNeededResourcesTo(PDAppearanceString.java:173)
>   at org.apache.pdfbox.
> pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:130)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:106)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:262)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:220)
>   at 
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:217)
> ...
> {code}
> not sure what the difference is on the two systems that causes this, but this 
> and the fact that setField worked pretty well in 1.8.9 with the same pdf file 
> makes me think it isn't related entirely to something broken about the 
> embedded font in the pdf.
> example (groovy) code for setting a value
> {code}
>   ...
>   PDDocumentCatalog catalog = docume

[jira] [Commented] (PDFBOX-2842) Overhaul font substitution

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608413#comment-14608413
 ] 

Tilman Hausherr commented on PDFBOX-2842:
-

I looked at the rendering of PDFBOX-1422.pdf at a higher resolution, it isn't a 
serif font. You just substituted STXihei with a different font. I ran an older 
snapshot, at that time you used ArialMT, now you use LiberationSans, so that's 
ok for me if that was your intention.

> Overhaul font substitution
> --
>
> Key: PDFBOX-2842
> URL: https://issues.apache.org/jira/browse/PDFBOX-2842
> Project: PDFBox
>  Issue Type: Improvement
>  Components: FontBox, PDModel
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Fix For: 2.0.0
>
> Attachments: 166292-fi-ligature.pdf
>
>
> The improved font substitution mechanisms in 2.0 are not quite sufficient to 
> handle all PDFs. Specifically, CJK substitution and substitution of TTF in 
> place of CFF fonts is not possible with the current design.
> The CJK problems can be seen in PDFBOX-2509 and PDFBOX-2563, which does not 
> solve the problem. Additional font API weaknesses can be found in PDFBOX-2578 
> and PDFBOX-2366. This meta-issue aims to address all of those sub-issues.
> The current problems are:
> - FontBox does not provide a generic font type, so we have handle 
> TrueTypeFont, CFFFont, and Type1Font separately. This hinders cross-format 
> substitution.
> - ExternalFonts has no knowledge of the CIDSystemInfo which is necessary for 
> CJK substitution
> - FontProvider contains too much public logic which should be internal to 
> PDFBox, e.g. substitution logic, this makes it brittle and means we won't be 
> able to add additional logic after 2.0 is released, e.g. CJK substitution.
> - Too much confusion about the role of ExternalFonts, particularly with 
> regards to mapping of built-in fonts and the definition of substitute vs. 
> fallback font.
> - ExternalFonts is a black box: the user cannot tell whether the font 
> returned is an exact match, or a last-resort fallback.
> - Confusing font substitution API, users preferred having a flat file format
> - PDSimpleFont#getEncoding() can return null for TTFs which use built-in 
> encodings. This has caused a lot of bugs - there must be a better way.
> - We still have some confusing names, for example a CustomEncoding is known 
> as a "built-in encoding" in the spec.
> - There is no fallback CFF font, we resort to AdobeBlank instead, which has 
> no rendering.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2842) Overhaul font substitution

[Maruan Sahyoun (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608257#comment-14608257
 ] 

Maruan Sahyoun commented on PDFBOX-2842:


Yes, but isn't that what the o.a.fontbox namespace is for. There are already a 
number of other 'duplicate' names in Java e.g. java.util.List and java.awt.List.

To me Font would be the easiest but any other name which doesn't duplicate the 
namepace is also fine. At the end it's a minor issue.

> Overhaul font substitution
> --
>
> Key: PDFBOX-2842
> URL: https://issues.apache.org/jira/browse/PDFBOX-2842
> Project: PDFBox
>  Issue Type: Improvement
>  Components: FontBox, PDModel
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
> Fix For: 2.0.0
>
> Attachments: 166292-fi-ligature.pdf
>
>
> The improved font substitution mechanisms in 2.0 are not quite sufficient to 
> handle all PDFs. Specifically, CJK substitution and substitution of TTF in 
> place of CFF fonts is not possible with the current design.
> The CJK problems can be seen in PDFBOX-2509 and PDFBOX-2563, which does not 
> solve the problem. Additional font API weaknesses can be found in PDFBOX-2578 
> and PDFBOX-2366. This meta-issue aims to address all of those sub-issues.
> The current problems are:
> - FontBox does not provide a generic font type, so we have handle 
> TrueTypeFont, CFFFont, and Type1Font separately. This hinders cross-format 
> substitution.
> - ExternalFonts has no knowledge of the CIDSystemInfo which is necessary for 
> CJK substitution
> - FontProvider contains too much public logic which should be internal to 
> PDFBox, e.g. substitution logic, this makes it brittle and means we won't be 
> able to add additional logic after 2.0 is released, e.g. CJK substitution.
> - Too much confusion about the role of ExternalFonts, particularly with 
> regards to mapping of built-in fonts and the definition of substitute vs. 
> fallback font.
> - ExternalFonts is a black box: the user cannot tell whether the font 
> returned is an exact match, or a last-resort fallback.
> - Confusing font substitution API, users preferred having a flat file format
> - PDSimpleFont#getEncoding() can return null for TTFs which use built-in 
> encodings. This has caused a lot of bugs - there must be a better way.
> - We still have some confusing names, for example a CustomEncoding is known 
> as a "built-in encoding" in the spec.
> - There is no fallback CFF font, we resort to AdobeBlank instead, which has 
> no rendering.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2370) Move caching outside of PDResources

[JIRA]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608090#comment-14608090
 ] 

Andreas Lehmkühler commented on PDFBOX-2370:


Any update on this? The first method doesn't seem to be relevant any more and 
the second one doesn't exist anymore.

> Move caching outside of PDResources
> ---
>
> Key: PDFBOX-2370
> URL: https://issues.apache.org/jira/browse/PDFBOX-2370
> Project: PDFBox
>  Issue Type: Improvement
>  Components: PDModel
>Affects Versions: 2.0.0
>Reporter: John Hewson
>Assignee: John Hewson
>Priority: Blocker
> Fix For: 2.0.0
>
>
> *Note:* This issue is based on a discussion which occurred regarding 
> PDFBOX-2301 but is actually a separate issue.
> Currently we cache the page resources in PDResources which belongs to a 
> specific PDPage. This causes two problems, 1) users who want to hold many 
> PDPage objects in memory will have high memory use (but this is often by 
> accident*). 2) By caching resources in PDPage we only get to keep that cache 
> for the lifetime of the page, which e.g. in PDFRenderer is a single page 
> only. That means that a font which appears on 40 pages has to be parsed 40 
> times, which causes slow running times, but also memory thrashing as objects 
> are destroyed frequently only to be re-created.
> What PDFRenderer really needs is not page-wide caching but document-wide 
> caching, so that it can cache fonts, cmaps, color profiles, etc. only once. 
> But that won't work for images, because they're too large. What we're 
> beginning to realise is that caching is use-case specific and probably 
> shouldn't be built-in to PDFBox's pdmodel. Instead we should removing 
> resource caching from PDPage/PDResources and implement custom caching in 
> PDFRenderer and other downstream classes such as PDFTextStripper. I'll 
> happily volunteer myself. The existing high-level PDFBox APIs will continue 
> to "just work" and power users will get a level of control that they 
> appreciate.
> This strategy could be enhanced by removing memory-hungry methods on 
> PDResources such as getFonts() and getXObjects() which force all resources of 
> a particular type to be loaded, whether or not they are needed, or actually 
> used in the content stream. They would be replaced by methods to retrieve a 
> single resource, e.g. getFont(name).
> ---
> \* There probably isn't a legitimate use case for 1) any more, we've solved 
> the issues which we used to have with image caching (in fact, the 
> clearCache() method actually no longer needs to be called by PDFRenderer, 
> though it currently is). The real problem is that it's easy to accidentally 
> retain PDPage objects, the PDDocument#getDocumentCatalog().getAllPages() 
> method is dangerous as looping over it will cause pages to be retained during 
> processing, like so:
> {code}
> for (PDPage page : document.getDocumentCatalog().getAllPages()) // 
> java.util.List
> {
>  // ... this is idiomatic in PDFBox 1.8
> } 
> // List returned by getAllPages() kept in scope until here (bad)
> {code}
> I added of couple of methods a while ago to avoid this by fetching each 
> PDPage one at a time, and this is now used internally in PDFBox to avoid the 
> memory problems we used to have:
> {code}
> for (int i = 0; i < document.getNumberOfPages(); i++)
> {
> PDPage page = document.getPage(i);
> // ... this is the new 2.0 way
> // current page falls out of scope here (good)
> }
> {code}
> To solve this problem, we could change getAllPages() so that instead of 
> returning a List it returns an Iterator, which would provide a nicer 
> API than getPage(int) and most existing code will continue to work. This is 
> also an opportunity to also fix type safety issues due to PDPageNode and 
> incorrect handling of the page tree (this is similar to the issue we had 
> recently with the acroform field tree).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

PDFBox 1.8.10 release

[Andreas Lehmkühler]

Hi,

there are again a number of solved issues and I'm thinking about a new
bugfix release. How about a new one next week, maybe later if someone
wants to get some addtional things done before?

WDYT?

BR
Andreas Lehmkühler

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Re: Broken Build

[Andreas Lehmkühler]

Hi,

> Andreas Lehmkuehler  hat am 21. Juni 2015 um 14:03
> geschrieben:
> 
> 
> Hi,
> 
> Am 17.06.2015 um 06:38 schrieb Andreas Lehmkuehler:
> > Hi,
> >
> > Am 12.06.2015 um 12:17 schrieb Andreas Lehmkühler:
> >> Hi,
> >>
> >>> John Hewson  hat am 11. Juni 2015 um 19:43 geschrieben:
> >>>
> >>>
> >>> Our build has been failing for about a day now, with this message:
> >>>
> >>> [WARNING] Could not transfer metadata
> >>> org.apache.pdfbox:pdfbox-parent:2.0.0-SNAPSHOT/maven-metadata.xml from/to
> >>> apache.snapshots.https
> >>> (https://repository.apache.org/content/repositories/snapshots): peer not
> >>> authenticated
> >>>
> >>> Anybody know why?
> >> Tilman and I already tried to find out the reason. No answer on builds@ so
> >> far,
> >> but it seems jdk related. I've configured the build to use 1.7 and
> >> everything
> >> works so far, but the tests useing strong encryption.
> >>
> >> I've created a ticket too
> >>
> >> https://issues.apache.org/jira/browse/BUILDS-85
> > Infra reconfigured nexus so that one can use java 6 again. The build is back
> > to
> > normal.
> Infra is still thinking about the configuration they want to use. The current 
> configuration doesn't work with jdk6 so that I've reconfigured our builds to
> use 
> jdk7. As there isn't any jdk including unlimited security the tests will fail.
I've set up a new build job [1] using java 6 incl. unlimited security to ensure
that everything works. The new job doesn't deploy to the nexus repository. The
ailing build is still active as it is used to deploy the SNAPSHOT artifacts to
the nexus repos.

BR 
Andreas

[1]
https://builds.apache.org/user/lehmi/my-views/view/PDFBox/job/PDFBox-trunk%20(JDK%201.6.0%20unlimited%20security)/

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Comment Edited] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607878#comment-14607878
 ] 

Tilman Hausherr edited comment on PDFBOX-2847 at 6/30/15 9:35 AM:
--

Thanks, I committed that, with an expanded test, i.e. that both get tested. 
I'll also add the use of a scratch file into the 2.0 version.


was (Author: tilman):
Thanks, I committed that, with an expanded test, i.e. that both get tested.

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Tilman Hausherr (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607878#comment-14607878
 ] 

Tilman Hausherr commented on PDFBOX-2847:
-

Thanks, I committed that, with an expanded test, i.e. that both get tested.

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607875#comment-14607875
 ] 

ASF subversion and git services commented on PDFBOX-2847:
-

Commit 1688384 from [~tilman] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1688384 ]

PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by Jim deVos

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Commented] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PDFBOX-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14607874#comment-14607874
 ] 

ASF subversion and git services commented on PDFBOX-2847:
-

Commit 1688382 from [~tilman] in branch 'pdfbox/branches/1.8'
[ https://svn.apache.org/r1688382 ]

PDFBOX-2847: use scratchFile for mergeDocumentsNonSeq, as suggested by Jim deVos

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

[jira] [Assigned] (PDFBOX-2847) mergeDocumentsNonSeq does not utilize scratchFile

[Tilman Hausherr (JIRA)]

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

Tilman Hausherr reassigned PDFBOX-2847:
---

Assignee: Tilman Hausherr

> mergeDocumentsNonSeq does not utilize scratchFile
> -
>
> Key: PDFBOX-2847
> URL: https://issues.apache.org/jira/browse/PDFBOX-2847
> Project: PDFBox
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 1.8.9
>Reporter: Jim deVos
>Assignee: Tilman Hausherr
> Attachments: pdfbox1.8.x.patch
>
>
> I noticed when merging relatively large pdfs (1gb)  that the heap would grow 
> by at least the same amount until complete, even when I call 
> mergeDocumentsNonSeq() and supplying a read/write scratchfile.   
> When I looked at the source for mergeDocuments(bool, RandomAccess),  it looks 
> like the scratch file is never used.
> {code}
> private void mergeDocuments(boolean isNonSeq, RandomAccess scratchFile) 
> throws IOException, COSVisitorException
> {
> //...snip
> if (isNonSeq)
> {
> source = PDDocument.loadNonSeq(sourceFile, null);
> }
> //...snip
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org