[ 
https://issues.apache.org/jira/browse/PDFBOX-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lonzak updated PDFBOX-3547:
---------------------------
    Description: 
*Short*: The handling of signing existing signature fields must be improved 
(and this patch is part of that effort).

*Details and background*
The current implementation for visible signatures always adds new signature 
fields when signing documents.
In that case for that signature everything has to be definied (field 
properties,  coordinates etc.).

Another quite common use case is the use of an existing signature field which 
should be signed. 
There are basically two different roles: The *document creator* who creates the 
document with all its texts, graphics and form fields. The creator knows best 
where everything should be positioned and is even sometimes bound by certain 
regulations about etc. The document creator defines his intend with the "Usage 
rights" and may add a usage right signature.
Then later a *document user* e.g. a customer fills out form fields and signs 
those predefined signature fields. 
In that case the coordinates and a lot of attributes are alrady defined and 
there is no need (and sometimes it is even forbidden) to change the physical 
attributes of those signature fields. The only things which is of interest is 
to set the signature dictionary and to recreate the appearance.

In the current implementation however one needs to define the coordinates of an 
existing signature field again. But not enough since the screen coordinates in 
java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a 
different origin one must convert those existing PDF coordinates to screen 
coordinates so that later those coordinates can be converted to PDF coordinates 
again. This is cumbersome, error prone and totally unecessary... With the 
supplied patch there is no conversion of coordinates anymore.



  was:
*Short*: The handling of signing existing signature fields must be improved 
(and this patch is part of that effort).

*Details and background*
The current implementation for visible signatures always adds new signature 
fields when signing documents.
In that case for that signature everything has to be definied (fields 
properties,  coordinates etc.).

Another quite common use case is the use of an existing signature field which 
should be signed. 
There are basically two different roles: The *document creator* who creates the 
document with all its texts, graphics and form fields. The creator knows best 
where everything should be positioned and is even sometimes bound by certain 
regulations about etc. The document creator defines his intend with the "Usage 
rights" and may add a usage right signature.
Then later a *document user* e.g. a customer fills out form fields and signs 
those predefined signature fields. 
In that case the coordinates and a lot of attributes are alrady defined and 
there is no need (and sometimes it is even forbidden) to change the physical 
attributes of those signature fields. The only things which is of interest is 
to set the signature dictionary and to recreate the appearance.

In the current implementation however one needs to define the coordinates of an 
existing signature field again. But not enough since the screen coordinates in 
java (and in the PDFBox PDVisibleSigBuilder) and PDF coordinates have a 
different origin one must convert those existing PDF coordinates to screen 
coordinates so that later those coordinates can be converted to PDF coordinates 
again. This is cumbersome, error prone and totally unecessary... With the 
supplied patch there is no conversion of coordinates anymore.




> [Patch]Improved signing of existing signature fields
> ----------------------------------------------------
>
>                 Key: PDFBOX-3547
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-3547
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Signing
>    Affects Versions: 2.0.4
>            Reporter: Lonzak
>         Attachments: CreateVisibleSignature.patch, PDDocument.patch
>
>
> *Short*: The handling of signing existing signature fields must be improved 
> (and this patch is part of that effort).
> *Details and background*
> The current implementation for visible signatures always adds new signature 
> fields when signing documents.
> In that case for that signature everything has to be definied (field 
> properties,  coordinates etc.).
> Another quite common use case is the use of an existing signature field which 
> should be signed. 
> There are basically two different roles: The *document creator* who creates 
> the document with all its texts, graphics and form fields. The creator knows 
> best where everything should be positioned and is even sometimes bound by 
> certain regulations about etc. The document creator defines his intend with 
> the "Usage rights" and may add a usage right signature.
> Then later a *document user* e.g. a customer fills out form fields and signs 
> those predefined signature fields. 
> In that case the coordinates and a lot of attributes are alrady defined and 
> there is no need (and sometimes it is even forbidden) to change the physical 
> attributes of those signature fields. The only things which is of interest is 
> to set the signature dictionary and to recreate the appearance.
> In the current implementation however one needs to define the coordinates of 
> an existing signature field again. But not enough since the screen 
> coordinates in java (and in the PDFBox PDVisibleSigBuilder) and PDF 
> coordinates have a different origin one must convert those existing PDF 
> coordinates to screen coordinates so that later those coordinates can be 
> converted to PDF coordinates again. This is cumbersome, error prone and 
> totally unecessary... With the supplied patch there is no conversion of 
> coordinates anymore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to