emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: format/fill of text in a cell in tables
Date: Fri, 17 Dec 2021 08:51:59 +1100	[thread overview]
Message-ID: <87mtl0b1u2.fsf@gmail.com> (raw)
In-Reply-To: <874k78evcr.fsf@localhost>


Ihor Radchenko <yantar92@gmail.com> writes:

> George Michaelson <ggm@pobox.com> writes:
>
>> Thank you for the continuing support for Org mode. I really appreciate
>> the work done.
>>
>> I would love to understand why there is no built-in 'fill/wrap'
>> function for text in a cell, inside an org mode table.
>>
>> Given how this is a layout mechanism, and heads to M-x ox-<exportform>
>> outcomes, it would be useful to recognize the output is often table
>> edit states which do respect fill/wrap/center
>
> AFAIK, mostly technical difficulty. Emacs does not natively distinguish
> individual table cells, so we would need to emulate cell editing if it
> spans over multiple lines.
>
> Patches are welcome!
>

I agree. This is actually a much harder problem to solve than it may
appear on the surface. There have been a number of proposals regarding
how to do this over the years, but unfortunately, they have all had
significant drawbacks or limitations. One of which is that formatting
tables with multiple lines in LaTeX is actually a bit tricky (probably
the only exporter where it is relatively straight-forward is HTML). This
means you actually have two broad problems - handling cell wrapping in
the org buffers and handling it cleanly in the different exporters. 

In addition to the problem of defining some mechanism to treat each
table cell as if it was it's own 'minibuffer' (in TeX, you sometimes see
the 'minipage' environment used in this context), you also have to
define some mechanism to describe the relationship between the cells in
order to handle things like centring and justification. screen/page
width etc. To further complicate matters, you also have to consider what
this would mean for org's spreadsheet like capabilities when applied to
tables with cells wrapped over multiple lines. 

If you have lots of cells needing wrapping, the table is perhaps not the
right layout mechanism to use. While it may seem like a convenient way
to present content, often it isn't a great way to consume it. Donald
Knuth wrote a bit about why tables with multiple cell lines were a poor
choice. After years of dealing with project managers who too often use
Excel to record, present and share data, I tend to agree with his views.
I'm also old enough to remember when the table was the 'goto' solution
for managing layout in HTML files and what a mess that became.

While tables are great when you want to show 2-dimensional
relationships, for other situations, alternatives like definition lists,
nested lists and breaking the content up into subsections are often a
good alternative. It could be argued that not supporting table wrapping
is a positive aspect as it makes the author consider alternative layout
approaches which may actually improve readability of the content.

Finally, there is also an accessibility issue with multiple line tables.
For users who rely on assistive technology to consume content,
presenting information in a meaningful manner which is easy to navigate
and can represent larger 'chunks' of information with appropriate
indicators for the relationships between the cells is challenging.

As an aside, I sometimes find it useful when thinking about how to
layout information, how a typical user will consume it. We tend prefer
layouts with infinite length (pages), but with set width. Scrolling
up/down is convenient. Scrolling left/right is not. While larger screens
means we have more width to work with when reading on the screen, this
does not map well to printed pages as that 'width' has not changed -
best we can do is switch to 'landscape' rather than portrait mode. The
other problem with width is in variability - many people have wide
screens on desktops, but narrow screens on mobile devices. We can see
how quickly this becomes complex when we consider all the challenges we
have had with respect to being able to render web content on different
devices with varying screen sizes. Much of the complexity of CSS is
related to column layout and screen sizes. 


  reply	other threads:[~2021-12-16 22:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16  5:16 format/fill of text in a cell in tables George Michaelson
2021-12-16  9:45 ` Ihor Radchenko
2021-12-16 21:51   ` Tim Cross [this message]
2021-12-17  8:23     ` tomas
2021-12-17 12:11       ` Tim Cross
2021-12-17 18:46         ` tomas
2021-12-17 21:25           ` Juan Manuel Macías
2021-12-18  7:27     ` Uwe Brauer
2021-12-18 11:09       ` Juan Manuel Macías

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtl0b1u2.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).