A Gemini-style proposal

Gemini now expects the "* " tag for lists.
I propose a single "**" tag, which I call "highlighted", which can be used 
several times in each paragraph of text as a switch that was initially turned off.
Each client can interpret "highlighted" at will.
Now I throw this message into space. 🚀

Roberto Soccoli
Telegram me: @Roberto_Soccoli

I’d say no. The functionality of Gemini is pretty much done. People are of 
course free to write their own clients that do their own processing. But 
the standard is: if you need that, serve Markdown or HTML documents 
instead of extending Gemtext.

-- 
Typed on a tiny keyboard. Sorry for being terse.

> On 1 Nov 2021, at 12:04, Roberto Soccoli <roberto.vpt@protonmail.com> wrote:
> 
> 
> Gemini now expects the "* " tag for lists.
> I propose a single "**" tag, which I call "highlighted", which can be 
used several times in each paragraph of text as a switch that was initially turned off.
> Each client can interpret "highlighted" at will.
> Now I throw this message into space. 🚀
> 
> Roberto Soccoli
> Telegram me: @Roberto_Soccoli
>

On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
> I’d say no. The functionality of Gemini is pretty much done.

Also, that's not line-oriented.

> People are of course free to write their own clients that do their own
> processing. But the standard is: if you need that, serve Markdown or
> HTML documents instead of extending Gemtext.

Side note: I think it's best to serve PDFs instead of other markup
languages because everyone can view PDFs. Many people don't have a
markdown viewer/compiler installed, and serving HTML is, in my opinion,
overkill for Gemini.

-- 
DJ Chase
They, Them, Theirs

On Mon Nov 1, 2021 at 2:35 PM GMT, DJ Chase wrote:
> On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
> > I’d say no. The functionality of Gemini is pretty much done.
>
> Also, that's not line-oriented.
>
> > People are of course free to write their own clients that do their own
> > processing. But the standard is: if you need that, serve Markdown or
> > HTML documents instead of extending Gemtext.
>
> Side note: I think it's best to serve PDFs instead of other markup
> languages because everyone can view PDFs.

I'd say serving PDFs would be the grand overkill. PDFs have their own
purpose, built for print.

> Many people don't have a markdown viewer/compiler installed, and
> serving HTML is, in my opinion, overkill for Gemini.

Who's to say installing a Gemini client shouldn't come with a dependency
like a CommomMark compiler or similar? Even if there are different
Markdown standards, the differences are minimal and circumventable. I
can imagine a dropdown menu with a selection of Markdown "flavours".

One should also not limit our imagination to what currently exists.
Perhaps in a typical desktop application suite, a markdown viewer should
be included, and we should make a community effort to make that normal.

> DJ Chase
> They, Them, Theirs

On Mon, Nov 1, 2021 at 12:42 PM Alex Schroeder <alex@alexschroeder.ch> wrote:
>
> I’d say no. The functionality of Gemini is pretty much done. People are 
of course free to write their own clients that do their own processing. 
But the standard is: if you need that, serve Markdown or HTML documents 
instead of extending Gemtext.

HTML with embedded Flash content, it's even better.

HTML has always been a failure, it has been written by corporations
that want the possibility to load any proprietary "binary" in a
document.

Not to mention Javascript.

-- 
Benjamin Henrion (zoobab)
Email: zoobab at gmail.com
Mobile: +32-484-566109
Web: http://www.zoobab.com
FFII.org Brussels
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

It was thus said that the Great Byron Torres once stated:
> On Mon Nov 1, 2021 at 2:35 PM GMT, DJ Chase wrote:
> 
> > Many people don't have a markdown viewer/compiler installed, and
> > serving HTML is, in my opinion, overkill for Gemini.
> 
> Who's to say installing a Gemini client shouldn't come with a dependency
> like a CommomMark compiler or similar? Even if there are different
> Markdown standards, the differences are minimal and circumventable. I
> can imagine a dropdown menu with a selection of Markdown "flavours".

  RFC-7763 and RFC-7764 describe text/markdown and the various permutations
currently defined.  

  -spc

If you think of “highlight” as bolding, then —

At least for the alphabet we commonly associate with English, Unicode has
bold versions of those characters:

𝐀 𝐁 𝐂 𝐃 𝐄 𝐅 𝐆 𝐇 𝐈 𝐉 𝐊 𝐋 𝐌 𝐍 𝐎 𝐏 𝐐 𝐑 𝐒 𝐓 𝐔 𝐕 𝐖 𝐗 𝐘
𝐙
𝐚 𝐛 𝐜 𝐝 𝐞 𝐟 𝐠 𝐡 𝐢 𝐣 𝐤 𝐥 𝐦 𝐧 𝐨 𝐩 𝐪 𝐫 𝐬 𝐭 𝐮 𝐯 𝐰 𝐱 𝐲
𝐳
𝟎 𝟏 𝟐 𝟑 𝟒 𝟓 𝟔 𝟕 𝟖 𝟗

