>> I think that it's reasonable to suggest that clients implement a form of >> rich text other than text/gemini. I don't think we need to bloat text/gemini >> to support every use case, instead I think we should encourage a set of >> alternatives. > > Does the client itself really need to do this? No, I don't think that clients need to do this themself. They could if they want to, but they could just as well delegate it to existing programs. To that end my original verbalisation was not really good because the gemini client should not be concerned with how easy it is to parse a different markup language. > Allow the configuration of MIME type handlers that delegate the task to other > applications and it's no longer strictly necessary, Exactly that. For example with text/troff a client could use nroff as a backend. > but would the user experience suffer? I don't see how the user experience should suffer, except for maybe installation on a platform where troff/nroff/groff/etc. is not available. That said, there is even a version of groff for Windows. And unixoids should also covered obviously. Of course it would probably be easier for terminal-based gemini clients than for graphical based clients to implement something like this. >> Reviewing the Wikipedia list of document markup languages[1] I'd lean towards >> TROFF or LaTeX. They are both mature and reasonably well defined formats. >> LaTeX has the advantage of being a target for several document preprocessors >> (eg: pandoc[2]) so it need not be authored in directly. > > Those formats would both be a hard no for me. ... > A full distribution of LaTeX in particular can easily eat hundreds of > megabytes, even gigabytes. I agree that LaTeX is probably overkill for this but seeing that troff or better nroff were designed pretty similar to text/gemini, macros start at the start of the line etc. its really quite simple. > If the goal of Gemini is to be a protocol that makes the implementation of a > client and server simple, I don't think that recommending the inclusion of > full typesetting systems is reasonable. At least for me this was not the point at all. It was more a recommendation that people who want other formatting with italics etc. could use another MIME type and not have to discuss endlessly on the mailing list and getting nowhere. The degree of including it into the standard to be able to use it is already big enough: You can specify which MIME type the response is. It is only a problem if the respective client does not implement that. And I think it depends on how deeply people want to use other formatting than provided by text/gemini if this gets more widespread usage in documents, and if that happens, clients will start to implement it too.
---
Previous in thread (14 of 29): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (16 of 29): 🗣️ Matthew Ernisse (matt (a) going-flying.com)