chinapandaman
PPF-1145: Comb Field Characters not Centred
Version
PyPDFForm=3.4.0
Issue Description
Comb field characters not centred within the fields. Characters on the left are to the right and characters on the right are to the left.
This is understandable due to a gap between the character boxes. I though I'd fixed this previously by just reducing x by gap/2 and increasing width by double the amount but it doesn't seem to work now.
Code Snippet
from PyPDFForm import PdfWrapper
pdf = PdfWrapper("Capital-gains-tax-schedule-2022.pdf")
pdf.create_widget(widget_type="text", name="1-6-1", page_number=1, x=29.0, y=515.0, height=17.0, width=536.0, max_length=38, comb=True, bg_color=(0, 0, 0, 0), border_color=(0, 0, 0, 0), border_width=0)
pdf.write("output.pdf")
PDF Form Template
Capital-gains-tax-schedule-2022.pdf
Full code generating automated comb forms for white boxes: markup.py
>python markup.py --markup-blocks --create-fields --input-pdf Capital-gains-tax-schedule-2022.pdf
Generating standalone form fields creation script and running it...
Running generated form field creation script: generate_form_fields.py
Script output:
Created form fields PDF.
Screenshots (if applicable)
What is the precision of PyPDFForm coordinates? (I have a vague recollection it is integer points.)
Both the x and y and the width and height simply manipulate the Rect property of a form field.
The PDF spec doesn’t strictly limit decimal places. I will quote ChatGPT on this:
Precision details:
Data type: Each value is a PDF number, which according to the PDF specification (ISO 32000-1) can be either:
Integer (e.g., 123)
Real number (floating-point in decimal form, e.g., 123.456)
Decimal precision: The spec doesn’t strictly limit decimal places — any number of fractional digits may be written — but in practice, most PDF producers use up to 3–6 decimal places (e.g., 12.345 or 12.345678), because:
PDF numbers are stored as text until parsed.
Most PDF viewers internally use double-precision floating point (about 15–16 decimal digits of precision) when interpreting coordinates.
Unit system: Coordinates are in user space units (default: 1 unit = 1/72 inch), so very small decimal values are possible.
Key takeaway: Rect is not fixed to integers or limited decimal places — it can store high-precision floating-point values, but effective precision is limited by the PDF reader’s coordinate rendering (and the screen or printer resolution).
From my personal experience, anything beyond 2 decimal places becomes visually impossible to distinguish.
Try
x=27.0andwidth=540.0
It was initially set at x=29.0 and width=536.0, and distance between boxes calculated as gap=1.9.
To adjust mathematically x=x-gap/2, width=width+gap.
Say gap=2:
x=27+1=28andwidth=536+2=538.
x=28.0 and width=538.0 doesn't work but x=27.0 and width=540.0 does. Why?
I suspect there is a 1 point margin around the (comb) field regardless of the border_width setting.
Maybe, but I consider this out of scope for the project, as it simply flips the switch and the rest is just behavior of PDFs. Lots of times it's not uncommon to try multiple times before figuring out the right coordinates combination for creating fields, much like how you would do it in a GUI using many PDF tools.
simply manipulate the Rect property of a form field [according to] The PDF spec.
I'd like to see at least one example in the docs not using integers so it is clear PyPDFForm is not restricted to integers.
just behavior of PDFs
Fine, at least it is not a bug in PyPDFForm.
I still think it is worth a note in the docs that enabling comb field for max_length > 1 will require adjusting x and width to position characters evenly in the comb field. Also worth adding adjustment should include the distance between the comb characters plus a margin, even if border_width = 0.
I've put this in place in https://github.com/flywire/flyfield
Appreciate any comments.