I was performing signing using the iText7 library. I tried signing one of the signature fields available on the document but after the signing, it still shows that field is unsigned. The following is the code snippet that I'm using for signing.
String fieldName = "signature1";
PdfAcroForm pdfAcroForm = PdfAcroForm.getAcroForm(pdfDocument, false);
PdfArray pdfArray = pdfAcroForm.getField(fieldName).getWidgets().get(0).getRectangle();
Rectangle rect = pdfArray.toRectangle();
PdfSignatureAppearance appearance = pdfSigner.getSignatureAppearance().setReason("Test")
.setLocation("Test").setReuseAppearance(false);
appearance.setPageRect(rect).setPageNumber(1);
IExternalSignature pks =
new PrivateKeySignature(pk, DigestAlgorithms.SHA256, provider.getName());
pdfSigner.signDetached(new BouncyCastleDigest(), pks, chain, null, null, null, 0, CryptoStandard.CMS);
original pdf
& signed pdf
Updated
For the following pdf, I'm not getting the signature visibility on the document despite signing the field as mentioned in the response; however, working for the above earlier shared pdf.
pdfSigner.setFieldName(fieldName);
original pdf
& signed pdf
The Original Issue
You forgot to tell the PdfSigner to sign one of the existing form fields, so it creates a new field and signs that.
To tell iText to use a specific field, use PdfSigner.setFieldName:
pdfSigner.setFieldName(fieldName);
According to its JavaDocs this method
Sets the name indicating the field to be signed. The field can already be presented in the document but shall not be signed. If the field is not presented in the document, it will be created.
("presented" should have been "present" I guess...)
Once you do so, there is no need for
appearance.setPageRect(rect).setPageNumber(1);
anymore as the rectangle and page number of the existing form field are used.
The Issue With FORM FDA 1571
In an update you shared a file for which the signature appearance did not show in spite of the correction mentioned above, a FDA 1571 form.
The reason for this is simple: The signature fields in that document are invisible, before and after signing!
before signing
after signing
Thus, it's completely correct that you don't see the signature appearance.
If you want a visible signature appearance, you have to make sure that the signature field is visible.
There are a number of situations in which a signature appearance is invisible, in particular:
The signature widget is not referenced from any page.
The Rect entry of the signature widget is off-page (outside the crop box of the page).
The Rect entry of the signature widget has a width or height of 0.
The signature widget belongs to an optional content group (aka layer) which is switched off.
One of the signature widget flags Invisible, Hidden, or NoView is set.
In case of your form FDA 1571 the Hidden flag is set.
You can unset that flag like this:
PdfAcroForm.getAcroForm(pdfSigner.getDocument(), false)
.getField(fieldName)
.setVisibility(PdfFormField.VISIBLE);
(From SignWithAdaptions test testFda1571)
If you wonder why after manually signing the document the signature is visible: The sign button on the form executes a bit of JavaScript which among other things also clears that Hidden flag.
Related
when I set the ContentDefinitionReferenceId = "api.signuporsignin"
the login screen is shown with the elements sing up now
and forgot password
but among the html elements there is no select with the document type list that I have added. image here
enter image description here
Now when I change the ContentDefinitionReferenceId = "api.selfasserted" now if the list of document types is shown but there is no sign in button, sing Up now, forget the password.Image here
enter image description here
When using combined sign in and sign up, you cannot add more fields to the sign in page. The observation that it breaks the formatting is expected when attempting to do so.
https://learn.microsoft.com/en-gb/azure/active-directory-b2c/self-asserted-technical-profile#output-claims-sign-up-or-sign-in-page
When using selfAsserted, you can add more fields.
If you need more fields, this will be the only option. You will lose the sign up and forgot password links, you’ll have to add your own links if needed which go via your app to a separate B2C policy.
I am using citrix vdi to read an element on webpage. It is able to highlight and read the value in open vdi but in close vdi layout of webpage messes up and element i need went out of bound/off screen from webpage. I have tried minimize and maximize before reading value but invain. I also tried html mode and AA still cannot read it. In html mode i kept only path attribute for element, value remains exactly same on close and open vdi. The only difference i have notice is width of div in which element resides. Div width changes in open 1921and close 1203 which i assume push element out of screen bounds. Any help will be appreciated.
When working with Blue Prism don’t rely on initial attribute set. You need to choose as few attributes as possible to uniquely identify element. You should always untick attributes that are empty or it’s value it’s “Self” (for example Element ID attribute tends to have such value which doesn’t mean anything). Generally, attributes connected with elements position on the screen or its size are not helpful, because it may be easily affected.
When working with HTML spy mode your elements don’t need to be visible on screen to interact with them (unless you are using surface automation techniques), HTML elements don’t have any Visible or Screen Visible attributes.
Try to use attributes like:
Tag Name
Class Name
ID
If Value has always particular text, use wildcard type of match: text
Path attribute is not always the best choice as it might change because web page is dynamic or application update mess up the layout. If you won’t be able to identify element any other way, make sure you use Path as Dynamic match type & store it as environmental variable, so it could be easily adjusted if needed.
If you have problems reading value using “Get Current Value”, try “Get HTML Attribute” in Read stage options & try “Value” or “Title” as an Input.
I get the following error when placing Anchor Tags with a Y offset that will exceed the current page: TAB_OUT_OF_BOUNDS
Any suggestions on how I should handle such cases?
As the error message indicates, the resulting tab placement based off the anchor string, plus the addition of the specified Y offset to the anchor string is causing the tab to go off the page. Either modify the placement of the actual anchor string, or modify the Y offset you are providing for this particular tag to keep it on the page. Depending on your anchor string definitions/approach, you may need to special case this particular tag.
In our case there were some fields at the very edge of a couple of the pages at the bottom causing the automated process to place (something?) outside the page boundaries. We deleted the edge fields and it worked.
steps to reproduce:
upload our document
make a POST to envelopes with templateId specified in the body
in this case it's docusign's system messing up, not ours, and one should think that their system would be able to handle elements that are nearing the document boundaries, also the error message is vague as hell and makes you mistakenly think that there's a field in the source PDF called "Text 42" or "Text 53" or whatever that their system is assigning the I guess auto-generated off-page element.
We are using the Docusign REST API. Now we have an conditional initial tab whose parent tag is a check box. I was able to set the check box to selected when there is no conditional initial field depending on it using the following code: checkboxTabs {tabLabel: "", selected: true}
But when I added the initial field and set the check box as its parent, I was not able to set the check box value.
What is wrong with my code?
I see in the REST API guide it state this about Check Box tabs:
If the parent tab is a Checkbox, Radio button, Optional Signature, or Optional Initial use “on” as the value to show that the parent tab is active.
Are you doing this?
DocuSign Documentation Page
Docusign marks TabLabel for parent fields with some kind of GUID. Unfortunately, it is not visible in template editor, so you have to download template's xml and find your tab there.
Tab label will look like:
<TabLabel>##parent3deb3045-7e98-4ae6-9186-1f9192e3cc79##LABEL_NAME</TabLabel>
You have to use this name in order to prepopulate it.
P.S. This issue was very confusing. I think it should be mentioned in official documentation.
I have a SproutCore Pane - a PalettePane, specifically - which includes a form tied to an object elsewhere on the screen. The Pane is causing trouble with the object deletion interaction. The way I want it to work is:
If a text input field is in focus, the backspace/delete keys should apply to those fields (i.e. editing the text)
If no text input field has focus, the backspace/delete keys should delete the selected object related to the form. (The pane appears when the user has selected an object, so if the pane exists there's a selected object.)
So far, I get one of these behaviors or the other, never both. If I set acceptsKeyPane: YES in the Pane, I get the backspace/delete keys applying to the text fields, but no deleting of selected objects when the text fields don't have focus. If I use acceptsKeyPane: NO, when I'm editing a text field and hit backspace, it deletes the object I was trying to edit.
To add insult to injury, in Firefox with acceptsKeyPane: YES the backspace key is caught by the browser and interpreted as a back-button click, which is going to be frustrating to the user.
I've looked at the root_responder.js code and it looks like SproutCore handles backspaces differently for Firefox, but if I can handle them as described above the distinction between FF and other browsers should be moot.
ETA May 2011: Bear in mind when reading answers here that the SproutCore API for 1.5, 1.6 and beyond may not be the same as this.
Here's how we finally wound up doing it:
When the pane was created, we called becomeFirstResponder() on it.
We added acceptsFirstResponder: YES to its view definition.
Then we added to the view definition:
keyDown: function(evt) {
return this.interpretKeyEvents(evt) ? YES : NO;
},
deleteBackward: function() {
this.get('objectToEdit').destroy();
return YES;
},
deleteForward: function() {
this.get('objectToEdit').destroy();
return YES;
}
...and that did the trick.