@@ -92,7 +92,13 @@ internal static void ApplyLineBreaking(CssBox blockBox)
             // fixes it without needing a special case in the main loop. Subsumes that single-line case
             // too - it is just the `orphans` violation that can never be waived (0 lines fitting is
             // always fewer than any orphans value of at least 1).
-            var firstRunMovedToFreshPage = firstRunLineCount < lines.Count && firstRunLineCount < orphans;
+            // A forced break (or any other placement) may already have put this run flush at a fresh
+            // page's own top - in which case its capacity IS a full page height already, and pushing it
+            // to yet ANOTHER fresh page cannot gain any more room (same content, same capacity, same
+            // unsatisfiable result), it would just leave the page it was actually placed on blank. Only
+            // worth doing when there is real room being left on the table by staying put.
+            var alreadyAtFreshPageTop = Math.Abs(lines[0].LineTop - container.PageTopOf(firstPageIndex)) < 0.01;
+            var firstRunMovedToFreshPage = !alreadyAtFreshPageTop && firstRunLineCount < lines.Count && firstRunLineCount < orphans;
             if (firstRunMovedToFreshPage)
             {
                 firstPageIndex++;
@@ -117,26 +123,93 @@ internal static void ApplyLineBreaking(CssBox blockBox)
                     breaks.RemoveAt(breaks.Count - 1);
                     i--;
                 }
+                else if (linesBefore > 0 && linesBefore < orphans && runStart == 0 && !firstRunMovedToFreshPage && !alreadyAtFreshPageTop)
+                {
+                    // Same violation as above, but there is no earlier run to merge into - runStart==0
+                    // IS the first run. The only fix here is exactly what the pre-loop check above already
+                    // does for the common case: push it whole to a fresh page - gated by the SAME
+                    // alreadyAtFreshPageTop condition that check uses, for the same reason: if this run is
+                    // already sitting at a fresh page's own top, it already got the full pageHeight
+                    // capacity and still could not fit `orphans` lines (the pre-loop check's own
+                    // firstRunLineCount<orphans, computed against that same capacity, agrees) - genuinely
+                    // unsatisfiable, not something a SECOND fresh page could help with either.
+                    firstRunMovedToFreshPage = true;
+                    firstPageIndex++;
+                    firstRunCapacity = pageHeight;
+                    i = 0; // restart the scan from line 1 under the widened capacity
+                }
                 else
                 {
                     breaks.Add(i);
                 }
             }
 
