Edited 12_path_finding.asciidoc with Atlas code editor

12_path_finding.asciidoc

@@ -93,6 +93,7 @@ Balances are not announced in channel updates for two reasons: privacy and scala
 </ul>
 ++++
 
+[role="pagebreak-before"]
 or as a range:
 
 ++++
@@ -406,12 +407,12 @@ To read more about the optimization problem known as minimum-cost flows involved
 
 In our example, Selena's node will attempt to split the 1M satoshi payment into 2 parts with 600k and 400k satoshi, respectively, and send them on 2 different paths. This is shown in <<mpp_paths>>.
 
+Because the S->X channel can now be utilized, and (luckily for Selena), the B->R channel has sufficient liquidity for 600k satoshis, the 2 parts are successful along paths that were previously not possible.(((range="endofrange", startref="ix_12_path_finding-asciidoc13")))(((range="endofrange", startref="ix_12_path_finding-asciidoc12")))
+
 [[mpp_paths]]
 .Sending two parts of a multipart payment
 image::images/mtln_1209.png[]
 
-Because the S->X channel can now be utilized, and (luckily for Selena), the B->R channel has sufficient liquidity for 600k satoshis, the 2 parts are successful along paths that were previously not possible.(((range="endofrange", startref="ix_12_path_finding-asciidoc13")))(((range="endofrange", startref="ix_12_path_finding-asciidoc12")))
-
 ==== Trial and Error over Multiple "Rounds"
 
 ((("multipart payments (MPP)","trial-and error over multiple rounds")))((("payment delivery","trial-and error loop")))((("trial-and error loop")))Multipart payments lead to a somewhat modified trial-and-error loop for payment delivery. Because we are attempting multiple paths in each attempt, we have four possible outcomes: