Exercise 3: Reproducing the Overflow and Identifying the Exact Variable — Possible Solution
====================================================================

THE TEST
------------------------------
    words = "The quick brown fox jumps over the lazy dog".split()
    naive_lines = break_into_lines_naive(words, 100)
    [real_rendered_width(line) for line in naive_lines]

RESULT
------------------------------
    naive_lines -> [['The','quick'], ['brown','fox'], ['jumps','over','the'], ['lazy','dog']]
    real rendered widths -> [72, 72, 112, 64]

Exactly ONE line overflows: ['jumps', 'over', 'the'], at 112px against
a 100px budget -- a 12px overflow. The other three lines (72, 72, 64)
all genuinely fit.

THE EXACT VARIABLE THAT NEVER GETS SPACE-ADJUSTED
------------------------------
In break_into_lines_naive, the accumulator is `current_width`, updated
in exactly one place:

    else:
        current_line.append(word)
        current_width += w          # <- w is the WORD's width alone

`w` here is `measure_word(word)` -- purely the word's own character
count times CHAR_WIDTH_PX. Nothing in this line, or anywhere else in
the naive function, ever adds SPACE_WIDTH_PX to current_width. So
current_width, throughout the naive function's own execution, always
equals the sum of word widths only -- never the true rendered width a
real line with those words would actually occupy once real spaces are
drawn between them.

WHERE THE FIXED VERSION ADDS IT INSTEAD
------------------------------
break_into_lines (the fixed version) computes a separate `extra`
variable BEFORE deciding whether to wrap:

    extra = w if not current_line else (w + SPACE_WIDTH_PX)
    ...
    else:
        current_line.append(word)
        current_width += extra      # <- extra, not w

`extra` is exactly `w` when the word would be the FIRST on a line (no
space needed before it), but `w + SPACE_WIDTH_PX` for every subsequent
word on that same line, since a real space genuinely has to appear
before it once it sits next to the previous word. Critically, this
`extra` value is also what gets compared against available_width in
the overflow check itself (`current_width + extra > available_width`)
-- so the space cost is accounted for BEFORE the decision to wrap is
made, not merely added afterward for bookkeeping. The naive version's
overflow check (`current_width + w > available_width`) uses the
un-adjusted `w`, which is exactly why it can accept a word that, once
its own leading space is included, actually doesn't fit.

WHY THIS WORKS AS AN ANSWER
------------------------------
Both functions share an identical overall structure -- same loop,
same two-branch if/else, same list-of-lines accumulation -- differing
in exactly one substitution: `w` in the naive overflow check and
accumulator, versus `extra` (which conditionally includes
SPACE_WIDTH_PX) in the fixed version. That single substitution is
sufficient on its own to change the outcome for the real sentence used
throughout this chapter, confirming the bug was never about the
overall algorithm's shape -- only about what quantity it was
comparing against the available width.