https://drive.google.com/file/d/17JtXs0d_DPgLQVCcdIQSd03VTsTe2xdJ/view?usp=sharing
That's the link to the code you can download. I think your right about incremental save... but no matter I try, I can fill out the form, I can sign the form, but when I try to do both at the same time I break one or the other. -----Original Message----- From: Tilman Hausherr <thaush...@t-online.de> Sent: December 11, 2019 11:27 PM To: users@pdfbox.apache.org Subject: Re: PDFBox 1.8.10 Question You responded to the wrong thread, so I am moving this back here... I can't see your code except two lines, you need to upload this somewhere. What I see is that you use save() instead of incremental save. You need to first get the example to run, unchanged. The example uses incremental save. Then make your changes. If it still doesn't work, please upload source and result PDF and code to a sharehoster. As I wrote, the example in 1.8 doesn't support adding signatures to existing PDFs but it may be worth a try with the code I posted. To put a signature in a field it must be a empty signature field. You can only add 1 signature at a time. I.e. load, sign, save incrementally. Tilman Am 11.12.2019 um 20:14 schrieb Wade Polk: > In PDFBox 1.8.10, I sign the form with code very similar to the > CreateVisibleSignature.java example. > > This seems to work well enough, however when I fill out the form FIRST > using code like the below, it breaks the signature; when I click on > the signature I see error message "Error during signature > verification, Unexpected byte range values defining scope of signed > data., Details: The signature byte range is invalid." > > This is how I set field on my form fields: > PDTextbox field = (PDTextbox) acroForm.getField( fieldName ); > field.setValue(fieldValue); pdfDocument.save(pdfFilePath); > > I get the impression I have to associate every applicable field with > this signature, but just a guess. > > Note: > - My form has 8 signatures and various fields to be filled out by each. > - I would prefer to have all fields and signature lines locked on the > PDF beforehand and then just to set them with my code, but I believe > with this version you can only place a signature and not fill out an > existing signature field, correct? > > I definitely feel like I'm missing something, any help is appreciated. > > > -----Original Message----- > From: Tilman Hausherr <thaush...@t-online.de> > Sent: December 11, 2019 1:46 PM > To: users@pdfbox.apache.org > Subject: Re: Page boxes differ between Acrobat and PDFBox > > Ouch, I've known about this, but put it on low priority because I've > never seen such a file before. I've opened > > https://issues.apache.org/jira/browse/PDFBOX-4706 > > I'm not yet sure what to do, but COSName.USER_UNIT is the minimum. > Getter/Setter probably too. > > Tilman > > Am 11.12.2019 um 18:31 schrieb Gilad Denneboom: >> Hmm, that's very interesting. Should PDFBox take that value into >> account when reporting the page size, then? >> I see this is a property of the page. Should this be added to PDFBox >> through a getter/setter? Or at least UserUnit should be added to the >> COSName enum? >> Thanks a lot for the information, anyway. It gives me a way to solve >> this issue! >> >> On Wed, Dec 11, 2019 at 4:24 PM Peter Wyatt <petervwy...@gmail.com> >> wrote: >> >>> The sample PDF provided has a /UserUnit key with the value 3 in the >>> Page dictionary. This key was introduced in PDF 1.6 and is described >>> in various specifications along the lines of "(Optional; PDF 1.6) A >>> positive number giving the size of default user space units, in >>> multiples of 1 ⁄ 72 inch." so it is a scaling factor on default user >>> space. So, based on what you have reported, Acrobat is entirely >>> correct and confirmed by other tooling. >>> >>> Peter >>> ISO 32000 co-Project Leader >>> >>> On Wed, Dec 11, 2019 at 10:13 AM Gilad Denneboom >>> <gilad.denneb...@gmail.com> wrote: >>>> Hi all, >>>> >>>> This issue really stumps me. I'm getting different page box values >>> between >>>> PDFBox and Acrobat, and even within Acrobat itself... >>>> The files I'm working with are very large housing plans. >>>> When I open them in Acrobat it reports the page size to be 35.93 x >>>> 435.20 inches, but when I use a script I get different results, >>>> namely 11.97 x >>>> 145.06 inches, which is also what I'm getting when I use PDFBox 2.0.16. >>> It >>>> seems the difference is exactly 1/3, ie the page boxes reported by >>> Acrobat >>>> are 3 times as large as those PDFBox and the script find. The same >>>> is >>> true >>>> of all boxes (Crop, Trim, Bleed, Art, etc.). >>>> I think the results reported by Acrobat are the correct ones, but I >>>> can't figure out where they're coming from... Any insight would be >>>> very much appreciated. >>>> >>>> A sample file can be found here: >>>> https://drive.google.com/open?id=1FeFs1W0Iesz6Kcq3wTU_LclyIgmFBOsF >>>> >>>> Thanks in advance! >>> -------------------------------------------------------------------- >>> - To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org >>> For additional commands, e-mail: users-h...@pdfbox.apache.org >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: users-h...@pdfbox.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org For additional commands, e-mail: users-h...@pdfbox.apache.org
