The typesetter was incorrectly measuring line width when expressions contained
superscripts or subscripts (e.g., b²). After rendering a superscript, the line
is split into multiple display segments, but the width checking code was only
measuring the current segment, not the total visual line width.
Key changes:
- Use currentPosition.x to track actual horizontal position across all segments
- Calculate visualLineWidth = currentPosition.x + currentSegmentWidth
- Pass remainingWidth (maxWidth - currentPosition.x) to findBestBreakPoint
- Apply fix to both interatom breaking and inline text breaking
This fixes truncation issues where content like "Δ=b²-4ac avec a=1..." was
being clipped instead of wrapped to a new line.
Before: Each segment checked in isolation → segments appeared to fit individually
but total visual width exceeded maxWidth → content truncated/clipped
After: Total visual width tracked correctly → line breaking triggered when
actual visual width exceeds maxWidth → content wraps properly
When rendering large operators (e.g., sum, integral) with scripts in text
mode, the operator glyph was incorrectly positioned after its subscripts
and superscripts instead of before them. This caused expressions like
\sum_{i=1}^{n} i = \frac{n(n+1)}{2} to render with the equals sign
appearing visually misplaced.
Root cause:
The line-breaking refactoring introduced double-positioning of large
operators. makeLargeOp() internally sets the operator position, advances
currentPosition.x, and adds script displays. However, the calling code
then overwrote the position and advanced currentPosition.x again, causing:
- Double-advancement leading to incorrect width calculations
- Scripts positioned before the operator instead of after
Solution:
Save and restore typesetter state before/after line break dimension checks,
then call makeLargeOp() once at the correct position after handling line
breaks and inter-element spacing.
