Improve layout on large screens and with large font sizes

[permezel]

When I view an org file on an iPad, the contents appeared to be right justified. When adjusting the file size, I now realise that it is just wasted space on both left an right sides. This is made apparent by increasing the font size until line wrap happens. There is no need to wrap the content. Don't waste my screen space!

Here is another reveal:

[amake]

I purposely limit the width of the document region because

• Orgro reflows text where appropriate, eliminating poor wrapping in many scenarios
• I find overly long lines to be hard to read. I would not want the document to span the full width of the screen in pretty much any case.

If there is a good middle ground then I'm open to making changes, but I'm not sure what that would be.

[permezel]

I agree that moving my eyeballs left-to-right all the time is annoying.  However, if I adjust the point size, I would expect the padding to be reduced before a line gets wrapped. When lines are wrapped, you lose vertical space as well.

Also, when rendering tables, if one adjusts the point size, say to make it visible from a distance, the table is truncated, not re-flowed.  I would prefer the table to not be re-flowed and not truncated.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, December 10th, 2021 at 14:20, Aaron Madlon-Kay @.***> wrote:

I purposely limit the width of the document region because

• Orgro reflows text where appropriate, eliminating poor wrapping in many scenarios
• I find overly long lines to be hard to read. I would not want the document to span the full width of the screen in pretty much any case.

If there is a good middle ground then I'm open to making changes, but I'm not sure what that would be.

—

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub, or unsubscribe.[https://github.com/notifications/beacon/AARU5FGGY7R5PLR4WEZHVNDUQF5YLA5CNFSM5JYF7HN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHMFW3DI.gif]

[permezel]

Here is the table truncation issue. Given the text size, and the available space, truncation does not seem warranted.

[amake]

Here is the table truncation issue. Given the text size, and the available space, truncation does not seem warranted.

Thank you for the concrete example.

You may not be aware, but you can scroll the table horizontally to see the rest of it.

I made the choice to let tables expand to their natural width because otherwise very wide tables become unreadable: each column is squeezed to become extremely narrow.

I imagine the ideal situation would be:

• Tables that are narrower than the viewport should be their natural width
• Tables that are only a bit wider than the viewport should be snapped to the viewport width
• Tables that are much wider than the viewport should be truncated with horizontal scrolling

It's not clear to me that there is a clean way to implement this in Flutter, as it seems that multiple layout passes would be required: one to measure the natural width, and another to re-layout with the width resulting from the above rubric.

[amake]

I would prefer the table to not be re-flowed and not truncated.

This is untenable for very wide tables, per above.

However, if I adjust the point size, I would expect the padding to be reduced before a line gets wrapped.

The maximum width of the viewport is currently hard coded by screen size. Maybe I should make it vary with the point size as well, though I'm not sure that would give you the effect you're looking for.

[amake]

I am narrowing the scope of this ticket to the viewport width issue, and calling the table width snapping out of scope. Feel free to open a new issue for the table stuff.

[amake]

I spent hours looking into the table snapping thing, and I found that there seems to be no good way to squeeze a table that is intrinsically too wide for the viewport into a narrower space. The only table column sizing strategy that takes the content width into account, IntrinsicColumnWidth, will result in a table that does not tolerate a width less than its intrinsic width. Any other strategy will result in poor column apportionment.

Flutter just doesn't easily accommodate this, so I'm going to let it go for the time being.

[permezel]

The issue does not pertain solely to table display. Consider PDF document readers. You can have them display the entire page in the viewport: typically I find not useful: big bands on either side of the page -- wasted screen space. Alternately, I can scale the page width up to and including the screen width. Much more useful (so long as the PDF is not 2col text mode, but still better than the single page at small point size).

At minimum, please consider allowing me to 'full width' the display as well as adjust the font size.

[amake]

In 1.24.0 the document's maximum width is 72 em, as measured by the M character in the chosen font family and font size.

I'm not convinced about other issues because the comparison with PDF is not apt: PDF has fixed layout and cannot be reflowed (or at least is non-trivial to reflow) whereas Org documents are rendered fluidly already.

If you can formulate a compelling improvement with a coherent spec then I will consider it; please open a new issue for it.

[amake]

After seeing that some apps in the wild (e.g. Notion) do offer to toggle between full-width and restricted width, I am adding a similar option in v1.26.0. Look for it on the beta test channels soon:

• iOS
• Android