From: <tomas@tuxteam.de>
To: emacs-orgmode@gnu.org
Subject: Re: format/fill of text in a cell in tables
Date: Fri, 17 Dec 2021 09:23:45 +0100 [thread overview]
Message-ID: <YbxJEbxRx1DwrhLT@tuxteam.de> (raw)
In-Reply-To: <87mtl0b1u2.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3934 bytes --]
On Fri, Dec 17, 2021 at 08:51:59AM +1100, Tim Cross wrote:
[on flowing text whithin table cells]
> I agree. This is actually a much harder problem to solve than it may
> appear on the surface [...]
If you want to get completely dizzy, watch the recurrent threads about
proportional fonts in emacs-user or emacs devel :-)
That's when things start getting interesting.
> 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.
Very interesting points you make. I'd like to add a couple or two ;-)
* static vs dynamic, user vs master
An admirer of Knuth myself, I tend to relativise his position: he's a
book writer in the classical sense. Lots of things happen at "compile
time", you (the reader) get to watch (in awe) the process's results.
Tables have an advantage if your approach is an explorative one, i.e. if
the process is part of the result. I don't think they are as successful
as they are for no reason (SQL, or R's data frames are about tables, after
all, so it's not only Excel). If you want your reader to take part in
the exploration process, a table might just be right.
The cell lines is again in the same pattern: once the layout is fixed,
you can tweak your appearance so you can drop the lines. The result is
astounding, but only if you know your trade damn well. Knuth does. If
things are still in flow, or if you aren't a Grandmaster, perhaps lines
do help [1]. Now sometimes, this "in flow" is part of what you want to
convey, so...
* acculturation & perception
Very interesting point you make about "project managers". This reminds
me that there's not that One Perception Ruleset. People tend to justify
nearly anything with anything (remember those arguing with grey levels
and contrast to prove that serif fonts are more readable? Or was it the
other way around?). To the project managers, tables are probably the
most readable, because they read them all the time. Especially if they
are made with Microsoft (that's the basis of the power of those corps,
after all). Human perception seems so adaptable that it's nearly scary.
So it is all part of a giant feedback loop. Difficult to spot some
bedrock in this mess. Perception is culture is perception.
The point you make about assistive technologies is hugely important. I
haven't much experience with blind people myself, but I'm convinced that
their perception of dimensionality (2D, 2D vs 3D) could be quite
different from that of sighted people. Is a table an advantage or a
disadvantage then? Does it depend on the strategic path they have
chosen? Do some feel better at 3D? 5D? [2]
* WYS ain't WYG
Lastly, Org ain't WYSIWYG (well, duh). But such things as flowed cells
are measuring it up to one, up to a point (although, at some point, I
admit to having yearned for some). A strength is a weakness is a
strength. I think it is the nature of Org to live with such conflicts.
It's an interesting place, where it lives :-)
Cheers
[1] You better go with your camera's defaults to take an everyday photo.
If you're planning that astounding grainy B&W portrait, you're in for
some training.
[2] I had once a prof in functional analysis: the way he drew his things
on the blackboard gave us the impression that he really was /seeing/
those infinite-dimensional vector spaces he constantly talked about.
Scary :)
--
tomás
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2021-12-17 8:24 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
2021-12-17 8:23 ` tomas [this message]
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=YbxJEbxRx1DwrhLT@tuxteam.de \
--to=tomas@tuxteam.de \
--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).