[jira] [Commented] (PDFBOX-5637) Add getter and setter for the CO array under PDAcroForm
[ https://issues.apache.org/jira/browse/PDFBOX-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747397#comment-17747397 ] Gilad Denneboom commented on PDFBOX-5637: - File with calculated fields (and an CO array as a result) attached. > Add getter and setter for the CO array under PDAcroForm > --- > > Key: PDFBOX-5637 > URL: https://issues.apache.org/jira/browse/PDFBOX-5637 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.29 >Reporter: Gilad Denneboom >Priority: Minor > Fix For: 2.0.30, 3.0.0 PDFBox > > Attachments: calc order test.pdf > > > The CO-array is a part of the AcroForm object, which defines the order in > which fields are calculated (see Table 218 in the PDF ISO specs). It contains > (indirect) references to the calculated fields. > It would be nice to have a direct getter and setter for it under PDAcroForm. > Also, if the references could be automatically converted to point to the > actual PDField objects, that would be great. > In order to do that, the values from this array need to be compared to those > returned by the getCOSObject method of the PDField objects returned by the > getFields methods of PDAcroForm. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5637) Add getter and setter for the CO array under PDAcroForm
[ https://issues.apache.org/jira/browse/PDFBOX-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-5637: Attachment: calc order test.pdf > Add getter and setter for the CO array under PDAcroForm > --- > > Key: PDFBOX-5637 > URL: https://issues.apache.org/jira/browse/PDFBOX-5637 > Project: PDFBox > Issue Type: Improvement > Components: AcroForm >Affects Versions: 2.0.29 >Reporter: Gilad Denneboom >Priority: Minor > Fix For: 2.0.30, 3.0.0 PDFBox > > Attachments: calc order test.pdf > > > The CO-array is a part of the AcroForm object, which defines the order in > which fields are calculated (see Table 218 in the PDF ISO specs). It contains > (indirect) references to the calculated fields. > It would be nice to have a direct getter and setter for it under PDAcroForm. > Also, if the references could be automatically converted to point to the > actual PDField objects, that would be great. > In order to do that, the values from this array need to be compared to those > returned by the getCOSObject method of the PDField objects returned by the > getFields methods of PDAcroForm. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5638) Add getter and setter for the Tabs COSName value under PDPage
Gilad Denneboom created PDFBOX-5638: --- Summary: Add getter and setter for the Tabs COSName value under PDPage Key: PDFBOX-5638 URL: https://issues.apache.org/jira/browse/PDFBOX-5638 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 2.0.29 Reporter: Gilad Denneboom Attachments: tab order test.pdf Defined in Table 30 of the PDF 1.7 ISO specs, the Tabs key is an optional COSName value under PDPage that defines the tab order of the annotations on the page. The specs define its possible values as: R (row order), C (column order), and S (structure order). However, from inspecting PDF files created by Acrobat it seems that another value can be used, namely "W", when the form's author specifies the tab order manually. See attached file. A getter/setter for this value is missing from the PDPage implementation. Also, the "Tabs" key itself is missing from the COSName enum and should be added. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5637) Add getter and setter for the CO array under PDAcroForm
Gilad Denneboom created PDFBOX-5637: --- Summary: Add getter and setter for the CO array under PDAcroForm Key: PDFBOX-5637 URL: https://issues.apache.org/jira/browse/PDFBOX-5637 Project: PDFBox Issue Type: Improvement Components: AcroForm Affects Versions: 2.0.29 Reporter: Gilad Denneboom The CO-array is a part of the AcroForm object, which defines the order in which fields are calculated (see Table 218 in the PDF ISO specs). It contains (indirect) references to the calculated fields. It would be nice to have a direct getter and setter for it under PDAcroForm. Also, if the references could be automatically converted to point to the actual PDField objects, that would be great. In order to do that, the values from this array need to be compared to those returned by the getCOSObject method of the PDField objects returned by the getFields methods of PDAcroForm. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561938#comment-17561938 ] Gilad Denneboom commented on PDFBOX-5470: - PS. I tested it in another file and there the page numbers were 0-based, as expected. > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, > image-2022-07-03-17-30-29-113.png, image-2022-07-03-17-31-04-424.png, > screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561890#comment-17561890 ] Gilad Denneboom commented on PDFBOX-5470: - > and now it works, although it shows page 4 instead of page 2. That worked for me too! And yeah, it seems the page numbers start with -1, which is very odd. At least it works! > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, > image-2022-07-03-17-30-29-113.png, image-2022-07-03-17-31-04-424.png, > screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[
https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561889#comment-17561889
]
Gilad Denneboom commented on PDFBOX-5470:
-
I added it manually and it converted the whole string to Unicode, but also
inserted the space character twice, for some reason...
Code: target.setFilename("\uFEFF" + key);
Result:
!image-2022-07-03-17-31-04-424.png!
> PDActionEmbeddedGoTo does not accept a Destination with a page number or
> string
> ---
>
> Key: PDFBOX-5470
> URL: https://issues.apache.org/jira/browse/PDFBOX-5470
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm
>Affects Versions: 2.0.26
>Reporter: Gilad Denneboom
>Assignee: Tilman Hausherr
>Priority: Minor
> Fix For: 2.0.27, 3.0.0 PDFBox
>
> Attachments: EmbeddedActionTest-1.java, LinkTest.pdf,
> LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt,
> image-2022-07-03-17-30-29-113.png, image-2022-07-03-17-31-04-424.png,
> screenshot-1.png
>
>
> According to Table 202 of the PDF 32000-1:2008 specs, the P key under the
> Target Directory of an Embedded Go-To Action is an "integer or byte string",
> with the following description "If the value is an integer, it specifies the
> page number (zero-based) in the current document containing the file
> attachment annotation. If the value is a string, it specifies a named
> destination in the current document that provides the page number of the file
> attachment annotation."
> However, the current implementation of PDActionEmbeddedGoTo does not accept
> using the setPageNumber command by itself when setting the Destination
> dictionary, and throws an IllegalArgumentException unless setPage is used to
> set the target page as a PDPage object, which is not specified in the
> documentation. Also, there doesn't seem to be a way to specify the target as
> a string, if a named destination is to be used.
> This applies to both the Destination dictionary and the Target Directory, but
> when creating such a link in Acrobat the Target Directory does not contain a
> P value at all, only the Destination dictionary does, and in the form of a
> number. This should be possible to replicate using PDFBox.
>
> Attached are a sample file with a pre-existing link and a PDF attachment, the
> code trying to set that link's action to open the attachment on page 3, and
> the resulting error message stack trace.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-5470: Attachment: image-2022-07-03-17-31-04-424.png > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, > image-2022-07-03-17-30-29-113.png, image-2022-07-03-17-31-04-424.png, > screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-5470: Attachment: image-2022-07-03-17-30-29-113.png > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, > image-2022-07-03-17-30-29-113.png, screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561887#comment-17561887 ] Gilad Denneboom commented on PDFBOX-5470: - Could it be the Zero Width No-Break Space (\uFEFF) character before the file-name, do you think? > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561877#comment-17561877 ] Gilad Denneboom commented on PDFBOX-5470: - I changed the setFilename line to: target.setFilename(new String(key.getBytes(), StandardCharsets.UTF_8)); But the results are the same. > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt, screenshot-1.png > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561876#comment-17561876 ] Gilad Denneboom commented on PDFBOX-5470: - Strange... Where do you see that's it's UTF8 encoded? And do you mean that if I created the attachments using PDFBox, instead of doing it in Acrobat, it would work? Could I extract them from the PDF as separate files, reset the EmbeddedFiles array, and then re-attach them? > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561856#comment-17561856 ] Gilad Denneboom commented on PDFBOX-5470: - Thanks a lot, Tilman! I updated the jar file in my project, and it's indeed not throwing an Exception any longer, but the link still doesn't work. I compared the A dictionary of a link created in Acrobat with that created using PDFBox (I used the PDF Debugger) and am not seeing any differences that would explain why this is happening. I attached the output created by the code, and the same file edited by Acrobat. Any insight would be welcome! > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561856#comment-17561856 ] Gilad Denneboom edited comment on PDFBOX-5470 at 7/3/22 12:07 PM: -- Thanks a lot, Tilman! I updated the jar file in my project, and it's indeed not throwing an Exception any longer, but the link still doesn't work. I compared the A dictionary of a link created in Acrobat with that created using PDFBox (I used the PDF Debugger) and am not seeing any differences that would explain why this is happening. I attached the output created by the code, and the same file edited by Acrobat. Any insight would be welcome! PS. I added the following line to the code, just in case: dest.setTop(0); was (Author: giladd): Thanks a lot, Tilman! I updated the jar file in my project, and it's indeed not throwing an Exception any longer, but the link still doesn't work. I compared the A dictionary of a link created in Acrobat with that created using PDFBox (I used the PDF Debugger) and am not seeing any differences that would explain why this is happening. I attached the output created by the code, and the same file edited by Acrobat. Any insight would be welcome! > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
[ https://issues.apache.org/jira/browse/PDFBOX-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-5470: Attachment: LinkTest_edited.pdf LinkTest_Acrobat.pdf > PDActionEmbeddedGoTo does not accept a Destination with a page number or > string > --- > > Key: PDFBOX-5470 > URL: https://issues.apache.org/jira/browse/PDFBOX-5470 > Project: PDFBox > Issue Type: Bug > Components: AcroForm >Affects Versions: 2.0.26 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 2.0.27, 3.0.0 PDFBox > > Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, > LinkTest_Acrobat.pdf, LinkTest_edited.pdf, StackTrace.txt > > > According to Table 202 of the PDF 32000-1:2008 specs, the P key under the > Target Directory of an Embedded Go-To Action is an "integer or byte string", > with the following description "If the value is an integer, it specifies the > page number (zero-based) in the current document containing the file > attachment annotation. If the value is a string, it specifies a named > destination in the current document that provides the page number of the file > attachment annotation." > However, the current implementation of PDActionEmbeddedGoTo does not accept > using the setPageNumber command by itself when setting the Destination > dictionary, and throws an IllegalArgumentException unless setPage is used to > set the target page as a PDPage object, which is not specified in the > documentation. Also, there doesn't seem to be a way to specify the target as > a string, if a named destination is to be used. > This applies to both the Destination dictionary and the Target Directory, but > when creating such a link in Acrobat the Target Directory does not contain a > P value at all, only the Destination dictionary does, and in the form of a > number. This should be possible to replicate using PDFBox. > > Attached are a sample file with a pre-existing link and a PDF attachment, the > code trying to set that link's action to open the attachment on page 3, and > the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561832#comment-17561832 ] Gilad Denneboom commented on PDFBOX-4117: - See: https://issues.apache.org/jira/browse/PDFBOX-5470 > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Fix For: 2.0.9, 3.0.0 PDFBox > > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-5470) PDActionEmbeddedGoTo does not accept a Destination with a page number or string
Gilad Denneboom created PDFBOX-5470: --- Summary: PDActionEmbeddedGoTo does not accept a Destination with a page number or string Key: PDFBOX-5470 URL: https://issues.apache.org/jira/browse/PDFBOX-5470 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 2.0.26 Reporter: Gilad Denneboom Attachments: EmbeddedActionTest-1.java, LinkTest.pdf, StackTrace.txt According to Table 202 of the PDF 32000-1:2008 specs, the P key under the Target Directory of an Embedded Go-To Action is an "integer or byte string", with the following description "If the value is an integer, it specifies the page number (zero-based) in the current document containing the file attachment annotation. If the value is a string, it specifies a named destination in the current document that provides the page number of the file attachment annotation." However, the current implementation of PDActionEmbeddedGoTo does not accept using the setPageNumber command by itself when setting the Destination dictionary, and throws an IllegalArgumentException unless setPage is used to set the target page as a PDPage object, which is not specified in the documentation. Also, there doesn't seem to be a way to specify the target as a string, if a named destination is to be used. This applies to both the Destination dictionary and the Target Directory, but when creating such a link in Acrobat the Target Directory does not contain a P value at all, only the Destination dictionary does, and in the form of a number. This should be possible to replicate using PDFBox. Attached are a sample file with a pre-existing link and a PDF attachment, the code trying to set that link's action to open the attachment on page 3, and the resulting error message stack trace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561737#comment-17561737 ] Gilad Denneboom commented on PDFBOX-4117: - I'm back to this class and am having issues using it to link to a specific page of an embedded PDF file. When I try to use setPageNumber on the PDDestination object I get the following error message: java.lang.IllegalArgumentException: Destination of a GoToE action must be a page dictionary object However, I don't see a way to get a reference to the PDPage object for the target page so I could use it with setPage. I think the implementation of this class needs to be adjusted to allow specifying only a page number, not a Page object. Acrobat does that when you create such links manually. The COSArray under D contains a page number reference in the first item, not a page reference. > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Fix For: 2.0.9, 3.0.0 PDFBox > > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4641) Keywords created using PDFBox are not visible in Acrobat
[ https://issues.apache.org/jira/browse/PDFBOX-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921727#comment-16921727 ] Gilad Denneboom commented on PDFBOX-4641: - Thanks, [~tilman] ! > Keywords created using PDFBox are not visible in Acrobat > > > Key: PDFBOX-4641 > URL: https://issues.apache.org/jira/browse/PDFBOX-4641 > Project: PDFBox > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.8.16, 2.0.16 > Environment: Windows 7, Eclipse 4.2.2, Acrobat Pro 11.0.10 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Minor > Fix For: 1.8.17, 2.0.17, 3.0.0 PDFBox > > Attachments: ApplyKeywords.java, Keywords test.pdf, Keywords > test_added in Acrobat.pdf, Keywords test_edited.pdf > > > Setting new keywords using PDFBox 2.0.16 inserts the data into the file > (confirmed via the PDF Debugger and running a script in Acrobat), but the > keywords are not displayed in the Acrobat GUI. This might be a bug of Acrobat > itself, but it will be good to know why this is happening, and whether it can > be solved. > > Attached are a blank sample file created in Acrobat, with no metadata, a java > file with the code I used, and the result of running it on that file. When I > open the edited file in Acrobat (11.0.10) the Properties window is still > empty. However, running the following code from the JS Console does print out > the correct output: > this.info.Keywords > Output: > NEW KEYWORDS > > I'm also attaching the same file after I've added keywords to in Acrobat, so > the internal structure could be compared with what PDFBox does. I didn't see > much of a difference, but maybe I missed something. > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4641) Keywords created using PDFBox are not visible in Acrobat
[ https://issues.apache.org/jira/browse/PDFBOX-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920661#comment-16920661 ] Gilad Denneboom commented on PDFBOX-4641: - Thanks Tilman, that worked. Strange that there's such a parallel way of doing it... Maybe it would be a good idea to create a util that will set both things at the same time? > Keywords created using PDFBox are not visible in Acrobat > > > Key: PDFBOX-4641 > URL: https://issues.apache.org/jira/browse/PDFBOX-4641 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.16 > Environment: Windows 7, Eclipse 4.2.2, Acrobat Pro 11.0.10 >Reporter: Gilad Denneboom >Priority: Minor > Attachments: ApplyKeywords.java, Keywords test.pdf, Keywords > test_added in Acrobat.pdf, Keywords test_edited.pdf > > > Setting new keywords using PDFBox 2.0.16 inserts the data into the file > (confirmed via the PDF Debugger and running a script in Acrobat), but the > keywords are not displayed in the Acrobat GUI. This might be a bug of Acrobat > itself, but it will be good to know why this is happening, and whether it can > be solved. > > Attached are a blank sample file created in Acrobat, with no metadata, a java > file with the code I used, and the result of running it on that file. When I > open the edited file in Acrobat (11.0.10) the Properties window is still > empty. However, running the following code from the JS Console does print out > the correct output: > this.info.Keywords > Output: > NEW KEYWORDS > > I'm also attaching the same file after I've added keywords to in Acrobat, so > the internal structure could be compared with what PDFBox does. I didn't see > much of a difference, but maybe I missed something. > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4641) Keywords created using PDFBox are not visible in Acrobat
[ https://issues.apache.org/jira/browse/PDFBOX-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-4641: Environment: Windows 7, Eclipse 4.2.2, Acrobat Pro 11.0.10 (was: Windows 7, Eclipse 4.2.2) > Keywords created using PDFBox are not visible in Acrobat > > > Key: PDFBOX-4641 > URL: https://issues.apache.org/jira/browse/PDFBOX-4641 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.16 > Environment: Windows 7, Eclipse 4.2.2, Acrobat Pro 11.0.10 >Reporter: Gilad Denneboom >Priority: Minor > Attachments: ApplyKeywords.java, Keywords test.pdf, Keywords > test_added in Acrobat.pdf, Keywords test_edited.pdf > > > Setting new keywords using PDFBox 2.0.16 inserts the data into the file > (confirmed via the PDF Debugger and running a script in Acrobat), but the > keywords are not displayed in the Acrobat GUI. This might be a bug of Acrobat > itself, but it will be good to know why this is happening, and whether it can > be solved. > > Attached are a blank sample file created in Acrobat, with no metadata, a java > file with the code I used, and the result of running it on that file. When I > open the edited file in Acrobat (11.0.10) the Properties window is still > empty. However, running the following code from the JS Console does print out > the correct output: > this.info.Keywords > Output: > NEW KEYWORDS > > I'm also attaching the same file after I've added keywords to in Acrobat, so > the internal structure could be compared with what PDFBox does. I didn't see > much of a difference, but maybe I missed something. > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4641) Keywords created using PDFBox are not visible in Acrobat
[ https://issues.apache.org/jira/browse/PDFBOX-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-4641: Attachment: Keywords test_edited.pdf Keywords test_added in Acrobat.pdf ApplyKeywords.java Keywords test.pdf > Keywords created using PDFBox are not visible in Acrobat > > > Key: PDFBOX-4641 > URL: https://issues.apache.org/jira/browse/PDFBOX-4641 > Project: PDFBox > Issue Type: Bug >Affects Versions: 2.0.16 > Environment: Windows 7, Eclipse 4.2.2 >Reporter: Gilad Denneboom >Priority: Minor > Attachments: ApplyKeywords.java, Keywords test.pdf, Keywords > test_added in Acrobat.pdf, Keywords test_edited.pdf > > > Setting new keywords using PDFBox 2.0.16 inserts the data into the file > (confirmed via the PDF Debugger and running a script in Acrobat), but the > keywords are not displayed in the Acrobat GUI. This might be a bug of Acrobat > itself, but it will be good to know why this is happening, and whether it can > be solved. > > Attached are a blank sample file created in Acrobat, with no metadata, a java > file with the code I used, and the result of running it on that file. When I > open the edited file in Acrobat (11.0.10) the Properties window is still > empty. However, running the following code from the JS Console does print out > the correct output: > this.info.Keywords > Output: > NEW KEYWORDS > > I'm also attaching the same file after I've added keywords to in Acrobat, so > the internal structure could be compared with what PDFBox does. I didn't see > much of a difference, but maybe I missed something. > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4641) Keywords created using PDFBox are not visible in Acrobat
Gilad Denneboom created PDFBOX-4641: --- Summary: Keywords created using PDFBox are not visible in Acrobat Key: PDFBOX-4641 URL: https://issues.apache.org/jira/browse/PDFBOX-4641 Project: PDFBox Issue Type: Bug Affects Versions: 2.0.16 Environment: Windows 7, Eclipse 4.2.2 Reporter: Gilad Denneboom Attachments: ApplyKeywords.java, Keywords test.pdf, Keywords test_added in Acrobat.pdf, Keywords test_edited.pdf Setting new keywords using PDFBox 2.0.16 inserts the data into the file (confirmed via the PDF Debugger and running a script in Acrobat), but the keywords are not displayed in the Acrobat GUI. This might be a bug of Acrobat itself, but it will be good to know why this is happening, and whether it can be solved. Attached are a blank sample file created in Acrobat, with no metadata, a java file with the code I used, and the result of running it on that file. When I open the edited file in Acrobat (11.0.10) the Properties window is still empty. However, running the following code from the JS Console does print out the correct output: this.info.Keywords Output: NEW KEYWORDS I'm also attaching the same file after I've added keywords to in Acrobat, so the internal structure could be compared with what PDFBox does. I didn't see much of a difference, but maybe I missed something. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2575) Add support for collections (portfolio)
[ https://issues.apache.org/jira/browse/PDFBOX-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712649#comment-16712649 ] Gilad Denneboom commented on PDFBOX-2575: - Thanks for the update, none the less! > Add support for collections (portfolio) > --- > > Key: PDFBOX-2575 > URL: https://issues.apache.org/jira/browse/PDFBOX-2575 > Project: PDFBox > Issue Type: Improvement > Components: PDModel >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler >Priority: Major > Labels: Collections, Portfolio > > We should add support for collections aka portfolios (see PDF specs 7.11.6 > Collections items and 12.3.5 Collections) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-2575) Add support for collections (portfolio)
[ https://issues.apache.org/jira/browse/PDFBOX-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712614#comment-16712614 ] Gilad Denneboom commented on PDFBOX-2575: - Any progress on this? It would be helpful if at least the relevant COSName items (like Collection and Folders) could be added, so we would at least have something to work with, until this is fully implemented... > Add support for collections (portfolio) > --- > > Key: PDFBOX-2575 > URL: https://issues.apache.org/jira/browse/PDFBOX-2575 > Project: PDFBox > Issue Type: Improvement > Components: PDModel >Affects Versions: 2.0.0 >Reporter: Andreas Lehmkühler >Priority: Major > Labels: Collections, Portfolio > > We should add support for collections aka portfolios (see PDF specs 7.11.6 > Collections items and 12.3.5 Collections) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375673#comment-16375673 ] Gilad Denneboom commented on PDFBOX-4117: - Will do, and thanks again! > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Fix For: 2.0.9, 3.0.0 PDFBox > > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375609#comment-16375609 ] Gilad Denneboom commented on PDFBOX-4117: - Everything looks good to me! > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375574#comment-16375574 ] Gilad Denneboom commented on PDFBOX-4117: - Can the same enum be used for PDActionRemoteGoTo and PDActionLaunch as well? The NewWindow key should work the same there. > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374717#comment-16374717 ] Gilad Denneboom commented on PDFBOX-4117: - Ah, I see. Sounds good to me! > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374703#comment-16374703 ] Gilad Denneboom commented on PDFBOX-4117: - I thought about that. The question is whether assigning null to it will have the same effect (in Acrobat) as removing it entirely. It can be tested, I'm sure. > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4117) Implement GoToE action-type
[
https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374226#comment-16374226
]
Gilad Denneboom edited comment on PDFBOX-4117 at 2/23/18 11:18 AM:
---
One thing that might be missing is the option to remove the NewWindow COK-key,
so that it defaults to the preference set in the application.
Here's the description in the ISO:
{noformat}
NewWindow – boolean
– (Optional) If true, the destination document should be opened in a new
window; if false, the destination document should replace the current document
in the same window. If this entry is absent, the conforming reader should act
according to its preference.{noformat}
was (Author: giladd):
One thing that might be missing is the open to remove the NewWindow COK-key, so
that it defaults to the preference set in the application.
Here's the description in the ISO:
{noformat}
NewWindow – boolean
– (Optional) If true, the destination document should be opened in a new
window; if false, the destination document should replace the current document
in the same window. If this entry is absent, the conforming reader should act
according to its preference.{noformat}
> Implement GoToE action-type
> ---
>
> Key: PDFBOX-4117
> URL: https://issues.apache.org/jira/browse/PDFBOX-4117
> Project: PDFBox
> Issue Type: New Feature
> Components: AcroForm
>Affects Versions: 1.8.13, 2.0.8
>Reporter: Gilad Denneboom
>Assignee: Tilman Hausherr
>Priority: Major
> Attachments: Sample GoToE Link.pdf
>
>
> One of the major Action Types is not implemented in any version of PDFBox,
> and I believe it should be. I'm referring to "Embedded Go-To Actions"
> (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an
> attached file. Currently, such "GoToE" actions are interpreted as "null" by
> PDFBox, which is not ideal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-4117) Implement GoToE action-type
[
https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374226#comment-16374226
]
Gilad Denneboom edited comment on PDFBOX-4117 at 2/23/18 11:18 AM:
---
One thing that might be missing is the option to remove the NewWindow COS-key,
so that it defaults to the preference set in the application.
Here's the description in the ISO:
{noformat}
NewWindow – boolean
– (Optional) If true, the destination document should be opened in a new
window; if false, the destination document should replace the current document
in the same window. If this entry is absent, the conforming reader should act
according to its preference.{noformat}
was (Author: giladd):
One thing that might be missing is the option to remove the NewWindow COK-key,
so that it defaults to the preference set in the application.
Here's the description in the ISO:
{noformat}
NewWindow – boolean
– (Optional) If true, the destination document should be opened in a new
window; if false, the destination document should replace the current document
in the same window. If this entry is absent, the conforming reader should act
according to its preference.{noformat}
> Implement GoToE action-type
> ---
>
> Key: PDFBOX-4117
> URL: https://issues.apache.org/jira/browse/PDFBOX-4117
> Project: PDFBox
> Issue Type: New Feature
> Components: AcroForm
>Affects Versions: 1.8.13, 2.0.8
>Reporter: Gilad Denneboom
>Assignee: Tilman Hausherr
>Priority: Major
> Attachments: Sample GoToE Link.pdf
>
>
> One of the major Action Types is not implemented in any version of PDFBox,
> and I believe it should be. I'm referring to "Embedded Go-To Actions"
> (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an
> attached file. Currently, such "GoToE" actions are interpreted as "null" by
> PDFBox, which is not ideal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[
https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374226#comment-16374226
]
Gilad Denneboom commented on PDFBOX-4117:
-
One thing that might be missing is the open to remove the NewWindow COK-key, so
that it defaults to the preference set in the application.
Here's the description in the ISO:
{noformat}
NewWindow – boolean
– (Optional) If true, the destination document should be opened in a new
window; if false, the destination document should replace the current document
in the same window. If this entry is absent, the conforming reader should act
according to its preference.{noformat}
> Implement GoToE action-type
> ---
>
> Key: PDFBOX-4117
> URL: https://issues.apache.org/jira/browse/PDFBOX-4117
> Project: PDFBox
> Issue Type: New Feature
> Components: AcroForm
>Affects Versions: 1.8.13, 2.0.8
>Reporter: Gilad Denneboom
>Assignee: Tilman Hausherr
>Priority: Major
> Attachments: Sample GoToE Link.pdf
>
>
> One of the major Action Types is not implemented in any version of PDFBox,
> and I believe it should be. I'm referring to "Embedded Go-To Actions"
> (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an
> attached file. Currently, such "GoToE" actions are interpreted as "null" by
> PDFBox, which is not ideal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374223#comment-16374223 ] Gilad Denneboom commented on PDFBOX-4117: - Seems to be working great! Any chance of implementing it in the older versions as well? > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-4117: Description: One of the major Action Types is not implemented in any version of PDFBox, and I believe it should be. I'm referring to "Embedded Go-To Actions" (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an attached file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, which is not ideal. (was: One of the major Action Types is not implemented in any version of PDFBox, and I believe it should be. I'm referring to "Embedded Go-To Actions" (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an attached file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, which is not ideal.) > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allows a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373539#comment-16373539 ] Gilad Denneboom commented on PDFBOX-4117: - Wow, thanks a lot for the quick turnaround, Tilman! Is it available in any current snapshot I can download and integrate into my project? > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Assignee: Tilman Hausherr >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-4117: Description: One of the major Action Types is not implemented in any version of PDFBox, and I believe it should be. I'm referring to "Embedded Go-To Actions" (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an attached file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, which is not ideal. (was: One of the major Action Types is not implemented in any version of PDFBox, and I believe it should be. I'm referring to "Embedded Go-To Actions" (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an attache file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, which is not ideal.) > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an > attached file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Updated] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-4117: Attachment: Sample GoToE Link.pdf > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an > attache file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-4117) Implement GoToE action-type
[ https://issues.apache.org/jira/browse/PDFBOX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370174#comment-16370174 ] Gilad Denneboom commented on PDFBOX-4117: - Added a sample file with a GoToE link on the first page, for testing purposes. > Implement GoToE action-type > --- > > Key: PDFBOX-4117 > URL: https://issues.apache.org/jira/browse/PDFBOX-4117 > Project: PDFBox > Issue Type: New Feature > Components: AcroForm >Affects Versions: 1.8.13, 2.0.8 >Reporter: Gilad Denneboom >Priority: Major > Attachments: Sample GoToE Link.pdf > > > One of the major Action Types is not implemented in any version of PDFBox, > and I believe it should be. I'm referring to "Embedded Go-To Actions" > (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an > attache file. Currently, such "GoToE" actions are interpreted as "null" by > PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-4117) Implement GoToE action-type
Gilad Denneboom created PDFBOX-4117: --- Summary: Implement GoToE action-type Key: PDFBOX-4117 URL: https://issues.apache.org/jira/browse/PDFBOX-4117 Project: PDFBox Issue Type: New Feature Components: AcroForm Affects Versions: 2.0.8, 1.8.13 Reporter: Gilad Denneboom One of the major Action Types is not implemented in any version of PDFBox, and I believe it should be. I'm referring to "Embedded Go-To Actions" (defined under 12.6.4.4 in PDF 32000-1:2008), which allow a link to open an attache file. Currently, such "GoToE" actions are interpreted as "null" by PDFBox, which is not ideal. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3996) Add option to automatically create just one file with Splitter
[ https://issues.apache.org/jira/browse/PDFBOX-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244625#comment-16244625 ] Gilad Denneboom commented on PDFBOX-3996: - I think it is... For example, the Split method of the String object uses 0 (or any negative value) for its limit parameter to mean that the output is not limited at all. There are various other examples. I'm not sure what your second comment is referring to. The documents are not created by me, but by the Splitter tool, when I call the split method. > Add option to automatically create just one file with Splitter > -- > > Key: PDFBOX-3996 > URL: https://issues.apache.org/jira/browse/PDFBOX-3996 > Project: PDFBox > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0.8 >Reporter: Gilad Denneboom >Priority: Minor > > When using Splitter, its default behavior is to extract each page in the > selected range as a separate PDDocument, but often one wants to extract that > range as a single document. In order to do that you currently need to use the > setSplitAtPage method and set it to the number of pages in your range, which > is a bit silly. It would be better if there was an option to do that > automatically, for example by setting the splitAtPage property to 0, or > something like that, and have it automatically calculate the number of pages > based on the startPage and endPage values. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3996) Add option to automatically create just one file with Splitter
[ https://issues.apache.org/jira/browse/PDFBOX-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244609#comment-16244609 ] Gilad Denneboom commented on PDFBOX-3996: - I can't use getNumberOfPages at that moment because the PDDocument object doesn't exist yet, but I guess passing a large number will work as well. I just thought it would be neater to use zero... > Add option to automatically create just one file with Splitter > -- > > Key: PDFBOX-3996 > URL: https://issues.apache.org/jira/browse/PDFBOX-3996 > Project: PDFBox > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0.8 >Reporter: Gilad Denneboom >Priority: Minor > > When using Splitter, its default behavior is to extract each page in the > selected range as a separate PDDocument, but often one wants to extract that > range as a single document. In order to do that you currently need to use the > setSplitAtPage method and set it to the number of pages in your range, which > is a bit silly. It would be better if there was an option to do that > automatically, for example by setting the splitAtPage property to 0, or > something like that, and have it automatically calculate the number of pages > based on the startPage and endPage values. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Commented] (PDFBOX-3996) Add option to automatically create just one file with Splitter
[ https://issues.apache.org/jira/browse/PDFBOX-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244427#comment-16244427 ] Gilad Denneboom commented on PDFBOX-3996: - I do, but it means I need to calculate the size of the file (in pages) each time, which shouldn't be necessary. I want to be able to specify setSplitAtPage(0) and have it figure it out by itself, so I don't need to worry about it each time. > Add option to automatically create just one file with Splitter > -- > > Key: PDFBOX-3996 > URL: https://issues.apache.org/jira/browse/PDFBOX-3996 > Project: PDFBox > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0.8 >Reporter: Gilad Denneboom >Priority: Minor > > When using Splitter, its default behavior is to extract each page in the > selected range as a separate PDDocument, but often one wants to extract that > range as a single document. In order to do that you currently need to use the > setSplitAtPage method and set it to the number of pages in your range, which > is a bit silly. It would be better if there was an option to do that > automatically, for example by setting the splitAtPage property to 0, or > something like that, and have it automatically calculate the number of pages > based on the startPage and endPage values. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Created] (PDFBOX-3996) Add option to automatically create just one file with Splitter
Gilad Denneboom created PDFBOX-3996: --- Summary: Add option to automatically create just one file with Splitter Key: PDFBOX-3996 URL: https://issues.apache.org/jira/browse/PDFBOX-3996 Project: PDFBox Issue Type: Improvement Components: Utilities Affects Versions: 2.0.8 Reporter: Gilad Denneboom Priority: Minor When using Splitter, its default behavior is to extract each page in the selected range as a separate PDDocument, but often one wants to extract that range as a single document. In order to do that you currently need to use the setSplitAtPage method and set it to the number of pages in your range, which is a bit silly. It would be better if there was an option to do that automatically, for example by setting the splitAtPage property to 0, or something like that, and have it automatically calculate the number of pages based on the startPage and endPage values. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
[jira] [Comment Edited] (PDFBOX-3461) Improve handling of control characters when setting AcroForm field values
[
https://issues.apache.org/jira/browse/PDFBOX-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418525#comment-15418525
]
Gilad Denneboom edited comment on PDFBOX-3461 at 8/12/16 8:43 AM:
--
Just a side-note: Acrobat itself replaces all instances of "\n" with "\r" when
applying the value using JS, and when entering a line-break manually by
pressing Enter it only inserts a "\r" character.
It does accept "\n" only as a line-break when applied via PDFBox, though.
Clarification: When applying "\r\n" using JS it becomes "\r". When applying
"\n" it becomes "\r" as well. So in some cases "\n" is removed, in others it is
replaced by Acrobat.
was (Author: giladd):
Just a side-note: Acrobat itself replaces all instances of "\n" with "\r" when
applying the value using JS, and when entering a line-break manually by
pressing Enter it only inserts a "\r" character.
It does accept "\n" only as a line-break when applied via PDFBox, though.
> Improve handling of control characters when setting AcroForm field values
> -
>
> Key: PDFBOX-3461
> URL: https://issues.apache.org/jira/browse/PDFBOX-3461
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
>Affects Versions: 2.0.1, 2.0.2, 2.0.3, 2.1.0
>Reporter: Maruan Sahyoun
> Labels: Appearance
>
> When filling AcroForm fields the text supplied to {{setValue}} might contain
> control characters such as {{\n}} {{\r}}, {{\t}} and others which leads to an
> {{ java.lang.IllegalArgumentException}} for most fonts as there is no glyph
> to represent these.
> We could enhance the processing of the string provided to provide proper
> replacements similar to how Adobe Acrobat handles that.
--
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-3461) Improve handling of control characters when setting AcroForm field values
[
https://issues.apache.org/jira/browse/PDFBOX-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15418525#comment-15418525
]
Gilad Denneboom commented on PDFBOX-3461:
-
Just a side-note: Acrobat itself replaces all instances of "\n" with "\r" when
applying the value using JS, and when entering a line-break manually by
pressing Enter it only inserts a "\r" character.
It does accept "\n" only as a line-break when applied via PDFBox, though.
> Improve handling of control characters when setting AcroForm field values
> -
>
> Key: PDFBOX-3461
> URL: https://issues.apache.org/jira/browse/PDFBOX-3461
> Project: PDFBox
> Issue Type: Improvement
> Components: AcroForm
>Affects Versions: 2.0.1, 2.0.2, 2.0.3, 2.1.0
>Reporter: Maruan Sahyoun
> Labels: Appearance
>
> When filling AcroForm fields the text supplied to {{setValue}} might contain
> control characters such as {{\n}} {{\r}}, {{\t}} and others which leads to an
> {{ java.lang.IllegalArgumentException}} for most fonts as there is no glyph
> to represent these.
> We could enhance the processing of the string provided to provide proper
> replacements similar to how Adobe Acrobat handles that.
--
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-3138) PDTextField doesn't accept any Hebrew characters as new value
[
https://issues.apache.org/jira/browse/PDFBOX-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034524#comment-15034524
]
Gilad Denneboom commented on PDFBOX-3138:
-
Embedding the font: Should I do that with PDFBox or via Acrobat? And how?
Setting NeedAppearances to true before applying the values: That worked!
Of course, the file always opens as "dirty", but that's a minor issue. Thanks
for that!
It would be nice if this issue could be solved natively within PDFBox, though.
> PDTextField doesn't accept any Hebrew characters as new value
> -
>
> Key: PDFBOX-3138
> URL: https://issues.apache.org/jira/browse/PDFBOX-3138
> Project: PDFBox
> Issue Type: Bug
> Components: AcroForm, FontBox
>Affects Versions: 2.0.0
> Environment: Eclipse 4.2.2, Windows 7 Pro, JRE 1.8.0_05
>Reporter: Gilad Denneboom
> Fix For: 2.1.0
>
> Attachments: SetHebrewFieldValueTest.java, Test-3-filled.pdf,
> Test.pdf, Test.txt
>
>
> Trying to set a UTF-8 encoded Hebrew string as the value of a PDTextField
> fails with the following exception:
> {code}
> Exception in thread "main" java.lang.IllegalArgumentException: No glyph for
> U+05D7 in font AdobeHebrew-Regular
> at
> org.apache.pdfbox.pdmodel.font.PDType1CFont.encode(PDType1CFont.java:300)
> at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:283)
> at
> org.apache.pdfbox.pdmodel.PDPageContentStream.showText(PDPageContentStream.java:341)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:213)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:373)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:237)
> at
> org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:144)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:263)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:221)
> at
> org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218)
> at SetHebrewFieldValueTest.main(SetHebrewFieldValueTest.java:22)
> {code}
> I've tried using multiple fonts for the field, all of which can handle Hebrew
> characters just fine, and got the same results in all of them.
> See attached files for a demonstration of the issue.
--
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-3138) PDTextField doesn't accept any Hebrew characters as new value
[ https://issues.apache.org/jira/browse/PDFBOX-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-3138: Attachment: Test.txt Test.pdf SetHebrewFieldValueTest.java These files demonstrate the issue reported. > PDTextField doesn't accept any Hebrew characters as new value > - > > Key: PDFBOX-3138 > URL: https://issues.apache.org/jira/browse/PDFBOX-3138 > Project: PDFBox > Issue Type: Bug > Components: AcroForm, FontBox >Affects Versions: 2.0.0 > Environment: Eclipse 4.2.2, Windows 7 Pro, JRE 1.8.0_05 >Reporter: Gilad Denneboom >Priority: Minor > Attachments: SetHebrewFieldValueTest.java, Test.pdf, Test.txt > > > Trying to set a UTF-8 encoded Hebrew string as the value of a PDTextField > fails with the following exception: > Exception in thread "main" java.lang.IllegalArgumentException: No glyph for > U+05D7 in font AdobeHebrew-Regular > at > org.apache.pdfbox.pdmodel.font.PDType1CFont.encode(PDType1CFont.java:300) > at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:283) > at > org.apache.pdfbox.pdmodel.PDPageContentStream.showText(PDPageContentStream.java:341) > at > org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:213) > at > org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:373) > at > org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:237) > at > org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:144) > at > org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:263) > at > org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:221) > at > org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218) > at SetHebrewFieldValueTest.main(SetHebrewFieldValueTest.java:22) > I've tried using multiple fonts for the field, all of which can handle Hebrew > characters just fine, and got the same results in all of them. > See attached files for a demonstration of the issue. -- 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-3138) PDTextField doesn't accept any Hebrew characters as new value
Gilad Denneboom created PDFBOX-3138: --- Summary: PDTextField doesn't accept any Hebrew characters as new value Key: PDFBOX-3138 URL: https://issues.apache.org/jira/browse/PDFBOX-3138 Project: PDFBox Issue Type: Bug Components: AcroForm, FontBox Affects Versions: 2.0.0 Environment: Eclipse 4.2.2, Windows 7 Pro, JRE 1.8.0_05 Reporter: Gilad Denneboom Priority: Minor Trying to set a UTF-8 encoded Hebrew string as the value of a PDTextField fails with the following exception: Exception in thread "main" java.lang.IllegalArgumentException: No glyph for U+05D7 in font AdobeHebrew-Regular at org.apache.pdfbox.pdmodel.font.PDType1CFont.encode(PDType1CFont.java:300) at org.apache.pdfbox.pdmodel.font.PDFont.encode(PDFont.java:283) at org.apache.pdfbox.pdmodel.PDPageContentStream.showText(PDPageContentStream.java:341) at org.apache.pdfbox.pdmodel.interactive.form.PlainTextFormatter.format(PlainTextFormatter.java:213) at org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.insertGeneratedAppearance(AppearanceGeneratorHelper.java:373) at org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceContent(AppearanceGeneratorHelper.java:237) at org.apache.pdfbox.pdmodel.interactive.form.AppearanceGeneratorHelper.setAppearanceValue(AppearanceGeneratorHelper.java:144) at org.apache.pdfbox.pdmodel.interactive.form.PDTextField.constructAppearances(PDTextField.java:263) at org.apache.pdfbox.pdmodel.interactive.form.PDTerminalField.applyChange(PDTerminalField.java:221) at org.apache.pdfbox.pdmodel.interactive.form.PDTextField.setValue(PDTextField.java:218) at SetHebrewFieldValueTest.main(SetHebrewFieldValueTest.java:22) I've tried using multiple fonts for the field, all of which can handle Hebrew characters just fine, and got the same results in all of them. See attached files for a demonstration of the issue. -- 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-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650296#comment-14650296 ] Gilad Denneboom commented on PDFBOX-772: Can you post the code you used to change the XMP title property? Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Attachments: pdf_open_parameters.pdf, pdf_open_parameters_edited.pdf, pdf_open_parameters_edited_edited.pdf, pdf_open_parameters_edited_edited2.pdf Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650298#comment-14650298 ] Gilad Denneboom commented on PDFBOX-772: So shouldn't these two properties be tied together? What's the point of the various set methods under PDDocumentInformation if updating them is not reflecting in the application? What does the PDF ISO say about this duplicity (if at all)? Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Attachments: pdf_open_parameters.pdf, pdf_open_parameters_edited.pdf, pdf_open_parameters_edited_edited.pdf, pdf_open_parameters_edited_edited2.pdf Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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] [Reopened] (PDFBOX-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom reopened PDFBOX-772: Problem still not solved in 1.8.10... Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649865#comment-14649865 ] Gilad Denneboom commented on PDFBOX-772: Still not solved in 1.8.10... Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649912#comment-14649912 ] Gilad Denneboom commented on PDFBOX-772: The code: PDDocument doc = PDDocument.load(C:\\Temp\\pdf_open_parameters.pdf); doc.getDocumentInformation().setTitle(TEST TITLE); doc.save(C:\\Temp\\pdf_open_parameters_edited.pdf); doc.close(); Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Attachments: pdf_open_parameters.pdf, pdf_open_parameters_edited.pdf Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-772: --- Attachment: pdf_open_parameters_edited.pdf pdf_open_parameters.pdf Before and after files... Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.1 Attachments: pdf_open_parameters.pdf, pdf_open_parameters_edited.pdf Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- 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-2745) PDPageXYZDestination's zoom property can't be set lower than 100%
[ https://issues.apache.org/jira/browse/PDFBOX-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-2745: Description: The zoom property of PDPageXYZDestination is currently an int, which means it can't be anything that isn't a multiple of 100%, as the zoom level is measured between 0 (=0%) and 1 (=100%), or higher, not between 0 and 100. Therefore it should be changed to a float. was: The zoom property of PDPageXYZDestination is currently an int, which means it can't be anything that isn't a multiple of 100%, as the zoom level is measured between 0 (=0%) and 1 (=100%), or higher, not between 0 and 100. Therefore should be changed to a float. PDPageXYZDestination's zoom property can't be set lower than 100% - Key: PDFBOX-2745 URL: https://issues.apache.org/jira/browse/PDFBOX-2745 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.9 Environment: Windows 7, JRE 1.8.0, Eclipse Reporter: Gilad Denneboom Priority: Minor The zoom property of PDPageXYZDestination is currently an int, which means it can't be anything that isn't a multiple of 100%, as the zoom level is measured between 0 (=0%) and 1 (=100%), or higher, not between 0 and 100. Therefore it should be changed to a float. -- 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-2745) PDPageXYZDestination's zoom property can't be set lower than 100%
Gilad Denneboom created PDFBOX-2745: --- Summary: PDPageXYZDestination's zoom property can't be set lower than 100% Key: PDFBOX-2745 URL: https://issues.apache.org/jira/browse/PDFBOX-2745 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.9 Environment: Windows 7, JRE 1.8.0, Eclipse Reporter: Gilad Denneboom Priority: Minor The zoom property of PDPageXYZDestination is currently an int, which means it can't be anything that isn't a multiple of 100%, as the zoom level is measured between 0 (=0%) and 1 (=100%), or higher, not between 0 and 100. Therefore should be changed to a float. -- 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-2631) Single radio-button group has no children
[ https://issues.apache.org/jira/browse/PDFBOX-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296760#comment-14296760 ] Gilad Denneboom commented on PDFBOX-2631: - If you consider this to be a correct implementation, then yes, it can be closed. Single radio-button group has no children - Key: PDFBOX-2631 URL: https://issues.apache.org/jira/browse/PDFBOX-2631 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 1.8.8 Environment: Windows 7, Eclipse, JRE 1.8.0_25 Reporter: Gilad Denneboom Assignee: Maruan Sahyoun Priority: Minor Attachments: test2.pdf (Continuation of https://issues.apache.org/jira/browse/PDFBOX-2617) A group of radio-buttons is an object of the PDRadioCollection class and each child of that group is an PDCheckbox object. However, if the group only contains one widget the getKids method of the PDRadioCollection object returns null. There should be at least one child for any such group. -- 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-2617) Group of Button fields treated as a Radio Button group
[
https://issues.apache.org/jira/browse/PDFBOX-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290515#comment-14290515
]
Gilad Denneboom commented on PDFBOX-2617:
-
[~msahyoun] Thanks for taking care of it. I tested my code using the latest
1.8.9 snapshot (pdfbox-1.8.9-20150124.080542-47.jar) and it seems to have
solved this issue.
However, I added some more fields and played around with it a bit more, and
might have come against another (minor) issue.
When I create a group of radio-buttons the group itself is a PDRadioCollection
object and each child is a PDCheckbox object, which makes sense. But if the
group only contains one child (for some reason), its Kids property is null.
Should there not be 1 PDCheckbox child in this case? If you want I can upload a
sample file that demonstrates it.
Group of Button fields treated as a Radio Button group
--
Key: PDFBOX-2617
URL: https://issues.apache.org/jira/browse/PDFBOX-2617
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8, 2.0.0
Environment: Windows 7, Eclipse, JRE 1.8.0_25
Reporter: Gilad Denneboom
Assignee: Maruan Sahyoun
Priority: Minor
Fix For: 2.0.0
Attachments: test.pdf
When creating a group of identical button fields PDFBox reads them as a group
of radio-button fields, with each widget as a check-box, which is incorrect.
The main field has the class PDRadioCollection and each kid is a PDCheckbox.
Run the following code on the attached file:
PDDocument doc = PDDocument.load( new File(test.pdf) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for (PDField f: fields) {
System.out.println(Name: + f.getFullyQualifiedName());
System.out.println(Type: + f.getFieldType());
System.out.println(Class: + f.getClass());
ListCOSObjectable kids = f.getKids();
if (kids!=null) {
for (COSObjectable c : kids) {
System.out.println(Kid Class: + c.getClass());
}
}
}
The results are:
Name:Test
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PDFBOX-2631) Single radio-button group has no children
Gilad Denneboom created PDFBOX-2631: --- Summary: Single radio-button group has no children Key: PDFBOX-2631 URL: https://issues.apache.org/jira/browse/PDFBOX-2631 Project: PDFBox Issue Type: Bug Components: AcroForm Affects Versions: 1.8.8 Environment: Windows 7, Eclipse, JRE 1.8.0_25 Reporter: Gilad Denneboom Priority: Minor (Continuation of https://issues.apache.org/jira/browse/PDFBOX-2617) A group of radio-buttons is an object of the PDRadioCollection class and each child of that group is an PDCheckbox object. However, if the group only contains one widget the getKids method of the PDRadioCollection object returns null. There should be at least one child for any such group. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PDFBOX-2631) Single radio-button group has no children
[
https://issues.apache.org/jira/browse/PDFBOX-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Denneboom updated PDFBOX-2631:
Attachment: test2.pdf
Sample file demonstrating the issue (compare Group1 and Group2).
Code:
PDDocument doc = PDDocument.load( new File(test2.pdf) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for (PDField f: fields) {
System.out.println(Name: + f.getFullyQualifiedName());
System.out.println(Type: + f.getFieldType());
System.out.println(Class: + f.getClass());
ListCOSObjectable kids = f.getKids();
if (kids!=null) {
for (COSObjectable c : kids)
{ System.out.println(Kid Class: + c.getClass()); }
}
}
Output:
Name:Test
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDPushButton
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
-
Name:Group1
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
-
Name:Group2
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
-
Name:Check Box2
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
-
Name:Check Box3
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
-
Name:Text3
Type:Tx
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDTextbox
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
Kid Class: class
org.apache.pdfbox.pdmodel.interactive.annotation.PDAnnotationWidget
-
Single radio-button group has no children
-
Key: PDFBOX-2631
URL: https://issues.apache.org/jira/browse/PDFBOX-2631
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8
Environment: Windows 7, Eclipse, JRE 1.8.0_25
Reporter: Gilad Denneboom
Priority: Minor
Attachments: test2.pdf
(Continuation of https://issues.apache.org/jira/browse/PDFBOX-2617)
A group of radio-buttons is an object of the PDRadioCollection class and each
child of that group is an PDCheckbox object.
However, if the group only contains one widget the getKids method of the
PDRadioCollection object returns null.
There should be at least one child for any such group.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2617) Group of Button fields treated as a Radio Button group
[
https://issues.apache.org/jira/browse/PDFBOX-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14290639#comment-14290639
]
Gilad Denneboom commented on PDFBOX-2617:
-
OK, I created https://issues.apache.org/jira/browse/PDFBOX-2631
Group of Button fields treated as a Radio Button group
--
Key: PDFBOX-2617
URL: https://issues.apache.org/jira/browse/PDFBOX-2617
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8, 2.0.0
Environment: Windows 7, Eclipse, JRE 1.8.0_25
Reporter: Gilad Denneboom
Assignee: Maruan Sahyoun
Priority: Minor
Fix For: 2.0.0
Attachments: test.pdf
When creating a group of identical button fields PDFBox reads them as a group
of radio-button fields, with each widget as a check-box, which is incorrect.
The main field has the class PDRadioCollection and each kid is a PDCheckbox.
Run the following code on the attached file:
PDDocument doc = PDDocument.load( new File(test.pdf) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for (PDField f: fields) {
System.out.println(Name: + f.getFullyQualifiedName());
System.out.println(Type: + f.getFieldType());
System.out.println(Class: + f.getClass());
ListCOSObjectable kids = f.getKids();
if (kids!=null) {
for (COSObjectable c : kids) {
System.out.println(Kid Class: + c.getClass());
}
}
}
The results are:
Name:Test
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2617) Group of Button fields treated as a Radio Button group
[
https://issues.apache.org/jira/browse/PDFBOX-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Denneboom updated PDFBOX-2617:
Attachment: test.pdf
Sample file
Group of Button fields treated as a Radio Button group
--
Key: PDFBOX-2617
URL: https://issues.apache.org/jira/browse/PDFBOX-2617
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8
Environment: Windows 7, Eclipse, JRE 1.8.0_25
Reporter: Gilad Denneboom
Priority: Minor
Attachments: test.pdf
When creating a group of identical button fields PDFBox reads them as a group
of radio-button fields, with each widget as a check-box, which is incorrect.
The main field has the class PDRadioCollection and each kid is a PDCheckbox.
Run the following code on the attached file:
PDDocument doc = PDDocument.load( new File(test.pdf) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for (PDField f: fields) {
System.out.println(Name: + f.getFullyQualifiedName());
System.out.println(Type: + f.getFieldType());
System.out.println(Class: + f.getClass());
ListCOSObjectable kids = f.getKids();
if (kids!=null) {
for (COSObjectable c : kids) {
System.out.println(Kid Class: + c.getClass());
}
}
}
The results are:
Name:Test
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PDFBOX-2617) Group of Button fields treated as a Radio Button group
Gilad Denneboom created PDFBOX-2617:
---
Summary: Group of Button fields treated as a Radio Button group
Key: PDFBOX-2617
URL: https://issues.apache.org/jira/browse/PDFBOX-2617
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8
Environment: Windows 7, Eclipse, JRE 1.8.0_25
Reporter: Gilad Denneboom
Priority: Minor
Attachments: test.pdf
When creating a group of identical button fields PDFBox reads them as a group
of radio-button fields, with each widget as a check-box, which is incorrect.
The main field has the class PDRadioCollection and each kid is a PDCheckbox.
Run the following code on the attached file:
PDDocument doc = PDDocument.load( new File(test.pdf) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for (PDField f: fields) {
System.out.println(Name: + f.getFullyQualifiedName());
System.out.println(Type: + f.getFieldType());
System.out.println(Class: + f.getClass());
ListCOSObjectable kids = f.getKids();
if (kids!=null) {
for (COSObjectable c : kids) {
System.out.println(Kid Class: + c.getClass());
}
}
}
The results are:
Name:Test
Type:Btn
Class:class org.apache.pdfbox.pdmodel.interactive.form.PDRadioCollection
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
Kid Class: class org.apache.pdfbox.pdmodel.interactive.form.PDCheckbox
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PDFBOX-2582) Form fields missing entirely or incorrect in PDField list
Gilad Denneboom created PDFBOX-2582:
---
Summary: Form fields missing entirely or incorrect in PDField list
Key: PDFBOX-2582
URL: https://issues.apache.org/jira/browse/PDFBOX-2582
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8, 2.0.0
Environment: Windows 7, JRE 1.8.0_25
Reporter: Gilad Denneboom
Running this code on the attached file results in incorrect and missing results:
PDDocument doc = PDDocument.load( new File(filePath) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for ( int i=0; ifields.size(); i++ ) {
System.out.println(Name: + fields.get(i).getFullyQualifiedName());
}
The output is:
Name:2
Name:Step 2
Name:Image 2
Name:Button 2
Name:Button 5
Name:Image 5
The file was generated in InDesign and the form fields created there, so they
should be recognizable. You can see that the part of the form fields after the
dot was removed and the two fields on page 4 are missing entirely.
I tested it using 1.8.8 and a very recent 2.0.0 snapshot, both yielded the same
results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PDFBOX-2582) Form fields missing entirely or incorrect in PDField list
[
https://issues.apache.org/jira/browse/PDFBOX-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Denneboom updated PDFBOX-2582:
Attachment: Rollover Mock 5.pdf
The file in question
Form fields missing entirely or incorrect in PDField list
-
Key: PDFBOX-2582
URL: https://issues.apache.org/jira/browse/PDFBOX-2582
Project: PDFBox
Issue Type: Bug
Components: AcroForm
Affects Versions: 1.8.8, 2.0.0
Environment: Windows 7, JRE 1.8.0_25
Reporter: Gilad Denneboom
Labels: acroform
Attachments: Rollover Mock 5.pdf
Running this code on the attached file results in incorrect and missing
results:
PDDocument doc = PDDocument.load( new File(filePath) );
PDAcroForm form = doc.getDocumentCatalog().getAcroForm();
ListPDField fields = form.getFields();
for ( int i=0; ifields.size(); i++ ) {
System.out.println(Name: + fields.get(i).getFullyQualifiedName());
}
The output is:
Name:2
Name:Step 2
Name:Image 2
Name:Button 2
Name:Button 5
Name:Image 5
The file was generated in InDesign and the form fields created there, so they
should be recognizable. You can see that the part of the form fields after
the dot was removed and the two fields on page 4 are missing entirely.
I tested it using 1.8.8 and a very recent 2.0.0 snapshot, both yielded the
same results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PDFBOX-2148) Handle the Fully Qualified Name of duplicate fields better
[ https://issues.apache.org/jira/browse/PDFBOX-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14168072#comment-14168072 ] Gilad Denneboom commented on PDFBOX-2148: - Not sure, John. Can you link to it? Handle the Fully Qualified Name of duplicate fields better -- Key: PDFBOX-2148 URL: https://issues.apache.org/jira/browse/PDFBOX-2148 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 1.8.5 Reporter: Gilad Denneboom Priority: Minor Fix For: 2.0.0 Attachments: field name test.java, field name test.pdf When there are multiple copies with the same field name, the getFullyQualifiedName for each kid in the list of PDField objects returns the name of the parent, followed by .null. So if the parent field is called Button2 and it has 4 instances the result of printing out all the names will be: Button2.null Button2.null Button2.null Button2.null Acrobat names these widgets using consecutive numbers, like so: Button2.0 Button2.1 Button2.2 Button2.3 I had a look at the PDF ISO documentation regarding Field Names (12.7.3.2, p. 434) and this convention is not mentioned there, but it might be a good idea to use it anyway, no? I'm attaching a sample code snippet and a PDF that show this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PDFBOX-2148) Handle the Fully Qualified Name of duplicate fields better
Gilad Denneboom created PDFBOX-2148: --- Summary: Handle the Fully Qualified Name of duplicate fields better Key: PDFBOX-2148 URL: https://issues.apache.org/jira/browse/PDFBOX-2148 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 1.8.5 Reporter: Gilad Denneboom Priority: Minor Attachments: field name test.java, field name test.pdf When there are multiple copies with the same field name, the getFullyQualifiedName for each kid in the list of PDField objects returns the name of the parent, followed by .null. So if the parent field is called Button2 and it has 4 instances the result of printing out all the names will be: Button2.null Button2.null Button2.null Button2.null Acrobat names these widgets using consecutive numbers, like so: Button2.0 Button2.1 Button2.2 Button2.3 I had a look at the PDF ISO documentation regarding Field Names (12.7.3.2, p. 434) and this convention is not mentioned there, but it might be a good idea to use it anyway, no? I'm attaching a sample code snippet and a PDF that show this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PDFBOX-2148) Handle the Fully Qualified Name of duplicate fields better
[ https://issues.apache.org/jira/browse/PDFBOX-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-2148: Attachment: field name test.pdf field name test.java Handle the Fully Qualified Name of duplicate fields better -- Key: PDFBOX-2148 URL: https://issues.apache.org/jira/browse/PDFBOX-2148 Project: PDFBox Issue Type: Improvement Components: PDModel Affects Versions: 1.8.5 Reporter: Gilad Denneboom Priority: Minor Attachments: field name test.java, field name test.pdf When there are multiple copies with the same field name, the getFullyQualifiedName for each kid in the list of PDField objects returns the name of the parent, followed by .null. So if the parent field is called Button2 and it has 4 instances the result of printing out all the names will be: Button2.null Button2.null Button2.null Button2.null Acrobat names these widgets using consecutive numbers, like so: Button2.0 Button2.1 Button2.2 Button2.3 I had a look at the PDF ISO documentation regarding Field Names (12.7.3.2, p. 434) and this convention is not mentioned there, but it might be a good idea to use it anyway, no? I'm attaching a sample code snippet and a PDF that show this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PDFBOX-1967) findMediaBox returns wrong value
[ https://issues.apache.org/jira/browse/PDFBOX-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13951874#comment-13951874 ] Gilad Denneboom commented on PDFBOX-1967: - Odd... I can't seem to reproduce it now. I guess you can close this issue for the time-being. If I encounter it again I'll report here. findMediaBox returns wrong value Key: PDFBOX-1967 URL: https://issues.apache.org/jira/browse/PDFBOX-1967 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.4 Environment: Windows, Eclipse Reporter: Gilad Denneboom Attachments: 794.pdf The PDPage method findMediaBox returns the wrong value, starting with version 1.8.4. The result for the attached page is: [0.0,0.0,612.0,792.0] v1.8.3 returns [0.0,0.0,595.276,765.354], and these are also the values reported by Acrobat. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PDFBOX-1967) findMediaBox returns wrong value
Gilad Denneboom created PDFBOX-1967: --- Summary: findMediaBox returns wrong value Key: PDFBOX-1967 URL: https://issues.apache.org/jira/browse/PDFBOX-1967 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.8.4 Environment: Windows, Eclipse Reporter: Gilad Denneboom The PDPage method findMediaBox returns the wrong value, starting with version 1.8.4. The result for the attached page is: [0.0,0.0,612.0,792.0] v1.8.3 returns [0.0,0.0,595.276,765.354], and these are also the values reported by Acrobat. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PDFBOX-1782) Add getMaxLength() and setMaxLength() methods to PDTextbox
Gilad Denneboom created PDFBOX-1782: --- Summary: Add getMaxLength() and setMaxLength() methods to PDTextbox Key: PDFBOX-1782 URL: https://issues.apache.org/jira/browse/PDFBOX-1782 Project: PDFBox Issue Type: Improvement Components: PDModel.AcroForm Affects Versions: 1.8.2 Reporter: Gilad Denneboom Priority: Trivial Basically, this would be a handy way of getting or setting the (int) value of the MaxLen property, which represents the maximum number of characters a text field can contain (documented in table 229 of PDF 32000-1:2008). Also, it would be nice if MaxLen could be added as a constant to COSName to facilitate this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PDFBOX-1106) PDFMergerUtility corrupts file attachments
PDFMergerUtility corrupts file attachments
--
Key: PDFBOX-1106
URL: https://issues.apache.org/jira/browse/PDFBOX-1106
Project: PDFBox
Issue Type: Bug
Components: Utilities
Affects Versions: 1.6.0
Environment: Windows 7, Acrobat Pro 9.4.4, Eclipse Helios SR2
Reporter: Gilad Denneboom
Priority: Minor
When combining files that contain (PDF) file attachments, the attachments carry
over, but are corrupted in the merged file.
Code used:
PDFMergerUtility merger = new PDFMergerUtility();
merger.addSource(c:/gilad/testing/in/1.pdf);
merger.addSource(c:/gilad/testing/in/2.pdf);
merger.setDestinationFileName(c:/gilad/testing/in/merged.pdf);
try {
merger.mergeDocuments();
} catch (Exception e) {
e.printStackTrace();
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1106) PDFMergerUtility corrupts file attachments
[
https://issues.apache.org/jira/browse/PDFBOX-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Denneboom updated PDFBOX-1106:
Attachment: merged.pdf
2.pdf
1.pdf
Attached the file used in the above code, including the result.
File 2 contains the original attachments.
PDFMergerUtility corrupts file attachments
--
Key: PDFBOX-1106
URL: https://issues.apache.org/jira/browse/PDFBOX-1106
Project: PDFBox
Issue Type: Bug
Components: Utilities
Affects Versions: 1.6.0
Environment: Windows 7, Acrobat Pro 9.4.4, Eclipse Helios SR2
Reporter: Gilad Denneboom
Priority: Minor
Labels: PDFMergerUtility, attachments
Attachments: 1.pdf, 2.pdf, merged.pdf
When combining files that contain (PDF) file attachments, the attachments
carry over, but are corrupted in the merged file.
Code used:
PDFMergerUtility merger = new PDFMergerUtility();
merger.addSource(c:/gilad/testing/in/1.pdf);
merger.addSource(c:/gilad/testing/in/2.pdf);
merger.setDestinationFileName(c:/gilad/testing/in/merged.pdf);
try {
merger.mergeDocuments();
} catch (Exception e) {
e.printStackTrace();
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1066) There is no functionlaity of reading the text line by line with its input field
[ https://issues.apache.org/jira/browse/PDFBOX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067012#comment-13067012 ] Gilad Denneboom commented on PDFBOX-1066: - This is not a bug. There is no functionlaity of reading the text line by line with its input field --- Key: PDFBOX-1066 URL: https://issues.apache.org/jira/browse/PDFBOX-1066 Project: PDFBox Issue Type: Bug Components: Text extraction Affects Versions: 0.7.3 Environment: Windows Reporter: Nishant Labels: patch Original Estimate: 168h Remaining Estimate: 168h I am trying to read the PDF texts along with its input type like textfield/checkboxes. What i found is TextStripper is pasing the whole document and retuning the string in getText(). And using Acroform.getfields i am able ot get all fields. But I have perticuler requierment of reading the texts and its input type. Do we have any class/method which can resolve this issue. Its very urgent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1064) Can't set destination of a PDOutlineItem to null
Can't set destination of a PDOutlineItem to null Key: PDFBOX-1064 URL: https://issues.apache.org/jira/browse/PDFBOX-1064 Project: PDFBox Issue Type: Bug Components: PDModel Environment: Windows 7, Eclipse Helios SR2 Reporter: Gilad Denneboom Priority: Minor Because of the overloaded setDestination() method of PDOutlineItem it's not possible to set it to null and therefore remove the Go To Named Destination action, like it is possible with PDOutlineItem.setAction(), for example. Sample code: PDOutlineItem bookmark = doc.getDocumentCatalog().getDocumentOutline().getFirstChild(); bookmark.setDestination(null); // DOES NOT COMPILE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1060) convertToImage includes ghost annotation outlines
[
https://issues.apache.org/jira/browse/PDFBOX-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Denneboom updated PDFBOX-1060:
Attachment: PAGE2.png
PAGE1.png
PAGE0.png
3 Pages from batch_sequences.pdf
The PDF and generated PNG files. The problem can be seen in the last one (page
3).
convertToImage includes ghost annotation outlines
---
Key: PDFBOX-1060
URL: https://issues.apache.org/jira/browse/PDFBOX-1060
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.6.0
Environment: Windows 7, Eclipse Helios SR2
Reporter: Gilad Denneboom
Labels: convertToImage
Attachments: 3 Pages from batch_sequences.pdf, PAGE0.png, PAGE1.png,
PAGE2.png
When using PDPage.convertToImage() to export PNG files of pages with
annotations on them, ghost outlines of sometimes appear on the generated
image. The outlines do not correspond to the location of the annotations. See
the attached files.
Code used:
String inputFilePath = C:/Gilad/input/3 Pages from
batch_sequences.pdf;
PDDocument doc = PDDocument.load(inputFilePath);
for (int p=0; pdoc.getNumberOfPages(); p++) {
PDPage page = (PDPage)
doc.getDocumentCatalog().getAllPages().get(p);
BufferedImage bImg = page.convertToImage();
String imagePath = FilenameUtils.getFullPath(inputFilePath)
+ PAGE+ Integer.toString(p) + .png;
File yourImageFile = new File(imagePath);
ImageIO.write(bImg,png,yourImageFile);
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1024) Some PDBorderStyleDictionary options not honored
[ https://issues.apache.org/jira/browse/PDFBOX-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045822#comment-13045822 ] Gilad Denneboom commented on PDFBOX-1024: - PS - any reason why the result file is 3 times bigger compared to the source? Some PDBorderStyleDictionary options not honored Key: PDFBOX-1024 URL: https://issues.apache.org/jira/browse/PDFBOX-1024 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.5.0 Environment: Windows 7, Acrobat 9 Pro, Reader X Reporter: Gilad Denneboom Priority: Minor Labels: border, links Attachments: AddLinks.java, batch_sequences.pdf, result.pdf I'm creating links and using PDBorderStyleDictionary to set the border style, but have noticed that some options are not honored when opening the files. Here are my findings: PDBorderStyleDictionary.STYLE_UNDERLINE = works correctly. PDBorderStyleDictionary.STYLE_SOLID = works correctly. PDBorderStyleDictionary.STYLE_BEVELED = identical to using SOLID. PDBorderStyleDictionary.STYLE_INSET = identical to using SOLID. PDBorderStyleDictionary.STYLE_DASHED = identical to using SOLID in appearance, link type under Properties in Acrobat is Custom. I've noticed that when I manually create a link in Acrobat the only options are Solid, Dashed and Underline, so maybe the PDF specs have changed and need to be updated in PDFBox as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PDFBOX-1024) Some PDBorderStyleDictionary options not honored
[ https://issues.apache.org/jira/browse/PDFBOX-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045861#comment-13045861 ] Gilad Denneboom commented on PDFBOX-1024: - I used Acrobat 9.4.4 Pro and Reader X 10.0.1, with the same results in both. So do you think this is a bug in Adobe's implementation of the dictionaries? Some PDBorderStyleDictionary options not honored Key: PDFBOX-1024 URL: https://issues.apache.org/jira/browse/PDFBOX-1024 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.5.0 Environment: Windows 7, Acrobat 9 Pro, Reader X Reporter: Gilad Denneboom Priority: Minor Labels: border, links Attachments: AddLinks.java, batch_sequences.pdf, result.pdf I'm creating links and using PDBorderStyleDictionary to set the border style, but have noticed that some options are not honored when opening the files. Here are my findings: PDBorderStyleDictionary.STYLE_UNDERLINE = works correctly. PDBorderStyleDictionary.STYLE_SOLID = works correctly. PDBorderStyleDictionary.STYLE_BEVELED = identical to using SOLID. PDBorderStyleDictionary.STYLE_INSET = identical to using SOLID. PDBorderStyleDictionary.STYLE_DASHED = identical to using SOLID in appearance, link type under Properties in Acrobat is Custom. I've noticed that when I manually create a link in Acrobat the only options are Solid, Dashed and Underline, so maybe the PDF specs have changed and need to be updated in PDFBox as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1031) PDFMergerUtility - form fields disappear
PDFMergerUtility - form fields disappear Key: PDFBOX-1031 URL: https://issues.apache.org/jira/browse/PDFBOX-1031 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.5.0 Environment: Windows 7, Acrobat Pro 9, Eclipse Helios SR2 Reporter: Gilad Denneboom I merge 2 PDF files with fields in them, but the result PDF contains no fields. I believe this is related to https://issues.apache.org/jira/browse/PDFBOX-930, which remains unsolved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PDFBOX-1031) PDFMergerUtility - form fields disappear
[ https://issues.apache.org/jira/browse/PDFBOX-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Denneboom updated PDFBOX-1031: Attachment: 3.pdf 2.pdf 1.pdf 1 and 2 are the input files. 3 is the result. PDFMergerUtility - form fields disappear Key: PDFBOX-1031 URL: https://issues.apache.org/jira/browse/PDFBOX-1031 Project: PDFBox Issue Type: Bug Components: Utilities Affects Versions: 1.5.0 Environment: Windows 7, Acrobat Pro 9, Eclipse Helios SR2 Reporter: Gilad Denneboom Labels: form, util Attachments: 1.pdf, 2.pdf, 3.pdf I merge 2 PDF files with fields in them, but the result PDF contains no fields. I believe this is related to https://issues.apache.org/jira/browse/PDFBOX-930, which remains unsolved. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PDFBOX-1024) Some PDBorderStyleDictionary options not honored
Some PDBorderStyleDictionary options not honored Key: PDFBOX-1024 URL: https://issues.apache.org/jira/browse/PDFBOX-1024 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.5.0 Environment: Windows 7, Acrobat 9 Pro, Reader X Reporter: Gilad Denneboom Priority: Minor I'm creating links and using PDBorderStyleDictionary to set the border style, but have noticed that some options are not honored when opening the files. Here are my findings: PDBorderStyleDictionary.STYLE_UNDERLINE = works correctly. PDBorderStyleDictionary.STYLE_SOLID = works correctly. PDBorderStyleDictionary.STYLE_BEVELED = identical to using SOLID. PDBorderStyleDictionary.STYLE_INSET = identical to using SOLID. PDBorderStyleDictionary.STYLE_DASHED = identical to using SOLID in appearance, link type under Properties in Acrobat is Custom. I've noticed that when I manually create a link in Acrobat the only options are Solid, Dashed and Underline, so maybe the PDF specs have changed and need to be updated in PDFBox as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (PDFBOX-457) PDF to Image doesn't show correctly the document
[ https://issues.apache.org/jira/browse/PDFBOX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918896#action_12918896 ] Gilad Denneboom edited comment on PDFBOX-457 at 10/7/10 8:13 AM: - Any more info on this issue? I'm having a similar problem while using PDFToImage on a PDF made from a scanned TIFF (The producer plugin is by PDF Technologies). The result is a blank image, even though I can see the image when I open the file in Acrobat. Adding JAI_core and JAI_codec to the classpath didn't seem to change much. Am I missing something here? was (Author: giladd): Any more info on this issue? I'm having a similar problem while using PDFToImage on a PDF made from a scanned TIFF (The producer plugin is by PDF Technologies). The result is a blank image, even though I can see the image when I open the file in Acrobat. Adding JAI_core and JAI_coded to the classpath didn't seem to change much. Am I missing something here? PDF to Image doesn't show correctly the document Key: PDFBOX-457 URL: https://issues.apache.org/jira/browse/PDFBOX-457 Project: PDFBox Issue Type: Bug Affects Versions: 0.8.0-incubator Reporter: Marcelo Tavares Assignee: Daniel Wilson Attachments: 580505.PR3.03.PDF, pdfbox-457-as_fax.pdf, pdfbox-457-Scan_from_a_Xerox_WorkCentre_Pro.PDF, pdfbox-457.PNG, testPDFToImage1.png I tried to convert the following document to image, but I got the attached result. It parsed just the text. I also tried different formats like JPG. I ran it using the PDFToImage class passing the document path as parameter. I've read that sometimes the document is not created respecting the PDF standard. But, is there a possibility to ignore it?! In fact, it's very important to me, so, could I use PDF Box despite of those errors? Thank you Marcelo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PDFBOX-432) PDField in a page
[ https://issues.apache.org/jira/browse/PDFBOX-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12890708#action_12890708 ] Gilad Denneboom commented on PDFBOX-432: From a PDField you can get the widget, and from that you can get the page. So if you have PDField f, do this: f.getWidget().getPage() PDField in a page - Key: PDFBOX-432 URL: https://issues.apache.org/jira/browse/PDFBOX-432 Project: PDFBox Issue Type: Wish Components: PDModel.AcroForm Reporter: Christian Zanata I think it could be nice to know wich page a PDField belongs to. For example I have several pages and a lot of form fields but I would like to populate them page per page. I try to understand how to obtain info like this from a PDPage or a PDField but I always fail. For example iText give me the page number a field belongs to when I ask for the position of a field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PDFBOX-772) Re-setting filled properties of PDDocumentInformation do not take
[ https://issues.apache.org/jira/browse/PDFBOX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887316#action_12887316 ] Gilad Denneboom commented on PDFBOX-772: Glad to hear it will be solved! Any workarounds for the moment, though? Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Fix For: 1.3.0 Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PDFBOX-772) Re-setting filled properties of PDDocumentInformation do not take
Re-setting filled properties of PDDocumentInformation do not take --- Key: PDFBOX-772 URL: https://issues.apache.org/jira/browse/PDFBOX-772 Project: PDFBox Issue Type: Bug Components: PDModel Affects Versions: 1.2.0 Environment: Win XP SP2 Reporter: Gilad Denneboom Setting any of the properties on PDDocumentInformation which were already filled-in has no effect. The old values remain in place. Empty properties can be set to new values, but pre-existing values can't be changed or removed. File info: PDF Version: 1.6 Producer: Distiller 7.0.5 I can upload the files somewhere, if necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