𝗔 𝗕 𝗖 𝗗 𝗘 𝗙 𝗚 𝗛 𝗜 𝗝 𝗞 𝗟 𝗠 𝗡 𝗢 𝗣 𝗤 𝗥 𝗦 𝗧 𝗨 𝗩 𝗪 𝗫 𝗬
𝗭
𝗮 𝗯 𝗰 𝗱 𝗲 𝗳 𝗴 𝗵 𝗶 𝗷 𝗸 𝗹 𝗺 𝗻 𝗼 𝗽 𝗾 𝗿 𝘀 𝘁 𝘂 𝘃 𝘄 𝘅 𝘆
𝘇
𝟬 𝟭 𝟮 𝟯 𝟰 𝟱 𝟲 𝟳 𝟴 𝟵

If you are writing English, you could use those characters.

--
Charles Iliya Krempeaux, B.Sc.
cikrempeaux@gmail.com



On Mon, Nov 1, 2021 at 4:04 AM Roberto Soccoli <roberto.vpt@protonmail.com>
wrote:

> Gemini now expects the "* " tag for lists.
> I propose a single "**" tag, which I call "highlighted", which can be used
> several times in each paragraph of text as a switch that was initially
> turned off.
> Each client can interpret "highlighted" at will.
> Now I throw this message into space. 🚀
>
> Roberto Soccoli
> Telegram me: @Roberto_Soccoli
>
>

I understand that bold versions of Unicode characters can be used.
Noting that what I ask for is already used without a formal method, I 
communicate the method now implemented to you.
It is not necessary to insert it in the protocol even if it seems to me a 
Gemini-style addition.
To normalize the use of the inline "*" tag, which I call "highlighted", I 
propose that it can be used several times in each line, after the other 
tags, as an initially off switch.
Each client will be able to interpret it at will, even if it normally puts it in bold.

Roberto Soccoli
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Il mercoledì 3 novembre 2021 06:58, Charles Iliya Krempeaux 
<cikrempeaux@gmail.com> ha scritto:

> If you think of “highlight” as bolding, then —
>
> At least for the alphabet we commonly associate with English, Unicode 
has bold versions of those characters:
>
> 𝐀 𝐁 𝐂 𝐃 𝐄 𝐅 𝐆 𝐇 𝐈 𝐉 𝐊 𝐋 𝐌 𝐍 𝐎 𝐏 𝐐 𝐑 𝐒 𝐓 𝐔 𝐕 𝐖 𝐗 𝐘 𝐙
> 𝐚 𝐛 𝐜 𝐝 𝐞 𝐟 𝐠 𝐡 𝐢 𝐣 𝐤 𝐥 𝐦 𝐧 𝐨 𝐩 𝐪 𝐫 𝐬 𝐭 𝐮 𝐯 𝐰 𝐱 𝐲 𝐳
> 𝟎 𝟏 𝟐 𝟑 𝟒 𝟓 𝟔 𝟕 𝟖 𝟗
>
> 𝗔 𝗕 𝗖 𝗗 𝗘 𝗙 𝗚 𝗛 𝗜 𝗝 𝗞 𝗟 𝗠 𝗡 𝗢 𝗣 𝗤 𝗥 𝗦 𝗧 𝗨 𝗩 𝗪 𝗫 𝗬 𝗭
> 𝗮 𝗯 𝗰 𝗱 𝗲 𝗳 𝗴 𝗵 𝗶 𝗷 𝗸 𝗹 𝗺 𝗻 𝗼 𝗽 𝗾 𝗿 𝘀 𝘁 𝘂 𝘃 𝘄 𝘅 𝘆 𝘇
> 𝟬 𝟭 𝟮 𝟯 𝟰 𝟱 𝟲 𝟳 𝟴 𝟵
>
> If you are writing English, you could use those characters.
>
> --
> Charles Iliya Krempeaux, B.Sc.
> cikrempeaux@gmail.com
>
> On Mon, Nov 1, 2021 at 4:04 AM Roberto Soccoli <roberto.vpt@protonmail.com> wrote:
>
>> Gemini now expects the "* " tag for lists.
>> I propose a single "**" tag, which I call "highlighted", which can be 
used several times in each paragraph of text as a switch that was initially turned off.
>> Each client can interpret "highlighted" at will.
>> Now I throw this message into space. 🚀
>>
>> Roberto Soccoli
>> Telegram me: @Roberto_Soccoli

> 𝐀, 𝗔

Those are *mathematical* bold letters, and shouldn't be used in place
of "A" as they're semantically different, they're not just a stylistic
variation. You wouldn't use "∪" in place of "U", would you? ;)

-- 
dalz

I know — but I think there is a tendency for semantic elements to
eventually become (defacto) style elements.

⁂

The sense I have of this is —

Regular people don't care whether these were originally for mathematics or
not — they look like bold versions of characters. And a number of people
are already using them as such. (There are even online tools to help people
use them.)

⁂

If Unicode doesn't come up with a semantically “pure” convention for
bolding — people will just use these.

And it isn't like we haven't been through this before.

Back in the day when terminals were common, some of them extended the set
of control codes (beyond those that came with the character set), to
include bolding.

For example —

