[
https://issues.apache.org/jira/browse/PDFBOX-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler resolved PDFBOX-127.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.8.0
Assignee: Andreas Lehmkühler
I guess this issue is solved by PDFBOX-1492
> Accessing XML-Forms (patch provided)
> ------------------------------------
>
> Key: PDFBOX-127
> URL: https://issues.apache.org/jira/browse/PDFBOX-127
> Project: PDFBox
> Issue Type: New Feature
> Components: PDModel
> Assignee: Andreas Lehmkühler
> Fix For: 1.8.0
>
>
> [imported from SourceForge]
> http://sourceforge.net/tracker/index.php?group_id=78314&atid=552835&aid=1420152
> Originally submitted by mig-o on 2006-01-31 00:42.
> Hi all,
> I have to modify forms in the new PDF1.6 format, so it
> seems like its up to me to implement it (since no one
> has done before).
> I will provide my development as a series of patches
> (just in case i give up, and get other things to do, my
> work is not lost then ;)
> This one allows to get the xml in the Form. It adds
> getter-Functions to the PDXFA, that return
> org.w3c.Element-Objects for the XFA.
> I will have to try modifing them by hand, and will
> provide write support in the next patch.
> Some questions left open:
> - Is it okey to handle errors like i did with
> RuntimeExceptions?
> - Maybe i missed the point in my modification of
> COSDictionaryMap.convertBasicTypesToMap(). I like it
> more like it is the wys i did, but maybe it breks
> something on your side so please check.
> - I added getStreamAsString-Functions to COSStream,
> since most interesting Streams are ASCII anyway.
> [attachment on SourceForge]
> http://sourceforge.net/tracker/download.php?group_id=78314&atid=552835&aid=1420152&file_id=165613
> patch.txt (text/plain), 6546 bytes
> patch to add limited, basic access to xml-forms.
> [comment on SourceForge]
> Originally sent by benlitchfield.
> Logged In: YES
> user_id=601708
> Thanks for taking the time to submit a patch, but we should
> talk a little about how we want this designed.
> Today forms are written in two ways, the old way using
> COSDictionary and the new way using XML forms. It would be
> nice if there was a single API that people could use that
> would update fields in both spots. Need to think about how
> we can do that. Such that both old and new get written
> properly and people who use PDFBox don't have to write it
> in both spots.
> Also, despite popular belief I have never met anyone that
> actually wants to work in XML object model, most people
> would rather use a standard java object model.
> For example, I would be willing to bet that most people
> would rather see
> public XFAConfig getConfigXML()
> rather than
> public Element getConfigXML()
> Returing an XML element means that the user is required to
> go look at the XFA documentation to know what is in there
> and handle any details themselves. If a XFAConfig(or
> whatever name) was returned that could do it for them.
> Maybe the XFAConfig simply holds as a data member an
> Element object and is really just a wrapper, just like most
> pdmodel objects are just wrappers to COSDictionaries.
> Ben
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
