[FEAT]: Support checkbox and radio button field filling in output PDF

[utkarshqz]

📝 Description

FireForm currently fills text-based PDF fields correctly but provides no support for checkbox or radio button field types. These fields are left blank in the output PDF regardless of what the LLM extracts from the transcript.

This is a gap in the core PDF filling pipeline — the extraction layer already works correctly, making this a targeted and isolated fix in src/filler.py.

💡 Rationale

Emergency response forms commonly include checkbox and radio button fields — for example:

• "Was medical assistance required?" → checkbox
• "Incident type: Fire / Medical / Hazmat" → radio button

Leaving these blank produces incomplete, unusable output PDFs that fail real-world filing requirements. Fixing this is essential for FireForm to serve its stated purpose of automating form completion for firefighters and emergency responders.

🛠️ Proposed Solution

In src/filler.py, add field-type detection and value mapping for /Btn field types:

# Detect field type
field_type = field.get("/FT")

if field_type == "/Btn":
    # Map extracted string value to PDF boolean value
    val = str(value).strip().lower()
    if val in ("yes", "true", "1", "checked"):
        field.update(pdfrw.PdfDict(V=pdfrw.PdfName("Yes"), AS=pdfrw.PdfName("Yes")))
    else:
        field.update(pdfrw.PdfDict(V=pdfrw.PdfName("Off"), AS=pdfrw.PdfName("Off")))

✅ Acceptance Criteria

• Checkbox fields correctly set to /Yes or /Off based on transcript content
• Radio button group selections correctly applied
• Existing text field behavior is completely unchanged
• Unit tests cover checkbox (/Yes) and checkbox (/Off) cases
• Unit tests cover radio button selection

📌 Additional Context

• The LLM extraction layer (src/llm.py) already extracts boolean and choice values correctly — this issue is purely a filler.py mapping problem
• pdfrw supports /Btn field type natively — no new dependencies required
• Related to the broader goal of full PDF field type coverage

[SouravVerma-art]

Hi, I’d like to work on [FEAT]: Support checkbox and radio button field filling in output PDF.
Could you please assign this issue to me?

[SouravVerma-art]

Hi @utkarshqz,
I noticed that I previously opened PR #234 implementing checkbox and radio button field support for this issue. Please let me know if any changes or improvements are needed from my side.

[Cubix33]

Hi @SouravVerma-art and @utkarshqz , this issue has been covered in #143 PR already, with exactly the same implementation. Please do go through the existing issue list to avoid creating redundant issues.

[SouravVerma-art]

Hi @Cubix33, thank you for letting me know . i will check PR #143 and review the existing implementation. I appreciate the guidance and will make sure to go through existing issues and PRs before submitting in the future.

[utkarshqz]

Hi @SouravVerma-art , @Cubix33 — thank you for the feedback.

I reviewed PR #143 , PR #234 and it covers the basics well, but PR #246 is part of a broader "Dynamic-First" architecture I am implementing to ensure FireForm is truly document-agnostic.

While PR #143 , #234 uses a more static approach, PR #246 introduces three key improvements for handling complex agency forms:

1. Dynamic State Mapping

Instead of hardcoding /Yes, the implementation reads the AP.N dictionary from the PDF at runtime to determine the correct on-state name (many PDFs use /On, /1, etc.).

2. Parent/Kid Hierarchy Support

Properly handles grouped radio buttons with nested annotation structures, which often break when fields are treated as a flat list.

3. Data Sanitization & Bug Fixes

• Fixes the issue where None values were written as the literal string "None" into PDFs.
• Improves field classification using both /FT and /Ff flags.

This change is intentionally aligned with the broader dynamic architecture introduced in my other contributions:

• PR feat: batch multi-template filling with single LLM extraction. Closes… #241 – Dynamic multi-template pipeline allowing a single LLM call to populate multiple forms.
• PR feat: frontend UI, batch LLM extraction, dynamic PDF labels, API hardening #210 – Dynamic labeling system powering the current end-to-end interface.
• Issue [BUG]: InputManager silently returns empty string on encoding errors #243 – The refactored input logic implicitly resolved this legacy bug by replacing the problematic module.

The goal is to make FireForm compatible with any arbitrary PDF structure, rather than relying on assumptions about field states or annotation layouts.

Happy to hear your thoughts on these architectural improvements.

[utkarshqz]

Duplicate of #142