Math Notation in Gemini?

Recently I found some people interested in Gemini as a research sharing 
format.  Their one requested extension was inline rendering of 
mathematical notation via Groff MS or TeX syntax.  Would this be something 
that could be handled as a special client side handler for links to 
documents containing the fragments, like how Lagrange handles inline image 
expansion on link select?  I do see the appeal, but I don't want to 
introduce the weight of Roff or MathML or TeX into the Gemtext format spec.

On 16/02/2021 18:23, Jonathan Lane wrote:
> Recently I found some people interested in Gemini as a research sharing 
format.  Their one requested extension was inline rendering of 
mathematical notation via Groff MS or TeX syntax.  Would this be something 
that could be handled as a special client side handler for links to 
documents containing the fragments, like how Lagrange handles inline image 
expansion on link select?  I do see the appeal, but I don't want to 
introduce the weight of Roff or MathML or TeX into the Gemtext format spec.
> 
I don't see why you couldn't have a client that could expand rendered 
math notation. You could just store it in the gemtext as a plaintext 
block with some kind of header/alt text that the client could read.

On Tuesday, February 16, 2021 10:26 AM, Nico <nico at itwont.work> wrote:
> I don't see why you couldn't have a client that could expand rendered
> math notation. You could just store it in the gemtext as a plaintext
> block with some kind of header/alt text that the client could read.

My concern there is that the minute we encourage inline alternate markup 
some clown starts injecting full HTML5/CSS3 into Gemtext instead of as 
separate .html links.

One of the golden rules of Gemini is user control, and by *default*
this would be off.
MathML/similar via preformatted blocks would be fine IMO, *if the user
enabled it*.

I don't see anyone ever making clients that render HTML as, well, why
would they?
But I understand that concern.

The spec never explicitly disallows this, but it does say how
preformatted lines should be displayed, which ~kinda disallows it.

IMO this specific case of MathML/similar would be perfectly fine.

- Oliver Simmons

On Tue, Feb 16, 2021 at 07:01:41PM +0000, Oliver Simmons wrote:
> One of the golden rules of Gemini is user control, and by *default*
> this would be off.
> MathML/similar via preformatted blocks would be fine IMO, *if the user
> enabled it*.
> 
I don't think it would be a good idea to embed Tex inline in gemini.
Some people can not read Tex and if their client didn't support it,
they would see weird characters. One of the ideas behind gemini I like
is that even plain text gemtext without any rendering is readable.

I would propose a bit different strategy, link a .tex file and have a
special client that can render it inline after clicking on the link
similar to how lagrange renders images.

This way is much more universal, we don't have to extend gemtext for
every use case, we can use existing formats.

~paper

> Le 16 f?vr. 2021 ? 19:23, Jonathan Lane <jon at dorsal.tk> a ?crit :
> 
> ?Recently I found some people interested in Gemini as a research sharing 
format.  Their one requested extension was inline rendering of 
mathematical notation via Groff MS or TeX syntax.  Would this be something 
that could be handled as a special client side handler for links to 
documents containing the fragments, like how Lagrange handles inline image 
expansion on link select?  I do see the appeal, but I don't want to 
introduce the weight of Roff or MathML or TeX into the Gemtext format spec.

Could it simply be serving a TeX file as application/x-latex (or another 
mime type) and let the client/user open it with any suitable app?

Paper <paper at tilde.institute> wrote:
> I would propose a bit different strategy, link a .tex file and have a
> special client that can render it inline after clicking on the link
> similar to how lagrange renders images.
> 
> This way is much more universal, we don't have to extend gemtext for
> every use case, we can use existing formats.

I agree completely.  I do use LaTeX and related, and I do see the appeal
of inlining it, but keeping gemtext simple forever is more important.  I
can imagine someone designing a renderer (which could use e.g. MathJax
or even just run it through LaTeX) or even a full-blown client for this.
It's also imaginable that some clients in the future support dynamic
(.dll / .so style) libraries which can render inline certain links, but
that's not happened yet (and I think there'd be a debate here on the ML
first).

~aravk | ~nothien

I second this. Serving the file as an appropriate type and letting the 
client decide is absolutely the approach. Rendering TeX in-line will mess 
up the readability of the plaintext for those rendering plain, not to 
mention open doors to further debasement of the standard.

The appeal of TeX integration is obvious, I use nothing else for document 
creation myself, but one person's TeX convenience is another person's 
tracking-cookie circus, so let's hold the line and stay focused! If we 
didn't allow in-line links and images, we're not to the point of even debating TeX.



-----------------------------

