Mapping TextField within SDK

Hi Max, Have you tried the label type, which is with the type of "kESFormFieldTypeLabel"? You can directly see the label content during Signing Ceremony. Duo

Hi, When I parse the PDF with PDFHelper.parsePDFToObjects(atPath: path), I only receive 4 objects which are my 4 signatures zones. However, I have a lot of textfields, about 50. I parse strings with Apple's PDFKit. However, on save, I think I lose objects recognizable by the PDFParser.

Hi Max, I see what you meant, I encountered the same issues at my side that the PDFHelper.parsePDF() function can only recognized signature fields as ESFormField, the "formFields" list is nil (text fields / checkbox). But when I tried the function PDFHelper.parsePDF(), all these fields can be extracted. However, in backend/non-mobile integrations, in order to create a text/ label field and give it a default value, users don't hard code the default values directly to the PDF forms(the value won't be extracted), instead, they use the PDF form property name to map with the ESFormField "name" attribute, by passing in a name-value list to your application(submit from front-end), your application will dynamically set as "value" attribute for this ESFormField. On the contrary, if you directly give PDF form values, you should expect the value directly flattened to PDF before signing, instead of creating OneSpan Sign fields. In current SDK implementation, the value only get flattened after signing(which is inconsistent with desktop integration) Given this background information, please advise your use case: Are you expecting user to input values during signing or the values should be unchangable? why put the value directly to the PDF form? have you integrated with another PDF generator? Or anyway you are able to directly flatten the value to the PDF before creating the package? We can come up with an acceptable workaround then I'll create a support ticket and report to R&D team for the corresponding fix. Duo

Thank you for the detailed reply, Our use case is this one : We want to map the PDF, (not hard coding directly in the PDF) with our data. We have about 100 TextFields that needs to be mapped. I tried using the PDFHelper that comes with the SDK however it doesn't recognize the ID attached to a specific TextField. You can see a screenshot of the dictionary that I receive after parsing the PDF with PDFHelper.parsePDF(). So, we used Apple PDFKit to map our data with the corresponding textfields, and this is working fine. When using ESignLive SDK, we don't want that textFields to be editable. In fact, we could flatten the pdf before signature but we're losing also the signature zones when doing this. The best case scenario would be that we map our textfields without flattening the pdf and that it opens up in the SDK in a read-only mode, except for the signature zones. Hope it is more clear now

Hi Max, Thanks so much for the detailed explanation, much appreciate! I see the problem now: PDFHelper.parsePDFAtPath() function can't extract the PDF form names of text fields. I will create a Jira ticket reporting this. After it's fixed, and the actual form name was extracted, you can create the form in below way:

    ESFormField *label1 = [[ESFormField alloc] initWithName:@"label1" rect:CGRectMake(215, 525, 280, 30) pageNumber:2 type:kESFormFieldTypeLabel];
    label1.value = @"label value1";

For the other function: PDFHelper.parsePDFToObjectsAtPath(), I will also mention it in the ticket that only signature can be extracted, and seems the signature name was not properly set(now it's empty string). Duo

Hi Max, As you may have noticed, with parsePDFAtPath() function, all the form returned with dummy names like "0_0", "0_1", "0_2", so on so forth, which is more like an index with order of position. So as a temporary workaround (probably for testing function or POC purpose), you can map the field values to the dummy names, to see whether the fixed function will fit your use case. Duo