-            // Widows: the run after the LAST break must have at least `widows` lines - if not, merge
-            // break points backward (as many as needed) until it does, or until only one run is left, or
-            // until merging further would make the run taller than a page can hold - honoring widows by
-            // creating a run that can never fit isn't honoring it, it's trading one violation for a worse
-            // one, so this is where the relaxation gives up rather than forcing it (css-break-3 §4.3's
-            // own "some constraints can't always be satisfied" philosophy).
+            // Widows: the run after the LAST break must have at least `widows` lines - if not, first try
+            // shifting the break point EARLIER by as few lines as it takes (css-break-3 §5.4 asks for the
+            // minimum number of lines moved across the break, not for the whole preceding run to be
+            // absorbed) - as long as the shrinking earlier run still keeps at least `orphans` lines of its
+            // own. A shifted-but-still-separate run always lands at a fresh page's own top regardless of
+            // where exactly the break falls (phase 2 places every run but the first at
+            // PageTopOf(firstPageIndex + its own ordinal), which does not depend on how many lines it
+            // holds) - so its own capacity is always a full page height, never the tighter capacity a
+            // merge into run 0 might face.
+            //
+            // If no such shift satisfies widows without violating orphans on the earlier run, fall back to
+            // merging the whole earlier run away entirely (as many times as it takes, cascading further
+            // back across more than one earlier break when needed) - first against that run's own current
+            // capacity (a full page height, unless it is run 0, still sitting at whatever tighter room its
+            // natural position left it), and if that specific case (merging into run 0) does not fit
+            // there, against a full page height instead (mirroring firstRunMovedToFreshPage above: run 0
+            // pushed whole to a fresh page gains the same capacity boost a later run already has for free).
+            //
+            // Only when neither a shift nor a merge - at any capacity - can satisfy widows does this give
+            // up and leave the violation in place: honoring widows by creating a run that can never fit
+            // isn't honoring it, it's trading one violation for a worse one (css-break-3 §4.3's own "some
+            // constraints can't always be satisfied" philosophy).
             while (breaks.Count > 1 && lines.Count - breaks[breaks.Count - 1] < widows)
             {
-                var candidateStart = breaks[breaks.Count - 2];
-                var candidateCapacity = candidateStart == 0 ? firstRunCapacity : pageHeight;
-                if (lines[lines.Count - 1].LineBottom - lines[candidateStart].LineTop > candidateCapacity)
+                var prevRunStart = breaks[breaks.Count - 2];
+
+                var shifted = false;
+                for (var newBreak = breaks[breaks.Count - 1] - 1; newBreak > prevRunStart; newBreak--)
+                {
+                    if (newBreak - prevRunStart < orphans)
+                        break; // shifting further would strand the earlier run below its own orphans minimum
+
+                    if (lines.Count - newBreak < widows)
+                        continue; // this candidate still does not have enough lines after it
+
+                    if (lines[lines.Count - 1].LineBottom - lines[newBreak].LineTop > pageHeight)
+                        continue; // the (now larger) last run would not fit a fresh page either
+
+                    breaks[breaks.Count - 1] = newBreak;
+                    shifted = true;
+                    break;
+                }
+
+                if (shifted)
                     break;
 
-                breaks.RemoveAt(breaks.Count - 1);
+                var mergedHeight = lines[lines.Count - 1].LineBottom - lines[prevRunStart].LineTop;
+                if (mergedHeight <= (prevRunStart == 0 ? firstRunCapacity : pageHeight))
+                {
+                    breaks.RemoveAt(breaks.Count - 1);
+                    continue; // re-test widows against the now one-level-earlier run (cascades further back)
+                }
+
+                if (prevRunStart == 0 && !firstRunMovedToFreshPage && mergedHeight <= pageHeight)
+                {
+                    // Merging everything back into run 0 does not fit run 0's own natural (tighter) room,
+                    // but WOULD fit a full page - exactly the boost firstRunMovedToFreshPage already gives
+                    // the first run for orphans. Apply it here too and finish the merge.
+                    firstRunMovedToFreshPage = true;
+                    firstPageIndex++;
+                    firstRunCapacity = pageHeight;
+                    breaks.RemoveAt(breaks.Count - 1);
+                    continue;
+                }
+
+                break; // neither a shift nor any merge can satisfy widows - decline gracefully
             }
 
             // Phase 2: apply the decided breaks as cumulative shifts, in one forward pass. The first
 
@@ -74,15 +74,6 @@ private static CssBox FindById(CssBox root, string id) =>
     // is already at the top of a fresh page - moving it again (as if there were a whole page of content
     // above it) would blank the page the forced break named.
     [TestMethod]
