I would like to build a small internal application for users to view a document and answer some questions, then sign it electronically - either by clicking a button or typing or moving their mouse or finger if on a mobile device. Imagine a DocuSign style of system whereby some fields are exposed to you, your answers are entered into those fields, and then you can sign it.
I was told by Aspose that GroupDocs API can provide such tools. Our documents start as Word docs and are merged and converted to PDF. However, all this is in .NET and we wrote the code, so it can change anytime.
To be clear - it’s to be used by people who are not technically savvy… they cannot be responsible for creating fields or areas on the form to work with. They can only see the document and be forced into answering specific things, signing it, etc. Much like DocuSign or equivalent products.
Is this possible?
Hi, David
@deisenberg
Thank you for your interest in GroupDocs Product
Your query precisely matches our product purpose and vision.
Let me share few product concepts that will help you to understand it better.
GroupDocs.Signature product has few versions
- GroupDocs.Signature for .NET/Java - server side solution as standalone library that implements low level document operations like editing, updating and formatting based on signature options user wants to apply to the document.
.NET, Java, Cloud APIs & Online Document Signature Apps
With this library on server side user is able to compose documents, add different signatures (text, image, digital, barcode, qrcode, metadata, form fields etc).
This library expects document and options as input and returns changed document (file/stream) with signatures were passed as options.
Also project provides ability to verify, validate and search for document signatures, same as keep document change history inside the document metadata (secured)
See samples on GitHub
-
GroupDocs Signature Cloud - document eSign REST API based solution. This approach allow users to manipulate features from p.1 above over REST API calls.
Document Signature Solutions and Apps -
Non comerial GroupDocs Signature Free App, front-end samples like GroupDocs.Signature for MVC - are demonstrations of how to use solutions from points 1 and 2.
I will put links below to check our resources.
Refering DocuSign solution you will need to build server side backend and UI fron-end parts.
So GroupDocs products for .NET/Java will help you to compose server side backend software.
Front-End part will query server side for following features
- upload document and retrieve document info and document page(s) as image(s)
- send UI Front-End elements and changes for document to server side to download changed document
You can see very simple demo here
Secure Digital Signature | Sign Documents Online
that shows how to build DocuSig-type solution
Server side will implement following operations
- retrieve document from web (upload to server)
- return document information and document pages ( for Front-End)
- accept document changes from UI (as list of signature options) and return changed document
GroupDocs Signature cloud will allow to use cloud API calls event on Front-end side to retrieve document information, its pages and apply changes to the document.
Summarizing
GroupDocs.Signature for .net/java allows to manipulate documents on low level:
- retrieve document information and its pages
- retrieve document change history and existing signtures
- made changes to the document with new signatures (various type), modify them and delete
- apply document verification (verify if document contains some required signatures per passed conditions etc)
- search for existing document signatures
Front-end UI solution
- displays document information and view (obtained from Signature library on server side)
- Keep changes to the document in browser cache as list of various options to be applied to the document.
Please find following useful links on examples GitHub and Dev Guide
Dev Guide
Hope it will help you!
Please ask if you have some more questions.
Thank you!
Thanks for the information and quick response. I’ve seen your demo software and it’s neat but it shows what a doc template Admin might do to setup and configure a document. My point here is that these documents are already built.
For example, imagine a Word document which has a spot for your Name, a spot for your Date of Birth, and a spot for your Signature. These field elements are already marked in the document itself with find-replace fields like {NAME} and {DOB} and {SEX} and {SIGNATURE}. During our back-end processing, the .NET system already replaces {NAME} and {DOB} with your name and date of birth. It’s just now waiting for YOU to answer what your Sex is and then Sign it. You (you are not a developer and not a doc admin person, just an employee) should be presented with the document (it could stay in Word format or be converted to PDF quickly) and be forced to answer the Sex question in the correct spot. Then, moved to the Signature spot and forced to sign it (either with your mouse or by typing your name, etc.)
The only thing I see in your samples are how to actually build the document itself by drag-and-drop field elements onto it. That’s great, but that’s done only once, then the template is finished. I’m talking about how that template is now used, over and over again, per employee.
As we mentioned earlier, those are the demo projects. Please note that GroupDocs.Signature for .NET is a back-end, UI-agnostic API that could be implemented in any .NET (new or existing) project without any third party tool or software dependency.
As far as your requirements are concerned, you can develop your own web UI that must allow users to just sign and add their sex/gender in the document (assuming that the document is already built and has signature and sex labels). In this case, you just have to pass the source file/document to the API, get the text signature and generate or save the output.
As you can see that API exposes Text signature options like margins or positioning. You can hardcode these things, if you want (as you said the signature position and sex position is pre-defined for all the documents and is mostly same).
Secondly, we also have form field signature feature. As your document has everything pre-defined. But you only want user’s signature and sex details, you can use form field for these two things.
Yes, once you have programmed the application using or without form field feature, user will just see the document, and two things to fill in (sex and signature).
- Using simple text signatures, you can set the signature/sex position in the code (left, top) and it’s just a one time practice. For all the users, they will give their input and it will be adjusted to the specified position.
- Or you just have to generate the signature and sex fields using form fields feature and users will provide their input there.
Please let us know if you still need more information on it.
Thank you for that detailed response, I really appreciate your assistance on this. My next steps will be to download a trial and see if we can build a proof-of-concept application to test the solution.
One thing that is not very clear: is Viewer required for Signature in order to present the PDF on the web browser? Or, does Signature already come with that functionality?
Hi, @deisenberg
Signature provides ability to obtain document information and view of each document page as image. So having Signature library is enough to retrieve document as collection of images at once or by one one. Please find following examples here
Viewer product will give you more ability with previewing all possible document types when Signature allows to view only documents it supports.
Referring back to example you provided. the Signature project allows user to search, verify and update Words Form Fields (these predefined input fields for user).
It means that you may search for them in the document and update them with values.
Responding to your comment:
“the Signature project allows user to search, verify and update Words Form Fields (these predefined input fields for user).
It means that you may search for them in the document and update them with values.”
Aspose Words (and Aspose PDF) already provide this functionality, and we use it extensively. We already perform back-end processing to “merge” data with Word documents, then convert them to PDF and save. For example, we use Aspose Words to find-replace “{NAME}” with the employee’s full name, which we already have in the database.
The next project phase is to take these documents which, after back-end merge, are now 90% complete and display them to the employee in their browser within our secure .NET framework web forms C# application. They should see the finished doc and browse through it while also being forced to complete missing information, and signing it… much like DocuSign will present you with a lease agreement, already complete with your name on it because it was merged in the back-end, but forcing you to finish and sign it. Maybe you need to enter/verify you mailing address, PO number, then sign and submit it.
We want to build that small application to allow the new employee to read/fill-in/sign.
If it were as simply as displaying a few web form text boxes to the employee so they can answer questions, then re-merging (Aspose Words find-replace) then we already have that. But what we want to do is more full-featured experience like DocuSign
Hi @deisenberg
It looks like you need to implement Front-End UI with document view, add input elements that will apply required data from user and pass entered values to the back-end where Signature will apply these to form final document.
From the sign perspective you will need to pass PFX file to the Signature to sign document.
Please share how Signature product may help you more or what functionality from your perspective is missing to solve your request
- generate PFX Certificates signatures file in Signature library (don’t expect existing PFX file as only one possible way to sign the document
- more example of Fron-end + backend API implementation
Thank you!
Thank you!
The biggest issue I see here is having the ability to show the PDF in the web page while positioning the HTML text box in the correct place in the PDF on-screen.
We can already ask them for their name, of course, using a standard HTML text box. Then, we can merge their response into a PDF anywhere we want.
However, instead, we want to display that PDF to them and show the text box at the correct X,Y position within the PDF document itself in the web page live in real-time as they read it. As if they are reading the PDF and writing in their response in the correct place in the PDF page.
Imagine the following workflow within the webforms .NET project:
- Navigate to the correct URL and authenticate the employee/user
- Display the appropriate PDF on their browser window/web page
- Jump to a bookmark/position in the PDF automatically, positioning the PDF to the correct page and scrolling to the correct location to reveal the text box (or signature line) where they must type their answer
- Accept their response by allowing them to type their answer within the rendered text box which is now located at the correct X,Y position inside the rendered PDF on-screen. As if they had the paper in front of them and can handwrite their response onto the paper
- Automatically move to the next required field element, again requiring their response within a text box or signature line.
The biggest challenge here is actually displaying the PDF on the web page while allowing them to see where their answer must be entered on the page.
Yes, it’s a simple task to ask them a bunch of questions by using standard HTML text boxes, checkboxes, etc. but they would just be randomly drawn on the web page together, not appropriately positioned on the document itself. By placing these field elements on the PDF itself, in their correct spots, the user’s experience is much better and it feels as though they are actually filling out a form rather than answering a simple list of questions and having those answers later positioned onto the PDF on the back-end (which we can already do)
Hi, @deisenberg
Yeah, I see your points.
For our app demo we simulate controls on page using client scripts/Angular, handling all mouse events etc. According to precise location you may call signature.Search method to retrieve PDF elements positions and calculate proper element on PDF Page view.
I will try to check some similar solutions in our open source code
Thanks