added note: as Tabs is defined on a Page level it's clear that this addresses the Annotation and not the form field as a form field can have multiple representations on the same and/or multiple pages. The visual part of the form field is defined by the annotation. The form field itself i.e. without the annotation(s) doesn't have a physical representation.
Am Mittwoch, dem 31.01.2024 um 18:22 +0100 schrieb sahy...@fileaffairs.de: > Dear Dwayne, > > for a generic solution reordering the fields won't help. > > A field can be nested inside a field tree but let's say one of the > nested fields is on top of the page and the other is on the bottom of > the page. Now another nested structure might have fields in between. > You can not move fields out of a nested structure to match the > physical > order as this will have consequences such as naming etc. > > E.g. > > Visual Order on the page > > [Policy.PolicyNumber] [Date] > [Policy.PolicyName] > > > from that you'd need to prompt for Policy.PolicyNumber, Date, > Policy.PolicyName > > > > AcroForm Order > > Policy > PolicyNumber > PolicyName > Date > > You can not move PolicyName below Date as it's nested inside Policy. > If > you move PolicyName out the structure would be > > Policy > PolicyNumber > Date > PolicyName > > But that changes a) the fully qualified name of the field and as > childs > can inherit from parents moving might miss properties only defined in > Policy. > > > The UI application needs to follow the definition of the visual order > as specified in the PDF. This should depend on the (Widget) > annotations > location on the page as this defines the physical location and is > what > you are looking for. > > There is also a (optional) Tabs key inside the Page dictionary which > can define the order the application should follow when tabbing > through > the (visual appearance) of the fields. > > from the spec: > > "R (row order), C (column order), and S (structure > order). Beginning with PDF 2.0, additional values also include A > (annotations array order) and W (widget order). Annotations array > order refers to the order of the annotation enumerated in the Annots > entry of the Page dictionary (see "Table 31 — Entries in a page > object"). Widget order means using the same array ordering but > making two passes, the first only picking the widget annotations and > the second picking all other annotations." > > > Now if the proprietry software doesn't follow these rules what about > parsing the PDF and generating the "prompt" list instead of doing it > manually. Generating can be done by looking at the physical location > of > the Widget annotations associated to a particular form field so you'd > be able to generate the field list the way they appear in the PDF and > feed that into your configuration for the form. > > BR > Maruan > > > Am Dienstag, dem 30.01.2024 um 18:40 -0600 schrieb Dwayne Parks: > > I am almost certain that the expected order is basically top-left > > to > > bottom-right, yes. Currently there is no calculation being used > > that > > I > > know of. > > > > Flattening: The issue isn't in the actual flattening itself. I > > need > > to > > explain more about the way the PDFs are used. > > > > The proprietary software is running as a web service where we > > upload > > multiple "forms" in PDF form as a library. At the simplest level, > > the > > fields on the form are one of two types. > > > > Field Type 1 is an internal field name that the software matches to > > internal data that it uses to set the field's value. Say, if the > > field > > name is "Policy.PolicyNumber" then it sets the field's contents to > > its > > internal data for the Policy # data that it has... and that is what > > it > > uses when it flattens the PDF. > > > > Field Type 2 has a user-defined field name and the software (during > > the > > process of generating the output PDF, before flattening the fields) > > prompts the user for each user-defined field's contents that will > > be > > used during the flattening. > > > > There is a configuration page for each form that allows some > > control > > over the prompting of data from the user (validation constraints, > > descriptive names for prompts, etc.) and a basic way to reorder the > > order that the fields are processed (drag and drop a field up or > > down > > in > > the order, one field at a time), but if the form is edited in any > > way, > > this order "resets" to one based off of the PDF's contents. > > > > Some forms have hundreds of fields on them and so we are having > > semi-technical people trying to "build out" multiple forms and > > getting > > very frustrated when they need to make a small change in an edition > > of a > > form and suddenly the order is reset to an unexpected order (I > > believe > > the same order that fields/widgets appear in the PDFBox debugger's > > "internal structure" tree view under Root/Catalog -> AcroForm -> > > Fields) > > when they re-upload the PDF file. > > > > Why this order is important (for the Type 2 fields only) is that we > > want > > the user to be prompted for each user-defined field in order from > > top-left to bottom-right, row by row. When the order is off, this > > is > > no > > longer possible. > > > > No errors are thrown as the proprietary software will happily > > prompt > > the > > user for the user-defined fields, but... it is adding hours to the > > form > > updating time and starting to drive our semi-technical people > > crazy. > > > > One other approach is to figure out how to force the order of the > > fields > > in Acrobat (which can be changed by dragging the fields up/down to > > position them in the list of field names) to be "honored" when it > > writes > > out the PDF contents to a file. It doesn't appear to do so. And > > it > > also sometimes creates Fields with Widgets as "Kids" and fields > > with > > the > > Widget data combined with the Field data when new fields are > > created > > via > > copy/paste... all of this I had hoped to handle with a "cleanup" > > utility that would take the user-edited PDFs as a source and create > > cleaned up PDFs as separate output files. > > > > I hope that that makes more sense on the why. Thanks for > > listening!!! > > > > - Dwayne > > > > On 1/30/2024 3:33 PM, sahy...@fileaffairs.de wrote: > > > > > > > > > what is the expected order? Is it by location, top left to bottom > > > right? Calculation order ... > > > > > > Never heard that order matters for flattening. Is the proprietry > > > software throwing any errors which would be a hint? > > > > > > > > > BR > > > Maruan > > > > > > Am Dienstag, dem 30.01.2024 um 15:27 -0600 schrieb Dwayne Parks: > > > > Hello list! > > > > > > > > I'm dealing with a proprietary software product that accepts > > > > PDFs > > > > with > > > > fields in them to "flatten" into a final output PDF. The > > > > difficulty > > > > is > > > > that it expects the ordering of the fields (or their associated > > > > widgets) > > > > to be in a certain order. I don't know the exact details of > > > > this, > > > > but > > > > it takes much trial and error for our folks here manually > > > > deleting > > > > and > > > > recreating fields, trying them and seeing if they are accepted. > > > > > > > > So, to greatly streamline the process of getting the > > > > field/widget > > > > content in the PDF files in a correct order, I would like to > > > > write a > > > > utility that takes a configuration file containing a list of > > > > Field > > > > Names > > > > and reorders the content in the PDF to match the order they are > > > > in > > > > the > > > > configuration file. > > > > > > > > My naive initial idea is to: > > > > > > > > - Write a utility that outputs the current list of fields > > > > (in > > > > the > > > > PDF in the order that they are there) into a config file > > > > - Allow a user to reorder the lines of field names as > > > > desired > > > > - Write a utility that takes the config file and the PDF and > > > > rebuilds the field list/tree in the order that the config > > > > file > > > > specifies... then writes out the updated PDF contents to a > > > > new > > > > PDF file > > > > > > > > Alternately, I believe that there is an order for forms/widgets > > > > that > > > > is > > > > specified in Adobe Acrobat (tab order?) that I might be able to > > > > try > > > > to > > > > try to recreate. I'm not sure if that will work, but it would > > > > allow > > > > non-technical users to define the needed order without > > > > intervention > > > > from > > > > technical staff. > > > > > > > > I realize that there might be issues with combined field/widget > > > > fields > > > > if it comes to needing to order the widgets instead, but I am > > > > wanting > > > > to > > > > start with the above and go from there. > > > > > > > > So, I have a few questions to start with that someone might be > > > > able > > > > to > > > > help me out with! > > > > > > > > - Are there any examples of doing this sort of order > > > > modification? > > > > - Is it possible to reorder field contents at the PDDocument / > > > > PDAcroForm / PDField level? > > > > - Is it possible to reorder widget annotations at the > > > > PDAnnotiation / > > > > PDAnnotationWidget level? > > > > - Do I need to drop down to the COS* object level to do this? > > > > > > > > Thanks in advance for any pointers, info or suggestions! > > > > > > > > - Dwayne > > > > > > > > --------------------------------------------------------------- > > > > -- > > > > ---- > > > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > > > > > > > > > ----------------------------------------------------------------- > > > -- > > > -- > > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > > For additional commands, e-mail: users-h...@pdfbox.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
