💾 Archived View for gemi.dev › gemini-mailing-list › 000714.gmi captured on 2023-12-28 at 15:51:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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. >
---
Previous Thread: [users] Moved from artorinix.com to artorinix.space
Next Thread: Gemini Capsule Update: Mental Health and Drug Addicts