Handle overflows in wrap_optimal_fit by divide-and-conquer
#259
Conversation
mgeisler
force-pushed
the
wrap-optimal-fit-checked
branch
from
72c39a4
to
10114ec
Compare
|
I still need to add a test or two for the new behavior regarding wrapping over-sized fragments. So far I've simply tested that the existing tests still work the same. |
mgeisler
force-pushed
the
wrap-optimal-fit-checked
branch
2 times, most recently
from
fc0e7a2
to
8971476
Compare
|
I've added two simple tests for the overflow behavior.
This is not perfect because I only back up like this in case the current slice resulted in more than two wrapped lines. This is to ensure progress in the wrapping, but it might have the bad side-effect of stitching the wrapped slices together in a bad way. In general, the above approach implicitly assumes that over-sized fragments are rare so that they occur multiple lines apart. If this is not the case, I don't think the output will be so nice since the over-sized fragments end up forcing a line-break. |
mgeisler
force-pushed
the
wrap-optimal-fit-checked
branch
from
8971476
to
d9ebda2
Compare
The `wrap_optimal_fit‘ algorithm computes the penalty for a gap as `gap * gap`. If a fragment has a size near `usize::max_value()` and if the line width is large, this computation can easily overflow. When this happened, we would simply crash. Now, we instead do the computations with checked arithmetic and detect the overflow. We then proceed to wrap the first half of the fragments by themselves. If this work, we then wrap the second half. This way, we might be able to wrap everything without overflow. Should there be a single fragment which causes the overflow by itself, this fragment is put on a line by itself. When wrapping part of the fragments, we might of course end up with a partial last line. To fix this, we pop the last line and re-wrap the fragments that were put onto this line. This helps remove some of the “seams” that would otherwise occur. However, this is not perfect if there are many over-sized fragments since they can still cause half-empty lines to appear in the output. Fixes #247.
mgeisler
force-pushed
the
wrap-optimal-fit-checked
branch
from
d9ebda2
to
2eb83f3
Compare
mgeisler
changed the title
wrap_optimal_fit by divide-and-conquer
mgeisler
force-pushed
the
master
branch
3 times, most recently
from
90541dd
to
e47928b
Compare
|
Superseded by #421 which simply makes |
The
wrap_optimal_fit algorithmcomputes the penalty for a gap asgap * gap. If a fragment has a size nearusize::max_value()and if the line width is small, this computation can easily overflow.When this happened, we would previously abort or unwind. Now, we instead do the computations with checked arithmetic and detect the overflow. We then proceed to wrap the half of the fragments by themselves. If this work, we then wrap the second half. This way, we might be able to wrap everything without overflow.
Should there be a single fragment which causes the overflow by itself, this fragment is put on a line by itself.
When wrapping part of the fragments, we might of course end up with a partial last line. To fix this, we simply pop this line and re-wrap the fragments that were put onto this line. This ensures no “seams” in the wrapping.
Fixes #247.