💾 Archived View for rawtext.club › ~sloum › geminilist › 005303.gmi captured on 2024-02-05 at 11:12:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
David Emerson d at nnix.com
Tue Feb 16 23:10:56 GMT 2021
- - - - - - - - - - - - - - - - - - -
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?