As far as I can tell, digitally signing a PDF document and creating a corresponding annotation widget is exceptionally rare in the open source world. I am currently working to make this feature in Okular applicable to my every day use cases. A few of the issues I encountered along the way do concern Poppler:
- PDFDoc::sign draws a border around the signature. It's width can be controlled through the
signatureAnnot->generateFieldAppearance()is called before
border->setWidth(borderWidth), and therefore the parameter has no effect.
- Applications cannot pass a font size to be used with
signatureLeftTextand therefore Poppler always uses its default (20).
- Background images are only drawn if
- Qt applications cannot pass an
imagePathto PDFDoc::sign as the data structure passed around doesn't have an attribute for it.
This pull request contains how I did solve these issues. First, I defined a new class
NewSignatureData, which semantically mirrors the class
NewSignatureData I found in the Qt APIs. Then I changed the APIs to use instances of this new class to pass signature related data to
PDFDoc::sign, which is a breaking change to its signature. After that I changed the widget drawing, starting from
PDFDoc::sign and into
AnnotAppearanceBuilder to what I think yields better results:
border->setWidth() and changed
drawSignatureFieldText to always draw a background image (if available), not just if
signatureLeftText is empty.
While developing this I kept moving things back and forth between Okular and Poppler, because I had no idea what could and should be done in Poppler and what could and should be done in Okular. Ultimately the changes I did ...
- enable Qt applications to provide an additional font sized, to be used for "fancy" signatures
- enable Qt applications to provide a background image for signature widgets
borderWidthhave an effect on the generated signature widget
Changing PDFDoc::sign's three line signature to a new object seems a bit arbitrary. It made things easier for me while moving things back and forth and a change is required anyways to provide the second font size. Further more, future work may see users providing their own fonts for their signatures. This is also data that would have to be passed into PDFDoc::sign ...
I understand this PR is quite unsolicited, doesn't fix any recorded issues and is not a small patch. I am happy to make adaptions before these changes can be accepted.