#4501 split functions for `clippy::cognitive_complexity` and was meant to change no behaviour. A post-merge review of the whole diff found four places where it did. This PR restores the old behaviour in each.
- **Layout (`crates/layout/src/pass.rs`).** From section 2 on, headers, footers and footnote separators were measured under the previous section's document grid, with its SECTION/SECTIONPAGES values. Before #4501 the grid was reset first. With a docGrid line pitch in section 1 (common in CJK documents), section 2's body top moved and pages could break differently. The order is now:
1. `begin_section_state`: reset the grid, set the fields and separators.
2. `section_tops`: measure the header and footer room.
3. `apply_section_grid`: switch to the section's own grid.
New regression test `a_sections_header_is_measured_without_the_previous_sections_grid`. Without the fix, section 2's body top is 265.6 pt; with it, 226.9 pt, the same as with no grid.
- **ODT (`crates/formats/src/odt/styles.rs`).** A later paragraph default-style with no font, or a mono font, wiped the default font. It is now kept, as before #4501. Covered by a test.
- **Canvas (`crates/ui-egui/src/canvas/input.rs`).** A press that was handled showed the hover-link tooltip for one frame, which the old early `return` had skipped. This covers Ctrl+click on a link, switching to the header or footer, entering an equation, and a miss. `handle_primary_press` now returns `bool`. No test.
- **Czech suggestions (`crates/proof/src/cs/suggest.rs`).** The one-letter edits are bounded by the word's letter count as typed again. That count is clamped to the lowercased length so indexing can't go out of range. #4501 had bounded them by the lowercased length, which differs for e.g. `İ`.
`cargo xtask ci` passes locally (all 8 steps, 4606 tests).
<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
<!-- coderabbit-ai-generated:v1 -->
## Summary by CodeRabbit
* **Bug Fixes**
* Default document fonts remain available when a later paragraph style does not specify a usable font, and a later monospaced default does not replace an earlier proportional font.
* Headers, footers, and note separators use the layout settings and section values of their own section, helping prevent content from overlapping.
* Link hover tooltips are suppressed during canvas-handled clicks and return when the pointer hovers over the link after the press is released.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
* #5124: the window moves by its title bar behind a modal dialog
On macOS WordCraft draws its own title bar, and since modal dialogs
(#3859, #4076) the dialog's backdrop covers it, so the window couldn't be
dragged while a dialog was open. Word for Mac lets you drag the document
window by its title bar behind its Font dialog (and beeps on the click).
- The title bar (and the Backstage's top band on macOS) notes the part
that drags the window each frame. When the modal backdrop's drag starts
there, it moves the window; the press still shakes the dialog, as Word
beeps.
- Only the backdrop's own drag counts, so a drag on the dialog, its tabs
or its popups, where it reaches over the title bar, moves only the
dialog.
Tested by the developer on a Mac.
Fixes#5124.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5124: only the macOS title bar moves the window behind a dialog
Review (CodeRabbit):
- Elsewhere the system's title bar already moves the window; WordCraft's
own bar under it now doesn't, behind a modal dialog either, so nothing
changes on Linux and Windows.
- A drag from just inside the dialog's edge, where it reaches over the
title bar, moves only the dialog, as the nudge already tells it apart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5124: the window moves by its title bar behind Colors too; modal_open tests
Colors is an egui Modal, not a window with the backdrop of block_behind, so
a drag on the macOS title bar did nothing behind it. It now shares the check
with the other modal windows.
The new tests pin modal_open with nothing open, a modeless dialog, a modal
dialog, the file browser and Colors, and that the title bar moves the window
in each of those while the dialog stays open.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5124: the modal drag test covers the top of File's side menu
On macOS File's side menu covers the title bar, and its top band moves the
window. The test now drags there too, so losing the band's note_title_drag
call fails it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
In a section of several text columns the horizontal ruler was one white
strip from margin to margin. The space between each two columns is now
shaded like the margins, so the ruler shows where each column ends and
the next starts.
The edges of a space can be dragged, through layout.columns, one undo
step per drag, to change the spacing. Equal columns stay equal, so every
space changes with it, as in Word for Mac. Between unequal columns only
the column at that edge and the space change. As in Word for Mac, the
middle of a space has no grip of its own. Columns stay at least a
quarter inch wide and spaces 0-300 pt, as the Columns dialog allows,
snapped to 1/16 inch. Right-to-left sections are read from the right
edge.
Outside the main text, outside Print Layout and in a table the ruler is
unchanged. A selection across sections shows no spaces, since a drag
would set the columns of each section it touches; nor does a page the
caret isn't on. Columns from a file that the command wouldn't take back
(over 12, a column under a quarter inch, a space over 300 pt, wider than
the text) are shaded but not dragged. A tab stop's marker keeps its own
drag where it sits on an edge. The indent markers still follow the page
rather than the caret's column; that is #2196 (PR #2215).
Fixes#5197.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
* #5267: a linked picture shows and follows its link; DOCX keeps it on the drawing
A link put on a picture from its context menu was stored, but nothing showed
it: hovering the picture gave no tip, and Ctrl+click picked the picture for a
copy instead of following the link. Now the hover tip and Ctrl/Cmd+click work
on a linked picture, shape or text box, in line or floating, as on linked text.
DOCX: Word keeps a picture's hyperlink on the drawing (wp:docPr/a:hlinkClick,
ECMA-376 Part 1 20.4.2.5). It is now read (a w:hyperlink around the run wins)
and written beside the w:hyperlink, sharing one relationship. A link to a place
in the document stays the w:hyperlink w:anchor only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: ink and Office 2016 charts take their drawing's link; Ctrl+click over text on a Behind Text picture stays a text click
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: rustfmt
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: a chart or ink takes the link of the choice it was read from; Ctrl/⌘+click in the docs
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: the decoy choice in the chart-link fixture needs a namespace no reader knows
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: inside a linked text box, hover and Ctrl/⌘+click take the box's link
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5267: the picture-link test sets the image's fx after merging main
Main gave InlineObject::Image picture effects (fx); the round-trip test this PR adds built
an image without them and no longer compiled.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
* #5105: font menu entries are drawn from a few shared textures
Each font menu entry was a texture of its own, created and freed as the list
was browsed: on Windows (DirectX 12) the entries showed other textures' memory,
black strips in light mode, white or red ones in dark mode, as the Equation
tab's pictures did before #1002. They now share an atlas written in place, the
one the equation pictures use (MathAtlas, now PreviewAtlas).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5105: font menu entries are drawn again in every window once fonts change
The font atlas remembers the font database generation its entries were drawn
with and starts over when it changes, so another window's entries and a removed
font's entry (Recently Used Fonts) don't keep an old face.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5105: the atlas test doesn't compare with the shared font generation
Review: tests running alongside add and remove fonts, so the database's
generation may change between the draw and the assertion.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
* #5398: the title bar's Search box takes the typing in place, its results dropping down under it
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5398: Search in Focus opens the dialog, and Search whose box is gone doesn't keep Escape
Review: Focus hides the title bar's Search box, so Alt+Q on the frame Focus comes on opened
Search in a box that wasn't drawn, and that hidden Search kept Escape from leaving Focus.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5398: Search takes the keys from its first frame; Enter on a result isn't also the new dialog's OK
Review fixes:
- The Search box is focused before it reads the frame's input, so keys typed on the frame
right after Alt+Q go into it (they were lost). Alt+Q's own text is still swallowed: Alt is
read from the shortcut's key event too.
- Enter that runs a result is used up, so a dialog the result opens (Word Count) doesn't take
the same Enter as its OK and close at once.
- The Focus test opens Search with the command Alt+Q runs, so it also runs on macOS, where
Option+Q types a character (the test failed on the macOS runner).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #5398: Tab moves from the Search box to its results, and Enter runs the focused one
Review: the box took the focus back every frame, so Tab couldn't reach a result, and Enter
always ran the first hit. The box now takes the focus back unless it is on one of its results
(read from last frame's rects, so the page taking it is still undone), and runs the first hit on
Enter only while it has the focus; a focused result takes Enter or Space itself. Either way the
Enter that ran a result is used up, so the dialog it opens doesn't take it as its OK.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
* #4685: Shading on text selected inside a paragraph shades the text
Home › Paragraph › Shading always set the paragraph's shading. Word shades the selected
text when the selection is inside one paragraph (w:shd in the run properties), and the
paragraph for a caret or a whole paragraph. So an orange text shading from a .docx (which
Text Highlight Color › No Color leaves, in Word too) couldn't be taken off from the ribbon.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #4685: review — a paragraph's whole text is text unless it's the last; a selected object isn't text
A selection with a paragraph's mark ends at the next paragraph's start, so 0..len of a
paragraph that isn't the last of its story, cell or box is text only and No Color clears its
shading. A selected text box or picture (its object character) shades the paragraph as before,
instead of every line of the box.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #4685: review — a selected field is text; Apply to: Paragraph shades the paragraph
Only a selected picture, shape or text box (`object_selection`) keeps Shading on the
paragraph; a field's object character is text, so No Color clears its shading. The Borders
and Shading dialog's Apply to: Paragraph passes `paragraph: true`, so it shades the
paragraphs even for text selected inside one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #4685: ui-parity wording (CodeRabbit): text shading applies to part of one paragraph
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #4685: ui-parity wording (CodeRabbit): removes text shading imported from a file
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* UI parity: status line after merging main
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #4685: a test of Shading in a cell's last paragraph
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
The document used egui's floating scroll bars, invisible until the pointer
reached the right edge. The canvas now draws solid bars in the 14 px strip
it already left for them, with a grey thumb that stands out from its track
in light and dark themes and darkens under the pointer. Read mode still has
no bars.
Co-authored-by: Martin Ball <martin.ball@ucscaregroup.co.uk>
* M14: keep Page Setup margin and grid editors within their width (#5650)
Use the pinned egui DragValue clipping option for four margins and both grid counts. Canonical actual WordApp regression and 12 Page Setup controls pass; strict all-target UI Clippy and scoped rustfmt pass.
* M14: keep Page Setup paper-size editors within their width (#5650)
Apply the same bounded text editing to paper width and height while preserving their existing limits, units and speed. Actual Page Setup regression and existing controls pass.
* M14: regress Page Setup paste, blur and reopen widths (#5650)
Exercise all eight numeric fields through the actual WordApp harness. Baseline Bottom paste reproduced width growth from 354 to 2973 pt; the fixed canonical 12-test Page Setup suite passes. Private rendering hooks are excluded.
* M14: record bounded Page Setup number editors (#5650)
Add the focused UI fix to the progress and revision logs and status line. Readiness estimates remain unchanged.
* M14: note the focused Page Setup paste fix in gaps (#5650)
Record bounded numeric editing in the gap note, status and revision history; no ranked gap or readiness estimate changes.
* M14: document bounded Page Setup numeric input (#5650)
Update the UI parity note, status and revision history for long input scrolling inside the existing fields. Readiness estimates remain unchanged.
* M14: bound unfocused Page Setup margin values (#5650)
Keep the unfocused DragValue inside an allocated, clipped field without changing numeric parsing, units, speed or accepted values. Regress a finite long paste followed by Tab in all four margins. The actual baseline grew from 354 to 458.53125 pt after Tab; the canonical 13 Page Setup tests and scoped formatting checks pass, and the inspected fixed renders stay 354 pt. Hosted validation remains pending in draft PR #5696.
* M14: record unfocused Page Setup bounds (#5650)
Update the gap and UI parity notes for the accepted-value paste followed by Tab regression. Retain the existing progress history, value ranges and readiness estimates.
* M14: log the Page Setup blur regression (#5650)
Record the bounded unfocused margin display and accepted-value regression. Preserve every upstream progress entry and the previous validation history.
* M14: regress RTL margin re-entry (#5650)
Cover re-editing the visible portion of a wide blurred margin in the real Page Setup dialog under an asserted RTL fixture. Raw pointer events restore editing and accept a normal value; the existing thirteen tests remain unchanged. Fourteen Page Setup tests, package formatting, strict all-target UI Clippy and source-integrity checks passed. No production or dependency changes.
* Mini toolbar: hovering a formatting button previews it on the selection (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Keep mini toolbar stable during alignment preview
* Track live mini toolbar anchor during preview
* Mini toolbar: hovering a font, size, highlight or font colour previews it (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Mini toolbar preview: the page holds its scroll position (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Mini toolbar: hovering the highlight and font colour buttons previews their colour (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Mini toolbar: the font list and colour menus mark the choice in effect (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Skip hover previews in context toolbar
* Pass preview mode in toolbar test
* Font list: a picked family keeps its place until the list next opens (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Font and size lists close when an entry is picked (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Mini toolbar: a clicked button holds its preview until the pointer leaves (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Mini toolbar: a button already on does not preview (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Alignment buttons follow the paragraph a selection covers; a toggle previews its undo on return (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
* Font list: a recent family is marked as chosen in Recently Used Fonts only (#4664)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-authored-by: Fluorine <joseph.anglada92@gmail.com>
Codex
batistalucasv
FredApps
Martin Ball
vangel76andClaude Opus 5.5
ReesandMartin Ball
Zinadin ZidanandMartin Ball
Mex
