-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
Nice work @Acidus. đ
Since you are displaying the email contents as preformatted text, it may not (should not, IMHO) be wrapped by clients to fit on the screen, though. Any chance you can wrap the long single-line paragraphs to a shorter max width?
Of course, on mobile devices, preformatted text is not great but I can understand why you'd choose to use it here.
2023-10-14 ¡ 7 months ago ¡ đ mozz, director ¡ ⤠1
Something between 60-70 is usually readable on mobile in landscape mode.
Thanks for the kind words @skyjake. I really just wanted an easy way to read all this content, and to link individual messages. However an important goal was that I didn't want the reader to ever wonder: "wait, is this formatting because of how Acidus is interpreting the text, or is it how the text was actually written?" I want the content to just be as it was.
The content of the messages is pretty varied, and so it's hard to come up with good general rules on how to transform or reformat it in a way that doesn't become distracting. I certainly struggled with this and am open to suggestions.
As an example, look at the first thread:
Sean's first message uses whitespace to indent (Something that would be lost if rendered as a text line in gemtext since browsers swallow leading whitespace). Other emails use whitespace for layout or to line up certain things they are discussing.
Sean's message has Gemini link lines. I don't want those to render as links. Should I wrap those lines in a preformatted sections? Should I indent them with 1 space character so they don't render?
Look at the use of `>` for quoted text in replies. Should I try and wrap that text? Should I collapse consecutive lines of quote into a single gemtext quote line?
What about multiple levels of quotes (e.g. `> >` or `>> >`, etc.). A gemini browser will do whatever it special formatting it does to render a quote and eat with the first `>` character, but then the others `>` characters are just present in the quoted text? Do they get wrapped strangely?
Seans last message uses indenting to group 3 URLs, which would be lost in gemtext.
Many authors use email signatures, which assumes fixed width text.
And we are just talking about the first 11 messages. There are over 7700...
So I just punted on the whole thing. I decided the emails are what they are. The cleanest, easiest way to show them was to preserve the text exactly as it is in the mbox messages. Funny enough this is what Orbital Fox did as well, where each email is rendered inside a `<pre>` tag.
If you can come up with a better way, I'm certainly open to suggestions.
Something that is a little distracting is that Lagrange seems to change the size of the text in a Preformatted section, based on the width of the text. Would you consider adding an option to disable that?
I agree those are all good reasons to use preformatted text to display the contents. However, I would raise one point: the email clients that I've used do apply word wrapping to overly long lines, in case the sender's client didn't wrap the message body. So when I read those messages, they were not super-long horizontally scrolled lines but regular paragraphs. (Personally, I also view all plain text emails with a proportional font, and it's usually just fine.)
I propose this formatting tweak: keep everything else the same, but if a line is longer than ~100 characters, insert newlines to word-wrap it to about 70 characters per line.
As an additional heuristic, you might consider checking if a line has 3 or more consecutive whitespace characters, which would indicate that it has some indentation or other pre-formatting applied. Those lines could be kept as is.
When it comes to Lagrange's preformatted blocks, they certainly could use some improvement. A per-block word wrapping option would resolve the readability issue altogether, for instance. The adaptive font sizing is basically a crutch to avoid having to horizontally scroll blocks, which has always been a bit glitchy. The original idea was to freely scale the contents (like the image viewer does) to fit into the horizontal space, but the text renderer doesn't support arbitrary font sizes. Hence, there are only regular and small monospaced blocks...
I am planning to improve this situation at some point, hopefully sooner than later.
Yeah, I like that. Seems like a reasonable modification to make: Keep everything the same, and keep the content in a single preformatted section. However, if a line is longer than 100 or so charcters, and doesn't seem to have any specific padding/whitespace formatting, hard wrap it.
Let me try playing with this later
-- Response ended
-- Page fetched on Sun May 19 15:06:40 2024