Skip to content

[Bug]: numberToString function doesn't properly handle null values in pdf.js/src/core/core_utils.js #19877

@lyyffee

Description

@lyyffee

Attach (recommended) or Link to PDF file

The bug is about node.js logic.

Web browser and its version

node.js

Operating system and its version

ubuntu 22.04

PDF.js version

v5.2.133

Is the bug present in the latest PDF.js version?

Yes

Is a browser extension

No

Steps to reproduce the problem

// Implementation of numberToString function 
// Source: /pdf.js/src/core/core_utils.js
function numberToString(value) {
    if (Number.isInteger(value)) {
      return value.toString();
    }
  
    const roundedValue = Math.round(value * 100);
    if (roundedValue % 100 === 0) {
      return (roundedValue / 100).toString();
    }
  
    if (roundedValue % 10 === 0) {
      return value.toFixed(1);
    }
  
    return value.toFixed(2);
  }
  
  // Test and output results
  console.log('=== numberToString Function Test ===');
  console.log(`numberToString(42.345) = "${numberToString(42.345)}"`);
  console.log(`numberToString(-42.345) = "${numberToString(-42.345)}"`);
  console.log(`numberToString(0) = "${numberToString(0)}"`);
  console.log(`numberToString(null) = "${numberToString(null)}"`); // This will output "0", demonstrating the bug
  
  try {
    console.log(`numberToString("42.345") = "${numberToString("42.345")}"`);
  } catch (error) {
    console.log(`String input error: ${error.message}`); // Will throw an error because strings don't have a toFixed method
  }

The implement is copy from the source code, and we focus on when the input is "null".

What is the expected behavior?

The out put of "null" should consider different situations.

What went wrong?

The out put of "null" is always "0" since node.js implement.

Link to a viewer

No response

Additional context

During PDF processing, directly converting null values to 0 might not always be appropriate. In some cases, a null can represent missing or undefined data rather than an actual numeric value. Automatically treating it as 0 could unintentionally alter the meaning of the data, potentially leading to incorrect interpretations or downstream issues.

It might be safer to preserve null as-is, or to handle it explicitly based on context — for example, distinguishing between truly "zero" values and "unknown/missing" values. This would help maintain data integrity and avoid masking important information.

Just a suggestion to consider: handling null values more carefully depending on the specific use case could make the system more robust.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions