This brings it down from around 20 seconds to less than a second,
for moderately sized documents (i.e. default size).
For larger documents, it can still be slow.
It's still O(n^2) complexity, but more specifically, it's
(n^2 - n) / 2 iterations instead of n^2.
I don't know much about the performance of `enumerate()` or slicing.
It handles the pathological character grid test case SVG I devised,
as well as loading the SVG as saved by the app.
It's a little weird that I managed to get the pathological case working
before the simple rigid grid, but it was what I was shooting for,
and the main problem with the rigid grid was the spanned rects,
which I didn't think of when making the test case SVG.
It does have one problem left; characters that are wider than a cell,
when saved as SVG, take up two cells, but in my SVG loading code,
they're just placed in one cell, so, when saving and loading,
it shifts content to the right of the wide character rightwards,
expanding the region of the background from the wide character's cell.
But it converges now.
It turns out the background rects can span multiple cells, so I have to
pivot strategy here.
Instead of removing any outliers, remove any containers, i.e. rects that
visually (not structurally) contain other rects.
This doesn't yet fill in multiple cells when a rect is spanned.
- DRY: Make decode_based_on_file_extension use format_from_extension.
- If you try to load .html, .htm, .svg, (or ._rich_console_markup) file,
show an error instead of loading as text. The text would be much
larger than a document you saved in this format, and it wouldn't give
you what you expect, unless you're wanting to load an arbitrary text
file for viewing, and for some reason choose this program to do it.
