-
|
Hey! I have various PDF files that I created in Adobe products. I've defined some form fields in Acrobat. I'm then grabbing a PDF and loading it into pdf-lib in my app and filling various fields. In one of my PDF files, I've included some text fields that are tall (in height), defined as multiline fields and given a fixed font size. My app does not fill those fields (the intention is that the user that receives the PDF can fill those fields manually). But after going through the pdf-lib processing, the font size for those multiline fields is really big (like, ~100). I've tried to use PDFTextField.setFontSize() to force the fields back to a reasonable size, but that's failed to improve the output. I can see that there's some code in layoutMultilineText in api/text/layout.ts which is used by api/form/appearances.ts: this code appears to be trying to change the font size based on the size of the text in the field (in my case, there's no text in the field). But I don't want that. Is there a way to prevent that code from being executed on my fields? I don't really understand appearances, so I'm not sure if there's a way to use a "leave everything the way you found it" appearance. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
Some findings after scouring through some of the code. I can't be sure that the appearance.ts file is a culprit, but I've done some looking in to the calls, and here's the basic call hierarchy. Overall, the PDFDocument.updateFieldAppearances() call is dependant on a flag on the save call; if that flag is set to false, then the code that I question is not invoked. My concern is that setting that flag to false will prevent more straight-forward text fields from adjusting their text sizes. But it's testable, and if my concern proves true, I might have some options to emulate the save behaviour with some changes (although privacy might thwart me). |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's even worse than I expected. It appears that if I pass in a |
Beta Was this translation helpful? Give feedback.
-
|
New idea: if I manually run the updateAppearances() method on the text fields, I can pass in an alternative implementation of the appearanace provider (one that does not behave the same w.r.t. multiline fields), then we should be able to mark those fields as clean, and therefore the updateFieldAppearances() method shouldn't try to re-update them (with the default appearance provider). |
Beta Was this translation helpful? Give feedback.
-
|
That... seems to have worked. The code's a bit more cut-and-paste-y than I'd prefer, but this'll do for now. |
Beta Was this translation helpful? Give feedback.
New idea: if I manually run the updateAppearances() method on the text fields, I can pass in an alternative implementation of the appearanace provider (one that does not behave the same w.r.t. multiline fields), then we should be able to mark those fields as clean, and therefore the updateFieldAppearances() method shouldn't try to re-update them (with the default appearance provider).