Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: news@zzo38computer.org.invalid
Newsgroups: comp.infosystems.gemini
Subject: Re: Tables in Gemini
Date: Tue, 30 Jul 2024 10:50:50 -0700
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <1721415955.bystand@zzo38computer.org>
References: <v7e2j2$31q1g$1@dont-email.me>
MIME-Version: 1.0
Injection-Date: Tue, 30 Jul 2024 19:46:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2e411b970b85ab7345acc5cdad2bc312";
	logging-data="1204989"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18n9CzGJO0zA4AsJZorYuPD"
User-Agent: bystand/1.3.0pre1
Cancel-Lock: sha1:m49uzHpvraTsH+bZ0BK18VMWxQc=
Bytes: 3166

Namno <wed3009@yandex.ru> wrote:
> Greetings. I think that gemtext would benefit from inclusion of tables 
> that are not ad-hoc constructs of pseudographics. I have written a blog 
> post (gemini://namno.duckdns.org/blog/2024-06-09.gmi) on how I would like 
> tables to be implemented in gemini, but I think it would be great if other 
> people gave some critique on my reasoning and markup.

There are uses of data tables. However, I dislike this format, and I will
make my comments about it.

How are tables identified? By the heading of a preformatted block (although
you do not identify what is needed in this heading)? Then it would be
possible to display even if a client software does not implement tables,
although still there are some difficulty of doing this too.

The difficulty of display can include tables not lined up properly; even
this document has some examples of this.

Furthermore, use of Unicode will make it less likely to line up properly,
due to the use of fonts and due to ambiguous widths; Gemini does not
require the use of Unicode although non-Unicode text is less likely to be
supported (and some programs will just convert them to Unicode anyways,
which results in the same problem of fonts and ambiguous widths if you are
not careful) as well as requiring a single character encoding for the
entire file.

The quotation can also result in the display being not very good.

Data types and alignment are also not considered. This would mean that the
user must manually enter data types if they wish to sort or filter it (or
convert it to a scatter plot or pie chart or other graphics). (CSV and HTML
also do not specify data types, and I would have wanted to avoid to make
the same mistake as before.)

> This too complex ... I disagree. It is somewhat complex, but I don't
> think that it is really that complex.

I think it is somewhat too complex.

> This is unnecessary ... tables are good at laying out regular data, which
> I think is a useful thing

I agree that laying out regular data is a useful thing, but I think this
is not the best way to do it. I think linking to a separate CSV file would
do it (although CSV lacks data types and some of these other features, but
it is simpler to get it to work).

-- 
Don't laugh at the moon when it is day time in France.