\e[1m

⁂

Also —

We (in this community) are doing semantically “impure” things too.

Unicode has more than one symbol for making bullet lists —

For example U+2022 “•”.

Yet when we write Gemtext we use the asterisk (U+002A “*”) for the bullet
in the bullet list item.

And I know this didn't start with Gemtext, and it is an old convention. But
we are continuing it.

⁂

And yes, I know, not everyone's keyboards can easily generate U+2022. But
some people's can. Mine can. And (if that is a concern) U+2022 could have
been a permitted Gemtext bullet list symbol (in addition to the asterisk).

⁂

If Gemtext can ignore the original semantics of the asterisk, the
back-tick, the pound symbol, the equal symbol, and the greater-than symbol
— then why can't we also do the same with those mathematical characters?



On Wed, Nov 3, 2021, 1:38 AM dalz <gemini@alsd.eu> wrote:

> > 𝐀, 𝗔
>
> Those are *mathematical* bold letters, and shouldn't be used in place
> of "A" as they're semantically different, they're not just a stylistic
> variation. You wouldn't use "∪" in place of "U", would you? ;)
>
> --
> dalzu
>

3 Nov 2021 09:23:33 Charles Iliya Krempeaux <cikrempeaux@gmail.com>:

> I know — but I think there is a tendency for semantic elements to 
eventually become (defacto) style elements.
>
> ⁂
>
> The sense I have of this is —
>
> Regular people don't care whether these were originally for mathematics 
or not — they look like bold versions of characters. And a number of 
people are already using them as such. (There are even online tools to 
help people use them.)
>
> If Unicode doesn't come up with a semantically “pure” convention for 
bolding — people will just use these.

That's the kind of attitude that made HTML the
semantic/presentational spaghetti it is
today. We ought to separate semantics from
presentation where possible.

> And it isn't like we haven't been through this before.
>
> Back in the day when terminals were common, some of them extended the 
set of control codes (beyond those that came with the character set), to include bolding.
>
> For example —
>
> \e[1m
>
> ⁂

Isn't that a counter example?
Control characters are not printable characters.

> Also —
>
> We (in this community) are doing semantically “impure” things too.
>
> Unicode has more than one symbol for making bullet lists —
>
> For example U+2022 “•”.
>  
> Yet when we write Gemtext we use the asterisk (U+002A “*”) for the 
bullet in the bullet list item.
>
> And I know this didn't start with Gemtext, and it is an old convention. 
But we are continuing it.
>
> ⁂
>
> And yes, I know, not everyone's keyboards can easily generate U+2022. 
But some people's can. Mine can. And (if that is a concern) U+2022 could 
have been a permitted Gemtext bullet list symbol (in addition to the asterisk).
>
> ⁂
>
> If Gemtext can ignore the original semantics of the asterisk, the 
back-tick, the pound symbol, the equal symbol, and the greater-than symbol 
— then why can't we also do the same with those mathematical characters?

Gentext is a markup language. It's not
supposed to be an exact one-to-one
correlation to the resulting presentation.
The characters each have a purpose in the
Gemtext context. The mathematical characters
are mathematical, in whatever context.

We, as you touched upon, use '*' because its
ASCII, which is the most universal character
set and therefore accessible for everyone.
It would not be smart to include Unicode core
syntax. That's why most programming
languages' core syntaxes use ASCII.
Otherwise, we'd all be writing in APL-like
languages.

TL;DR : I could bring up any number of straw-man arguments, but those are 
not useful. The actual argument is as follows. Unicode mathematical 
characters used as if they were normal characters, just in a fancier font 
is just plain rude to multiple groups of people, some of whom the gemini 
specification explicitly recommends accommodating.


Hello, I actually have some knowledge that is relevant here.

> ...
> Regular people don't care whether these were originally for mathematics 
or not — they look like bold versions of characters. And a number of 
people are already using them as such. (There are even online tools to 
help people use them.)
> ...

This is true. However, as things currently stand, this is not a good thing.

The reason is simple: not everyone looks at screens. Screen readers exist. 
If I remember correctly, screen readers are actually explicitly mentioned 
in the gemtext specification, in the context of alt ext for ascii art in 
preformatted blocs. One could say, the gemini protocol was designed with 
text-to-speech systems in mind as well as screens. Currently, espeak reads 
"𝐀, 𝗔" as "letter 1d400, letter 1d5d4". This is worse than putting a 
clapping hand emoji between every other word, as that at least leaves the words intact.

While it is doubtless possible to write a screen reader that reads these 
mathematical symbols as if they were not mathematical symbols, for this 
change to be accepted would require *almost every screen reader on the 
market* to make this change. Also, what if the character is actually being 
used in the original context? Say someone wrote down an equation, using 
these symbols, and didn't note down multiplication? How would a screen 
reader recognise it as a mathematical context, not formatting?

And even if you are willing to intentionally/neglectfully exclude those 
with eyesight worse than yours, the fact remains that searching for this 
text would simply not work on most computers, using the most common algorithms.

Then there's the whole issue of older hardware, with limited or 
non-existent Unicode support. Expecting everyone to just use a specific 
set of characters from a relatively modern encoding, when some people are 
working on getting a functional gemini client working on hardware my 
father used as a child (slight exaggeration may exist) is just asking for trouble.

> 
> If Gemtext can ignore the original semantics of the asterisk, the 
back-tick, the pound symbol, the equal symbol, and the greater-than symbol 
— then why can't we also do the same with those mathematical characters?
> 

I personally don't recall the pound symbol having any meaning in gemini, 
I'll have to look through the spec again. However!

I have a multi-part answer:
 - tradition: For most of these old symbols, the "original" meaning is no 
longer used. Even where it is, alternate meanings are common, and well 
understood. These new symbols still hold their original meaning.
 - legibility: If someone sees a couple of lines beginning with an 
asterisk, it is pretty obvious they are bullet points. A screen reader 
might read them out, in which case they work as audible bullet points, or 
not, in which case the actual sentences should be entirely understandable. 
While an individual with a Unicode-supporting font and fully functioning 
eyes will understand the intended meaning behind these characters, lose 
any of these, and the entire word is gone, either turned into tofu, or into gibberish.

With no disrespect intended, Babiak.

Charles Iliya Krempeaux <cikrempeaux@gmail.com> writes:

> I know — but I think there is a tendency for semantic elements to eventually become
> (defacto) style elements.
> 
> ⁂
> 
> The sense I have of this is —
> 
> Regular people don't care whether these were originally for mathematics or not —
> they look like bold versions of characters. And a number of people are already using
> them as such. (There are even online tools to help people use them.)

They are, and that's a significant accessibility issue. As i wrote elsewhere:

> The use of various Unicode graphemes in an attempt to create the effect 
of using a different font (something i frequently encounter online) can be 
really shit for those who have to use screenreaders. For example, "𝔥𝔦" 
will probably not be read out to them as "hi", but as "MATHEMATICAL SYMBOL 
FRAKTUR SMALL H MATHEMATICAL SYMBOL FRAKTUR SMALL I".

So, sure, if people care more about style than about making their text 
accessible to a variety of people, that's their choice. But i'd really 
prefer that geminispace avoid, for as long as possible, the 
style-over-substance road that the Web has taken.


Alexis.

Charles Iliya Krempeaux <cikrempeaux@gmail.com> writes:

> At least for the alphabet we commonly associate with English, Unicode
> has bold versions of those characters:

It's recommended that you not use these (or other Unicode variants of
normal letters) in regular text — they are generally not handled in a
friendly or useful way by screen readers. There are contexts where using
them is a reasonable trade-off, but I'd say that emphasis in regular
text is not one of those contexts.

-- 
Jason McBrayer      | “Strange is the night where black stars rise,
jmcbray@carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.”
                    | ― Robert W. Chambers,The King in Yellow

Do we have to go PDF? Oh dear God. Okay if they're textual in nature, sure.
But you know someone is gonna start uploading scans. I mean people can do
that in HTML kinda, but thankfully it's harder to do.
Devin Prater
r.d.t.prater@gmail.com




On Mon, Nov 1, 2021 at 9:35 AM DJ Chase <u9000@posteo.mx> wrote:

> On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
> > I’d say no. The functionality of Gemini is pretty much done.
>
> Also, that's not line-oriented.
>
> > People are of course free to write their own clients that do their own
> > processing. But the standard is: if you need that, serve Markdown or
> > HTML documents instead of extending Gemtext.
>
> Side note: I think it's best to serve PDFs instead of other markup
> languages because everyone can view PDFs. Many people don't have a
> markdown viewer/compiler installed, and serving HTML is, in my opinion,
> overkill for Gemini.
>
> --
> DJ Chase
> They, Them, Theirs
>
>

I'm reminded of the guy that went 'the internet is shit. return to PDF' 
and everyone else just

'PDF is terrible for a long list of reasons.'

So I ask now the same question as then without further rhetoric. 'Why?'

On 11/3/21 8:05 AM, Devin Prater wrote:
> Do we have to go PDF? Oh dear God. Okay if they're textual in nature, 
sure. But you know someone is gonna start uploading scans. I mean people 
can do that in HTML kinda, but thankfully it's harder to do.
> Devin Prater
> r.d.t.prater@gmail.com <mailto:r.d.t.prater@gmail.com>
> 
> 
> 
> 
> On Mon, Nov 1, 2021 at 9:35 AM DJ Chase <u9000@posteo.mx 
<mailto:u9000@posteo.mx>> wrote:
> 
>     On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
>     > I’d say no. The functionality of Gemini is pretty much done.
> 
>     Also, that's not line-oriented.
> 
>     > People are of course free to write their own clients that do
>     their own
>     > processing. But the standard is: if you need that, serve Markdown or
>     > HTML documents instead of extending Gemtext.
> 
>     Side note: I think it's best to serve PDFs instead of other markup
>     languages because everyone can view PDFs. Many people don't have a
>     markdown viewer/compiler installed, and serving HTML is, in my
>     opinion,
>     overkill for Gemini.
> 
>     --     DJ Chase
>     They, Them, Theirs
> 
-- -----
http://singletona082.flounder.online
gemini://singletona082.flounder.online
My online presence

Sure, if you want screen reader users to have to hear "lattin bold capital
letter a lattin bold letter d latin bold letter o latin bold letter n latin
bold letter a latin bold letter l latin bold letter s latin bold letter i
latin bold letter u latin bold letter m." I mean I knew this would start
happening because people don't like constraints on expression of text. And
now I guess it starts.
Devin Prater
r.d.t.prater@gmail.com




On Wed, Nov 3, 2021 at 12:58 AM Charles Iliya Krempeaux <
cikrempeaux@gmail.com> wrote:

> If you think of “highlight” as bolding, then —
>
> At least for the alphabet we commonly associate with English, Unicode has
> bold versions of those characters:
>
> 𝐀 𝐁 𝐂 𝐃 𝐄 𝐅 𝐆 𝐇 𝐈 𝐉 𝐊 𝐋 𝐌 𝐍 𝐎 𝐏 𝐐 𝐑 𝐒 𝐓 𝐔 𝐕 𝐖 𝐗 𝐘
> 𝐙
> 𝐚 𝐛 𝐜 𝐝 𝐞 𝐟 𝐠 𝐡 𝐢 𝐣 𝐤 𝐥 𝐦 𝐧 𝐨 𝐩 𝐪 𝐫 𝐬 𝐭 𝐮 𝐯 𝐰 𝐱 𝐲
> 𝐳
> 𝟎 𝟏 𝟐 𝟑 𝟒 𝟓 𝟔 𝟕 𝟖 𝟗
>
> 𝗔 𝗕 𝗖 𝗗 𝗘 𝗙 𝗚 𝗛 𝗜 𝗝 𝗞 𝗟 𝗠 𝗡 𝗢 𝗣 𝗤 𝗥 𝗦 𝗧 𝗨 𝗩 𝗪 𝗫 𝗬
> 𝗭
> 𝗮 𝗯 𝗰 𝗱 𝗲 𝗳 𝗴 𝗵 𝗶 𝗷 𝗸 𝗹 𝗺 𝗻 𝗼 𝗽 𝗾 𝗿 𝘀 𝘁 𝘂 𝘃 𝘄 𝘅 𝘆
> 𝘇
> 𝟬 𝟭 𝟮 𝟯 𝟰 𝟱 𝟲 𝟳 𝟴 𝟵
>
> If you are writing English, you could use those characters.
>
> --
> Charles Iliya Krempeaux, B.Sc.
> cikrempeaux@gmail.com
>
>
>
> On Mon, Nov 1, 2021 at 4:04 AM Roberto Soccoli <roberto.vpt@protonmail.com>
> wrote:
>
>> Gemini now expects the "* " tag for lists.
>> I propose a single "**" tag, which I call "highlighted", which can be
>> used several times in each paragraph of text as a switch that was initially
>> turned off.
>> Each client can interpret "highlighted" at will.
>> Now I throw this message into space. 🚀
>>
>> Roberto Soccoli
>> Telegram me: @Roberto_Soccoli
>>
>>

Davin beat me to it.

The idea of 'well lets just use the bold unicode' is... an anti feature 
for anyone needing anything adaptive, and goes counter to offloading 
presentation elements onto the client.

On 11/3/21 8:10 AM, Devin Prater wrote:
> Sure, if you want screen reader users to have to hear "lattin bold 
capital letter a lattin bold letter d latin bold letter o latin bold 
letter n latin bold letter a latin bold letter l latin bold letter s latin 
bold letter i latin bold letter u latin bold letter m." I mean I knew this 
would start happening because people don't like constraints on expression 
of text. And now I guess it starts.
> Devin Prater
> r.d.t.prater@gmail.com <mailto:r.d.t.prater@gmail.com>
> 
> 
> 
> 
> On Wed, Nov 3, 2021 at 12:58 AM Charles Iliya Krempeaux 
<cikrempeaux@gmail.com <mailto:cikrempeaux@gmail.com>> wrote:
> 
>     If you think of “highlight” as bolding, then —
> 
>     At least for the alphabet we commonly associate with English,
>     Unicode has bold versions of those characters:
> 
>     𝐀 𝐁 𝐂 𝐃 𝐄 𝐅 𝐆 𝐇 𝐈 𝐉 𝐊 𝐋 𝐌 𝐍 𝐎 𝐏 𝐐 𝐑 𝐒 𝐓 𝐔 𝐕
>     𝐖 𝐗 𝐘 𝐙
>     𝐚 𝐛 𝐜 𝐝 𝐞 𝐟 𝐠 𝐡 𝐢 𝐣 𝐤 𝐥 𝐦 𝐧 𝐨 𝐩 𝐪 𝐫 𝐬 𝐭 𝐮 𝐯
>     𝐰 𝐱 𝐲 𝐳
>     𝟎 𝟏 𝟐 𝟑 𝟒 𝟓 𝟔 𝟕 𝟖 𝟗
> 
>     𝗔 𝗕 𝗖 𝗗 𝗘 𝗙 𝗚 𝗛 𝗜 𝗝 𝗞 𝗟 𝗠 𝗡 𝗢 𝗣 𝗤 𝗥 𝗦 𝗧 𝗨 𝗩
>     𝗪 𝗫 𝗬 𝗭
>     𝗮 𝗯 𝗰 𝗱 𝗲 𝗳 𝗴 𝗵 𝗶 𝗷 𝗸 𝗹 𝗺 𝗻 𝗼 𝗽 𝗾 𝗿 𝘀 𝘁 𝘂 𝘃
>     𝘄 𝘅 𝘆 𝘇
>     𝟬 𝟭 𝟮 𝟯 𝟰 𝟱 𝟲 𝟳 𝟴 𝟵
> 
>     If you are writing English, you could use those characters.
> 
>     --
>     Charles Iliya Krempeaux, B.Sc.
>     cikrempeaux@gmail.com <mailto:cikrempeaux@gmail.com>
> 
> 
> 
>     On Mon, Nov 1, 2021 at 4:04 AM Roberto Soccoli
>     <roberto.vpt@protonmail.com <mailto:roberto.vpt@protonmail.com>>
>     wrote:
> 
>         Gemini now expects the "* " tag for lists.
>         I propose a single "**" tag, which I call "highlighted", which
>         can be used several times in each paragraph of text as a
>         switch that was initially turned off.
>         Each client can interpret "highlighted" at will.
>         Now I throw this message into space. 🚀
> 
>         Roberto Soccoli
>         Telegram me: @Roberto_Soccoli
> 
-- -----
http://singletona082.flounder.online
gemini://singletona082.flounder.online
My online presence

Thank you so much for this. Yes, people may not care. The writers may not
care. The web browser developers may not care. But the spec creators should
do everything in their power to make Gemini as resistant as possible to the
degradation that is improper use of things for styling. Again, as someone
noted and that I'd kinda forgotten, you can serve Markdown or HTML or
Org-mode files, or even PDF's if a browser (read Lagrange) supports it.
Devin Prater
r.d.t.prater@gmail.com




On Wed, Nov 3, 2021 at 6:07 AM Alexis <flexibeast@gmail.com> wrote:

>
> Charles Iliya Krempeaux <cikrempeaux@gmail.com> writes:
>
> > I know — but I think there is a tendency for semantic elements
> > to eventually become
> > (defacto) style elements.
> >
> > ⁂
> >
> > The sense I have of this is —
> >
> > Regular people don't care whether these were originally for
> > mathematics or not —
> > they look like bold versions of characters. And a number of
> > people are already using
> > them as such. (There are even online tools to help people use
> > them.)
>
> They are, and that's a significant accessibility issue. As i wrote
> elsewhere:
>
> > The use of various Unicode graphemes in an attempt to create the
> > effect of using a different font (something i frequently
> > encounter online) can be really shit for those who have to use
> > screenreaders. For example, "𝔥𝔦" will probably not be read out
> > to them as "hi", but as "MATHEMATICAL SYMBOL FRAKTUR SMALL H
> > MATHEMATICAL SYMBOL FRAKTUR SMALL I".
>
> So, sure, if people care more about style than about making their
> text accessible to a variety of people, that's their choice. But
> i'd really prefer that geminispace avoid, for as long as possible,
> the style-over-substance road that the Web has taken.
>
>
> Alexis.
>

On Wed, Nov 03, 2021 at 08:13:11AM -0500, Andrew Singleton wrote:
> Davin beat me to it.
> 
> The idea of 'well lets just use the bold unicode' is... an anti feature for
> anyone needing anything adaptive, and goes counter to offloading
> presentation elements onto the client.

Alyssa Rosenzweig has written about the accessibility problems caused by
abusing Unicode for presentation here:

gemini://rosenzweig.io/gemlog/2021-04-04-your-gemlog-may-not-be-accessible.gmi

On a different tack, here's Nervuri on how Unicode homoglyphs can be
used in fingerprinting attacks on published text and how such things can
be detected and avoided:

gemini://rawtext.club/~nervuri/stega.gmi

For more on homoglyphs (distinct characters with visually similar
appearance):

https://en.wikipedia.org/wiki/Homoglyph

Very screenreader unfriendly ahead...

---

MATHEMATICAL BOLD CAPITAL W MATHEMATICAL BOLD SMALL h MATHEMATICAL BOLD
SMALL y MATHEMATICAL BOLD SMALL d MATHEMATICAL BOLD SMALL o MATHEMATICAL
BOLD SMALL n APOSTROPHE MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD
SMALL y MATHEMATICAL BOLD SMALL o MATHEMATICAL BOLD SMALL u MATHEMATICAL
BOLD SMALL f MATHEMATICAL BOLD SMALL u MATHEMATICAL BOLD SMALL c
MATHEMATICAL BOLD SMALL k MATHEMATICAL BOLD SMALL o MATHEMATICAL
MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD
SMALL w MATHEMATICAL BOLD SMALL i MATHEMATICAL BOLD SMALL t MATHEMATICAL
BOLD SMALL h MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD SMALL h
MATHEMATICAL BOLD SMALL a MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD
ITALIC SMALL s MATHEMATICAL BOLD ITALIC SMALL h MATHEMATICAL BOLD ITALIC
SMALL i MATHEMATICAL BOLD ITALIC SMALL t PERIOD

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com

On Wed, 2021-11-03 at 08:08 -0500, Andrew Singleton wrote:
> I'm reminded of the guy that went 'the internet is shit. return to PDF' 
> and everyone else just
> 
> 'PDF is terrible for a long list of reasons.'
> 
> So I ask now the same question as then without further rhetoric. 'Why?'

To be clear: I'm not proposing serving PDFs; I'm suggesting not to serve
HTML or Markdown (which is an HTML front-end, and can include HTML tags
such as `<script>`).

> > On Mon, Nov 1, 2021 at 9:35 AM DJ Chase <u9000@posteo.mx 
> > <mailto:u9000@posteo.mx>> wrote:
> > 
> > On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
> > > I’d say no. The functionality of Gemini is pretty much done.
> > > Also, that's not line-oriented.
> > > People are of course free to write their own clients that do
> > > their own
> > > processing. But the standard is: if you need that, serve Markdown or
> > > HTML documents instead of extending Gemtext.

Also, this isn't a standard. It's aruably not even the defacto-standard.

-- 
DJ Chase
They, Them, Theirs

I don't need a screen reader and I can /HEAR/ that.... so yes while you 
can't keep someone from using substitute lettering via the spec so long as 
its valid unicode?


please do not do this.

On 11/3/21 9:16 AM, Alex // nytpu wrote:
> Very screenreader unfriendly ahead...
> 
> ---
> 
> MATHEMATICAL BOLD CAPITAL W MATHEMATICAL BOLD SMALL h MATHEMATICAL BOLD
> SMALL y MATHEMATICAL BOLD SMALL d MATHEMATICAL BOLD SMALL o MATHEMATICAL
> BOLD SMALL n APOSTROPHE MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD
> SMALL y MATHEMATICAL BOLD SMALL o MATHEMATICAL BOLD SMALL u MATHEMATICAL
> BOLD SMALL f MATHEMATICAL BOLD SMALL u MATHEMATICAL BOLD SMALL c
> MATHEMATICAL BOLD SMALL k MATHEMATICAL BOLD SMALL o MATHEMATICAL
> MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD SMALL f MATHEMATICAL BOLD
> SMALL w MATHEMATICAL BOLD SMALL i MATHEMATICAL BOLD SMALL t MATHEMATICAL
> BOLD SMALL h MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD SMALL h
> MATHEMATICAL BOLD SMALL a MATHEMATICAL BOLD SMALL t MATHEMATICAL BOLD
> ITALIC SMALL s MATHEMATICAL BOLD ITALIC SMALL h MATHEMATICAL BOLD ITALIC
> SMALL i MATHEMATICAL BOLD ITALIC SMALL t PERIOD
> 
> ~nytpu
> 
-- -----
http://singletona082.flounder.online
gemini://singletona082.flounder.online
My online presence

Others have already said what I would say about the rest of this thread,
so I will skip that part.

On Wed, 2021-11-03 at 12:41 +0200, babiak wrote:
> > If Gemtext can ignore the original semantics of the asterisk, the 
> > back-tick, the pound symbol, the equal symbol, and the greater-than 
> > symbol — then why can't we also do the same with those mathematical 
> > characters?
> > 
> 
> I personally don't recall the pound symbol having any meaning in gemini, 
> I'll have to look through the spec again. However!

Charles is refering to '#', not '£'. '#' is called the 'pound
{sign,symbol}' in the telephone system.


-- 
DJ Chase
They, Them, Theirs

Oh that makes more sense. Thanks!

On 03/11/2021 19:05, DJ Chase wrote:
> Others have already said what I would say about the rest of this thread,
> so I will skip that part.
> 
> On Wed, 2021-11-03 at 12:41 +0200, babiak wrote:
>>> If Gemtext can ignore the original semantics of the asterisk, the
>>> back-tick, the pound symbol, the equal symbol, and the greater-than
>>> symbol — then why can't we also do the same with those mathematical
>>> characters?
>>> 
>> 
>> I personally don't recall the pound symbol having any meaning in gemini,
>> I'll have to look through the spec again. However!
> 
> Charles is refering to '#', not '£'. '#' is called the 'pound
> {sign,symbol}' in the telephone system.
> 
> 

-- -------------------------
Gemini capsule: babiak.duckdns.org

> Message: 2
> Date: Wed, 03 Nov 2021 14:56:22 +0000
> From: DJ Chase <u9000@posteo.mx>
> To: Andrew Singleton <singletona082@gmail.com>, Devin Prater
> 	<r.d.t.prater@gmail.com>
> Cc: Gemini application layer protocol <gemini@lists.orbitalfox.eu>,
> 	Roberto Soccoli <roberto.vpt@protonmail.com>
> Subject: Re: A Gemini-style proposal
> Message-ID: <e5620ac174b95cea0d66a62e0b8bf77e4027db34.camel@posteo.mx>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Wed, 2021-11-03 at 08:08 -0500, Andrew Singleton wrote:
>> I'm reminded of the guy that went 'the internet is shit. return to PDF'
>> and everyone else just
>> 
>> 'PDF is terrible for a long list of reasons.'
>> 
>> So I ask now the same question as then without further rhetoric. 'Why?'
> 
> To be clear: I'm not proposing serving PDFs; I'm suggesting not to serve
> HTML or Markdown (which is an HTML front-end, and can include HTML tags
> such as `<script>`).
> 
>>> On Mon, Nov 1, 2021 at 9:35 AM DJ Chase <u9000@posteo.mx
>>> <mailto:u9000@posteo.mx>> wrote:
>>> 
>>> On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
>>>> I?d say no. The functionality of Gemini is pretty much done.
>>>> Also, that's not line-oriented.
>>>> People are of course free to write their own clients that do
>>>> their own
>>>> processing. But the standard is: if you need that, serve Markdown or
>>>> HTML documents instead of extending Gemtext.
> 
> Also, this isn't a standard. It's aruably not even the defacto-standard.

People have pointed out from early on that gemini is designed on the 
server side to serve text documents (as not-links, anyway), and if you 
need more than the native gemtext format has to offer, you are free to 
serve whatever text, be it Markdown or what have you. I think all the 
browsers will just display markdown in all its human-readable glory. Like 
if you view gemini pages is bombadillo, and  headline just look like

# Headline



peteyboy@sdf.org
SDF Public Access UNIX System - http://sdf.org

It would be interesting to look at the existing browsers that support
Gemini & Gemtext, to see what other data formats they support.

Would also be even more interesting to compare that against which browsers
are currently more popular.

--
Charles Iliya Krempeaux, B.Sc.
cikrempeaux@gmail.com



On Wed, Nov 3, 2021 at 4:56 PM Pete D. <peteyboy@sdf.org> wrote:

>
> > Message: 2
> > Date: Wed, 03 Nov 2021 14:56:22 +0000
> > From: DJ Chase <u9000@posteo.mx>
> > To: Andrew Singleton <singletona082@gmail.com>, Devin Prater
> >       <r.d.t.prater@gmail.com>
> > Cc: Gemini application layer protocol <gemini@lists.orbitalfox.eu>,
> >       Roberto Soccoli <roberto.vpt@protonmail.com>
> > Subject: Re: A Gemini-style proposal
> > Message-ID: <e5620ac174b95cea0d66a62e0b8bf77e4027db34.camel@posteo.mx>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Wed, 2021-11-03 at 08:08 -0500, Andrew Singleton wrote:
> >> I'm reminded of the guy that went 'the internet is shit. return to PDF'
> >> and everyone else just
> >>
> >> 'PDF is terrible for a long list of reasons.'
> >>
> >> So I ask now the same question as then without further rhetoric. 'Why?'
> >
> > To be clear: I'm not proposing serving PDFs; I'm suggesting not to serve
> > HTML or Markdown (which is an HTML front-end, and can include HTML tags
> > such as `<script>`).
> >
> >>> On Mon, Nov 1, 2021 at 9:35 AM DJ Chase <u9000@posteo.mx
> >>> <mailto:u9000@posteo.mx>> wrote:
> >>>
> >>> On Mon, 2021-11-01 at 12:41 +0100, Alex Schroeder wrote:
> >>>> I?d say no. The functionality of Gemini is pretty much done.
> >>>> Also, that's not line-oriented.
> >>>> People are of course free to write their own clients that do
> >>>> their own
> >>>> processing. But the standard is: if you need that, serve Markdown or
> >>>> HTML documents instead of extending Gemtext.
> >
> > Also, this isn't a standard. It's aruably not even the defacto-standard.
>
> People have pointed out from early on that gemini is designed on the
> server side to serve text documents (as not-links, anyway), and if you
> need more than the native gemtext format has to offer, you are free to
> serve whatever text, be it Markdown or what have you. I think all the
> browsers will just display markdown in all its human-readable glory. Like
> if you view gemini pages is bombadillo, and  headline just look like
>
> # Headline
>
>
>
> peteyboy@sdf.org
> SDF Public Access UNIX System - http://sdf.org
>

Hi Roberto!

On Mon, 01 Nov 2021 11:03:39 +0000
Roberto Soccoli <roberto.vpt@protonmail.com> wrote:

> Gemini now expects the "* " tag for lists.
> I propose a single "**" tag, which I call "highlighted", which can be 
used several times in each paragraph of text as a switch that was initially turned off.

Previous discussions about in-line styling are relevant here:
gemini://gemi.dev/gemini-mailing-list/messages/003177.gmi

There are some good comments there why it's a good idea and why it's
not, and what the alternatives are. My suggestion back then was for
clients to optionally allow users to define regular expressions to
describe text that should be emphasized in different ways. No need for
a spec change so long as you don't change the content (see the
paragraph below), because the spec gives some room for interpretation
regarding rendering.