-    [Ignore("Confirmed gap (this is the one case in this file where the cursor concept PeachPDF's own test "
-        + "targets really does have a counterpart bug here, just via a different mechanism):  "
-        + "InlineFragmentation.ApplyLineBreaking's firstRunMovedToFreshPage check "
-        + "('firstRunLineCount < lines.Count && firstRunLineCount < orphans') never asks whether "
-        + "lines[0] is already flush at a fresh page's own top before deciding to push the run forward - "
-        + "for an unsatisfiable orphans minimum (firstRunLineCount permanently 0 or otherwise < orphans), "
-        + "this fires unconditionally and moves the box one page further than the forced break already "
-        + "placed it, exactly like PeachPDF's stale-cursor bug: the page the break named (PageTopOf(1)) is "
-        + "left blank and the box lands on PageTopOf(2) instead. Confirmed by running this test unignored.")]
     public async Task AForcedBreak_LandsOnThePageItNames_EvenWhenTheBoxCannotMeetItsOrphansMinimum()
     {
         var html = "<div id='a' style='height:50px'>A</div>"
 
@@ -136,9 +136,24 @@ public async Task Orphans_IsInherited()
 
     private const double LineHeight = 20;
 
+    // A narrow width (each word alone easily exceeds half of it, so no two ever share a line) forces
+    // exactly one word per rendered line via natural wrapping - deliberately not <br>: this fork's <br>
+    // handling (DomParser.CorrectLineBreaksBlocks) only folds a <br> into a real forced-newline "\n" word
+    // when it is the LAST thing in its inline run; a <br> with more inline content after it is left as a
+    // literal box, which the parser's block-correction pass then splits into SEPARATE anonymous BLOCK
+    // siblings (one per <br>-delimited run), each holding exactly one line of its own - confirmed directly
+    // by inspecting the box tree (CssBox.Boxes came back as 7 children: 4 display:block text runs
+    // interleaved with 3 display:inline <br> boxes, and the <p> itself had zero LineBoxes of its own).
+    // InlineFragmentation.ApplyLineBreaking operates on a SINGLE box's own LineBoxes list, so a <br>-joined
+    // fixture never exercises its multi-line widows/orphans correction at all - every "line" is really an
+    // independent 1-line sibling block, which is a fundamentally different (and, for this feature, useless)
+    // shape than what these tests are meant to probe. A real multi-word-wrapped paragraph does not have
+    // this problem (confirmed empirically: no such splitting, and no spurious extra line box either - that
+    // only showed up at truly Ext width like 10px, an unrelated edge case avoided by staying well clear of
+    // it here).
     private static string Paragraph(int lineCount, string extraStyle = "") =>
-        "<p id='p' style='width:200px;line-height:" + LineHeight + "px;margin:0;padding:0;" + extraStyle + "'>"
-        + string.Join("<br>", Enumerable.Range(1, lineCount).Select(i => $"Line{i}"))
+        "<p id='p' style='width:50px;line-height:" + LineHeight + "px;margin:0;padding:0;" + extraStyle + "'>"
+        + string.Join(" ", Enumerable.Range(1, lineCount).Select(i => $"Line{i}"))
         + "</p>";
 
     /// <summary>How many of a paragraph's own lines fall on each side of a page boundary, at the given
@@ -165,15 +180,6 @@ private static string Paragraph(int lineCount, string extraStyle = "") =>
     // 4-line paragraph straddling with only 1 line naturally following the break (violating widows:2) must
     // have exactly one line pulled across, landing 2-before/2-after - not the whole box pushed on.
     [TestMethod]
-    [Ignore("Confirmed gap, traced by hand against InlineFragmentation.ApplyLineBreaking: its widows "
-        + "merge-back loop can only REMOVE a break entirely (fully merging two runs), never shift a break "
-        + "point earlier by fewer lines while keeping two runs, and never falls back to pushing the whole "
-        + "run to a FRESH page when an in-place merge does not fit the CURRENT page's remaining room. At "
-        + "several swept filler heights (e.g. 22px, 4 lines in a 100px page), phase 1 naturally breaks at a "
-        + "point that leaves fewer than widows:2 lines after the break; the merge-back then tries removing "
-        + "that break entirely, finds the WHOLE run does not fit in the page's remaining room, and gives up "
-        + "- leaving the violating split - rather than shifting the break by one line (which would fit) or "
-        + "pushing the whole run to a fresh page (which would also fit).")]
     public async Task Widows2_OnlyOneLineWouldFollowTheBreak_MovesOneLineRatherThanTheWholeBox()
     {
         var checkedAny = false;
@@ -192,8 +198,6 @@ public async Task Widows2_OnlyOneLineWouldFollowTheBreak_MovesOneLineRatherThanT
     }
 
     [TestMethod]
-    [Ignore("Same confirmed gap as Widows2_OnlyOneLineWouldFollowTheBreak_MovesOneLineRatherThanTheWholeBox "
-        + "- see that test's own remark.")]
     public async Task Widows3_MovesAsManyLinesAsItTakes()
     {
         var checkedAny = false;
@@ -213,8 +217,6 @@ public async Task Widows3_MovesAsManyLinesAsItTakes()
     // Where the two constraints meet, one has to give: honoring widows:4 on a 4-line paragraph would leave
     // none before the break, so the per-line correction gives up in favor of pushing the whole box.
     [TestMethod]
-    [Ignore("Same confirmed gap as Widows2_OnlyOneLineWouldFollowTheBreak_MovesOneLineRatherThanTheWholeBox "
-        + "- see that test's own remark.")]
     public async Task Widows4_CannotBeSatisfiedWithoutBreakingOrphans_PushesTheWholeBox()
     {
         var checkedAny = false;
@@ -237,14 +239,6 @@ public async Task Widows4_CannotBeSatisfiedWithoutBreakingOrphans_PushesTheWhole
     }
 
     [TestMethod]
-    [Ignore("Confirmed gap by running this test unignored: at several swept filler heights (e.g. 62px), the "
-        + "paragraph's first fragment keeps only 1 line before the break, fewer than orphans:2 requires. "
-        + "InlineFragmentation.ApplyLineBreaking's own phase-1 orphans back-off (breaks.RemoveAt + retry) "
-        + "only fires once at least one earlier break already exists (breaks.Count > 1, per that method's "
-        + "own comment on the condition), so a violation surfacing at the very FIRST break decision is never "
-        + "corrected there - only firstRunMovedToFreshPage's own narrower case (the paragraph's very first "
-        + "run) is, which is why the already-passing OrphansOnFirstRunTest.cs does not contradict this: its "
-        + "own fixture never lands in the specific narrow gap this one does.")]
     public async Task Orphans2_ParagraphNudgedWhenOnlyOneLineWouldPrecedeTheBreak()
     {
         var checkedAny = false;
@@ -309,8 +303,6 @@ public async Task TallParagraph_ExceedsOnePage_IsNotNudged()
     // be helped by moving it whole, but the break *before it* can fall earlier - with too few lines above
     // the boundary, orphans:2 must still push the whole thing to the next page rather than stranding one.
     [TestMethod]
-    [Ignore("Same confirmed gap as Orphans2_ParagraphNudgedWhenOnlyOneLineWouldPrecedeTheBreak - see that "
-        + "test's own remark.")]
     public async Task Orphans2_ParagraphTallerThanTheBand_BreaksBeforeItselfRatherThanStrandingOneLine()
     {
         var checkedAny = false;
@@ -408,12 +400,6 @@ public async Task Orphans2_HeadingAndParagraph_AreCorrectedOnceRatherThanWalking
     }
 
     [TestMethod]
-    [Ignore("Confirmed gap by running this test unignored: hits the same widows merge-back limitation as "
-        + "Widows2_OnlyOneLineWouldFollowTheBreak_MovesOneLineRatherThanTheWholeBox above (the merge-back can "
-        + "only remove a break entirely, never shift it earlier by fewer lines, nor fall back to pushing the "
-        + "whole run to a fresh page when the in-place merge doesn't fit) - this variant only adds that the "
-        + "paragraph's own natural top already lies past page 0, which does not change the underlying "
-        + "mechanism or its outcome.")]
     public async Task Widows2_ParagraphStartingOnSecondPage_StillCorrected()
     {
         var checkedAny = false;