[TheeCoderAhmed]

What kind of change does this PR introduce?

Bug fix. Fixes #1458

With align: 'justify' and a negative wordSpacing, justified lines run past the width.

LineWrapper counts the negative spacing when it decides what fits, so a line can hold more words than it would at normal spacing. _fragment then works out the justify spacing for that line, gets a negative number, and clamps it to 0 with Math.max(0, ...). The line is drawn with normal gaps and comes out wider than width.

The clamp now goes down to the negative wordSpacing the caller asked for, so those gaps can shrink. For zero or positive wordSpacing the lower bound is still 0, so nothing changes there.

In the new test, three aaaa words at 12pt in a width of 85 are 86.736 wide with normal gaps. Before the fix the line is drawn as [<616161612061616161206161616120> 0] TJ, with no adjustment. After it the gaps are 2.468 wide.

Checklist:

• Unit Tests
• Documentation N/A
• Update CHANGELOG.md
• Ready to be merged

What I ran:

• tests/unit/text.spec.js: the new test failed before the fix and passes after it.
• vitest --testTimeout 8000 run --exclude "tests/tools/**" (the yarn test command, unit and visual): 654 passed.
• eslint and prettier --check on the two changed code files.

I did not open a generated PDF in a viewer. I checked the TJ output and the tests only, and I did not run the sample from the issue, which needs the Poppins font.

[blikblum]

Not sure a negative wordSpacing makes sense

[TheeCoderAhmed]

It works today and the line wrapper already uses it, so I fixed the overflow. If you don't want to support negative values, I can close this.

[blikblum]

I realized that it works although the docs do not make clear it should work