Follow-up to #158 / PR #501. While investigating that position bug,
found a second, separate one in the same area: PartText::setFont()
never updated real_font_size_, so it stayed frozen at whatever size the
item was constructed with.
That field isn't cosmetic - it's live data two other operations depend
on:
- startUserTransformation()/handleUserTransformation() use it as the
base size when scaling the font as the user drags a resize handle.
With it stale, dragging a handle after changing the size via the
toolbar (or loading a file with a non-default size) scales from the
wrong starting point - the resulting size has nothing to do with
what's visibly on screen.
- flip() reads it directly to compute the repositioning offset, so a
stale value also mis-positions the item on flip.
Fix: update real_font_size_ inside setFont(), the same place PR #501
already re-runs adjustItemPosition() for the same reason (font changed,
keep everything that depends on it in sync). fromXml() already routes
both its "size" and "font" attribute branches through setFont(), so
loaded elements pick this up for free.
Verified with a temporary instrumented build: typed a size into the
element editor's font-size field three times (9 -> 4 -> 48). Each
setFont() call's "before" value exactly matched the previous call's
"after" value, confirming real_font_size_ now tracks every change
instead of freezing at its construction-time value (9). Instrumentation
removed before committing.
ispyisail
3077527601