You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Robert McHugh (JIRA)" <ji...@apache.org> on 2011/01/28 21:58:44 UTC
[jira] Created: (PDFBOX-952) getParent method of class PDField
doesn't consider both parent keys "P" and "Parent".
getParent method of class PDField doesn't consider both parent keys "P" and "Parent".
--------------------------------------------------------------------------------------
Key: PDFBOX-952
URL: https://issues.apache.org/jira/browse/PDFBOX-952
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.4.0
Environment: Irrelevant for this issue.
Reporter: Robert McHugh
Fix For: 1.5.0
The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
As a result of this design decision there is no way of getting a field's parent page from the getField method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer avoiding the COS data types wherever possible.
Thanks,
Robert McHugh
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PDFBOX-952) getParent method of class PDField
doesn't consider both parent keys "P" and "Parent".
Posted by "Robert McHugh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PDFBOX-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert McHugh updated PDFBOX-952:
---------------------------------
Description:
The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer to avoid the COS data types wherever possible.
Thanks,
Robert McHugh
was:
The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer avoiding the COS data types wherever possible.
Thanks,
Robert McHugh
formatting fix
> getParent method of class PDField doesn't consider both parent keys "P" and "Parent".
> --------------------------------------------------------------------------------------
>
> Key: PDFBOX-952
> URL: https://issues.apache.org/jira/browse/PDFBOX-952
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.4.0
> Environment: Irrelevant for this issue.
> Reporter: Robert McHugh
> Fix For: 1.5.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
> Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
> As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer to avoid the COS data types wherever possible.
> Thanks,
> Robert McHugh
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PDFBOX-952) getParent method of class PDField
doesn't consider both parent keys "P" and "Parent".
Posted by "Robert McHugh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PDFBOX-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert McHugh updated PDFBOX-952:
---------------------------------
Description:
The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer avoiding the COS data types wherever possible.
Thanks,
Robert McHugh
was:
The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
As a result of this design decision there is no way of getting a field's parent page from the getField method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer avoiding the COS data types wherever possible.
Thanks,
Robert McHugh
Replaced the wrong method name getField with getParent.
> getParent method of class PDField doesn't consider both parent keys "P" and "Parent".
> --------------------------------------------------------------------------------------
>
> Key: PDFBOX-952
> URL: https://issues.apache.org/jira/browse/PDFBOX-952
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.4.0
> Environment: Irrelevant for this issue.
> Reporter: Robert McHugh
> Fix For: 1.5.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
> Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
> As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer avoiding the COS data types wherever possible.
> Thanks,
> Robert McHugh
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PDFBOX-952) getParent method of class PDField
doesn't consider both parent keys "P" and "Parent".
Posted by "Andreas Lehmkühler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PDFBOX-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Lehmkühler resolved PDFBOX-952.
---------------------------------------
Resolution: Fixed
Assignee: Andreas Lehmkühler
I fixed that in revision 1065086. I also added some more COSName constants.
Thanks for reporting!
> getParent method of class PDField doesn't consider both parent keys "P" and "Parent".
> --------------------------------------------------------------------------------------
>
> Key: PDFBOX-952
> URL: https://issues.apache.org/jira/browse/PDFBOX-952
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 1.4.0
> Environment: Irrelevant for this issue.
> Reporter: Robert McHugh
> Assignee: Andreas Lehmkühler
> Fix For: 1.5.0
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> The getParent method should lookup a parent using both valid parent keys: "P" and "Parent". The method findFieldType of this class already performs it's lookup using both keys.
> Additionally method getParent of the class PDField has a return type of PDField. While this is appropriate for nested fields this doesn't work for PDPages. I have an AcroForm I'm working with that sets a Page object to be the parent of an AcroForm Field. It does this specifically by setting the "P" key to the object reference for a particular page (e.g. << /P 102 0 R/FT/Btn >> with "102 0 R" being the aforementioned object reference).
> As a result of this design decision there is no way of getting a field's parent page from the getParent method. We are required to get the backing COSDictionary, call getDictionaryObject("P") and create a PDPage Object from scratch. This is workable, but not optimal. We'd prefer to avoid the COS data types wherever possible.
> Thanks,
> Robert McHugh
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.