> Le 16 f?vr. 2021 ? 19:23, Jonathan Lane <> jon at dorsal.tk> > a ?crit :
>
> ?Recently I found some people interested in Gemini as a research sharing 
format. Their one requested extension was inline rendering of mathematical 
notation via Groff MS or TeX syntax. Would this be something that could be 
handled as a special client side handler for links to documents containing 
the fragments, like how Lagrange handles inline image expansion on link 
select? I do see the appeal, but I don't want to introduce the weight of 
Roff or MathML or TeX into the Gemtext format spec.
>

Could it simply be serving a TeX file as application/x-latex (or another 
mime type) and let the client/user open it with any suitable app?

It would be excellent for gemini to render mathematical notation but as
was said such a requirement conflicts with the core concepts of the
project.
However, much of mathematical notation (a lot of diagrams (category 
theory), for example) can be reasonably well rendered as ASCII art.
The only problem is that it might be to tedious to manually set so I was
wondering - is there some TikZ-to-ASCII or at lease diagram-to-ASCII
script?


On Tue, 16 Feb 2021, Jonathan Lane wrote:

> Recently I found some people interested in Gemini as a research sharing 
format.  Their one requested extension was inline rendering of 
mathematical notation via Groff MS or TeX syntax.  Would this be something 
that could be handled as a special client side handler for links to 
documents containing the fragments, like how Lagrange handles inline image 
expansion on link select?  I do see the appeal, but I don't want to 
introduce the weight of Roff or MathML or TeX into the Gemtext format spec.
>

> However, much of mathematical notation (a lot of diagrams (category
> theory), for example) can be reasonably well rendered as ASCII art.
> The only problem is that it might be to tedious to manually set so I
> was wondering - is there some TikZ-to-ASCII or at lease
> diagram-to-ASCII script?
Previously on the mailing list someone mentioned aamath[a] to render
formulae:

A_OPR = x*sqrt(x^2-1)/2 - int(sqrt(t^2-1), t = 1 .. x)

will turn into:

                        x
            ______     /
           / 2        |    ______
       x \/ x  - 1    |   / 2
A    = ----------- -  | \/ t  - 1 dt
 OPR        2         |
                      |
                     /
                      1


For diagrams, I'm sure if you could convert it to dot language[b] (more
common than one might think, lots of software supports it) then it'd be
trivial to convert it to ascii, here's a utility I found after a quick
search: https://github.com/ggerganov/dot-to-ascii


a: http://fuse.superglue.se/aamath/
b: https://www.graphviz.org/doc/info/lang.html

~nytpu

-- 
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210217/3f36
870b/attachment.sig>

Thank you! This seems to exactly what I was looking for.


On Wed, 17 Feb 2021, Alex // nytpu wrote:

>> However, much of mathematical notation (a lot of diagrams (category
>> theory), for example) can be reasonably well rendered as ASCII art.
>> The only problem is that it might be to tedious to manually set so I
>> was wondering - is there some TikZ-to-ASCII or at lease
>> diagram-to-ASCII script?
> Previously on the mailing list someone mentioned aamath[a] to render
> formulae:
>
> A_OPR = x*sqrt(x^2-1)/2 - int(sqrt(t^2-1), t = 1 .. x)
>
> will turn into:
>
>                        x
>            ______     /
>           / 2        |    ______
>       x \/ x  - 1    |   / 2
> A    = ----------- -  | \/ t  - 1 dt
> OPR        2         |
>                      |
>                     /
>                      1
>
>
> For diagrams, I'm sure if you could convert it to dot language[b] (more
> common than one might think, lots of software supports it) then it'd be
> trivial to convert it to ascii, here's a utility I found after a quick
> search: https://github.com/ggerganov/dot-to-ascii
>
>
> a: http://fuse.superglue.se/aamath/
> b: https://www.graphviz.org/doc/info/lang.html
>
> ~nytpu
>
> -- 
> Alex // nytpu
> alex at nytpu.com
> GPG Key: https://www.nytpu.com/files/pubkey.asc
> Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
> https://useplaintext.email/
>

I think most people interested in seeing mathematical notation are going 
to want the real thing, rather than ASCII art reproductions.  
Auto-generating ASCII art representations might be a fun challenge for a terminal client.

I was having a terminal client in mind.
Of course, for the real thing the only reasonable option I see is just linking
to a pdf, i.e. mimic arXiv.


On Wed, 17 Feb 2021, Jonathan Lane wrote:

> I think most people interested in seeing mathematical notation are going 
to want the real thing, rather than ASCII art reproductions.  
Auto-generating ASCII art representations might be a fun challenge for a terminal client.
>