float precision artifacts in PDFs

[rkrenn]

Summary by CodeRabbit

• Bug Fixes
  • Improved precision and consistency in floating-point number formatting within PDF forms.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This change modifies the FLOAT value formatting in the PDF form rendering by introducing BigDecimal conversion from string representation to improve numeric precision before applying the number format. Null handling and color logic remain unchanged.

Changes

Cohort / File(s)	Change Summary
FLOAT Formatting Enhancement core/src/main/java/org/phoenixctms/ctsms/pdf/InputFieldPDFBlock.java	Adds BigDecimal import and updates renderFormattedValue method to format FLOAT values via BigDecimal.valueOf(value.toString()) before number format application, while preserving null and color behavior

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Single-file, localized change to one method
• Straightforward numeric formatting improvement with established BigDecimal pattern
• No structural refactoring or complex logic changes
• Clear, focused modification with minimal risk

Poem

A rabbit hops with glee so bright, ✨
BigDecimal brings precision right,
No more float precision woes,
The numbers flow just as it goes! 🐰

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'float precision artifacts in PDFs' directly relates to the main change, which addresses float formatting issues in PDF rendering by using BigDecimal to prevent precision problems.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch pdf_float_precision

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

core/src/main/java/org/phoenixctms/ctsms/pdf/InputFieldPDFBlock.java (1)

3-3: BigDecimal-based formatting aligns with goal; consider guarding NaN/Infinity for robustness

Using BigDecimal constructed from the Float’s string representation is a reasonable way to stabilize decimal formatting and matches the PR’s intent of reducing precision artefacts. The import at Line 3 and the updated FLOAT branch at Lines 485–497 look consistent with the surrounding formatting logic and keep null/preset handling and coloring intact.

One thing to double‑check: Float.toString returns "NaN", "Infinity", or "-Infinity" for non‑finite values. new BigDecimal("NaN") (or "Infinity", "-Infinity") will throw NumberFormatException, which would now break PDF rendering if such a value ever slipped through validation. Previously, DecimalFormat.format(Float.NaN) would not throw.

If it is possible (even theoretically) for getFloatValue(...) to return NaN or Infinity, consider a small guard, e.g.:

-        value = getFloatValue(blank);
-        numberFormat = getFloatValueFormat();
-        if (value != null) {
-            string = numberFormat.format(new BigDecimal(value.toString()));
+        Float floatValue = getFloatValue(blank);
+        numberFormat = getFloatValueFormat();
+        if (floatValue != null) {
+            if (floatValue.isNaN() || floatValue.isInfinite()) {
+                // Fall back to the plain string representation or previous behavior
+                string = floatValue.toString();
+            } else {
+                string = numberFormat.format(new BigDecimal(floatValue.toString()));
+            }
         } else {
             string = (isShowPresetValues() ? getFloatValueFormatPattern() : null);
             isPresetColor = true;
         }

If your validation guarantees only finite values for FLOAT fields, the current implementation is fine but it would be good to document that invariant near getFloatValue / the field definition.

Also applies to: 485-497

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e54b9c1 and eaa0b87.

📒 Files selected for processing (1)

• core/src/main/java/org/phoenixctms/ctsms/pdf/InputFieldPDFBlock.java (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Build and Test