If you mean for these "**" not to be in-line, but to occur at the start
of a line, note that Gemini doesn't have a concept of paragraphs and
that every line break is printed, unlike e.g. Markdown which joins
consecutive, non-empty lines into paragraphs.

> Each client can interpret "highlighted" at will.

For any semblance of backwards compatibility, clients that implemented
this feature would need to show the original "**" in addition to
handling it, or it might break existing documents.

-- 
Philip

On Tue, 2 Nov 2021 22:58:23 -0700
Charles Iliya Krempeaux <cikrempeaux@gmail.com> wrote:

> At least for the alphabet we commonly associate with English, Unicode has
> bold versions of those characters:

Note that these are from the Mathematical Alphanumeric Symbols block,
and are intended to be used as mathematical symbols. Using them for
free-text emphasis subverts their intended purpose and may throw things
like text to speech systems, document search etc. off. I am strongly
against using them for emphasis.

-- 
Philip

It infuriates me that the '£' character sits on so many keyboard
configurations. Somebody should create a use for it or it should be put
out of its misery - it takes up too much realestate.

DJ Chase <u9000@posteo.mx> writes:

> Others have already said what I would say about the rest of this thread,
> so I will skip that part.
>
> On Wed, 2021-11-03 at 12:41 +0200, babiak wrote:
>> > If Gemtext can ignore the original semantics of the asterisk, the 
>> > back-tick, the pound symbol, the equal symbol, and the greater-than 
>> > symbol — then why can't we also do the same with those mathematical 
>> > characters?
>> > 
>> 
>> I personally don't recall the pound symbol having any meaning in gemini, 
>> I'll have to look through the spec again. However!
>
> Charles is refering to '#', not '£'. '#' is called the 'pound
> {sign,symbol}' in the telephone system.