💾 Archived View for idiomdrottning.org › emphasis-in-gemtext captured on 2023-04-26 at 13:38:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
One way would be an eight line type in Gemini. At this stage, it’s just an idea. Please do not start using it in capsules or in clients unless it becomes adopted by the protocol.
Lines beginning with _ are cursive lines. They may be displayed as bold, cursive, and/or a different color as the client wishes. They don’t have any inherent semantic meaning but can be used for titles, emphasis, foreign words, or any other reason, as the capsule wishes.
The _ and any spaces immediately following it are removed. If the line immediately neighbouring it is a text line or cursive line, exactly one line break between them is replaced by a single space.
For example, in this sentence,
_ these words would be displayed cursive
and these wouldn’t, and this would all be one line.
Orher ideas would be some sorta inline markup. Asterisks like markdown, doubled single quotes like Wikipedia, or tags, or control characters from the terminal, from ANSI, or from mIRC. Maybe with the added stipulation that both halves of the pair need to be on the same line. Asterisks are tricky because they’re used for so many other purposes, like multiplication or footnotes.
Again, please don’t start using these unless one of them becomes part of the spec.
I still see a lot of people still wanting to emphasize words. That was one of the few things I was missing when I first started using Gemini (behind metadata such as language and license, and tabular data). As time goes by, I’ve found that I can live just fine without it.
In other words, this is a kinda unneccessary proposal.
I am old so I remember when Project Gutenberg mandated ASCII text files only, and I was scared because Indidn’t want the canonical, preserved for all eternitity version be one that lost out on the typographical richness of classic books. But, having plain ASCII text as one of many possible exports would be just fine.
I’ve been kinda happy seeing Gemtext as one rendering of the text, not the canonical and perfect expression of the text. As an analogy, I used to do a lot of SVG stuff and sometimes the image got rendered into a PNG or a PDF. Those formats would lose something: they wouldn’t be nearly as editable or zoomable as the SVG source. Filter effects or complex gradients would be rasterized, and spiro splines rendered into normal bezier. But these format would also gain something: they were simpler for some clients to render and display.
Here’s another way to put it. I often try to take care to use cite, em, or i, as appropriate. It matters for scraping and mashing purps. But they are all displayed the same way, so obviously it doesn’t matter for display purps. Maybe they don’t even need to be displayed at all.
As a third example, I’m a huge fan of pdftotext. I like to use to to grab data out of PDFs for mashups, and for grepping. I have a folder of text-versions of PDFs just for grepping purposes; once I find which PDF has what I was looking for, I then can go read the actual PDF or paper book instead. It’s OK that the text version can’t do everything. It can do enough.
That’s how I see my gemtext, A simple rendering, suitable for cat and grep, still readable enough.
“Enough” is such a powerful concept. If I wanted to be maximally expressive I’d need some sorta five-dimensional VRML markup with scripting languages and namespaced sub-schemas and tags, but if you just wanna read what I have to say, you can. Gemtext is enough for it. I hope you like it.
I wanna rephrase; when above I sloppily wrote:
In other words, this is a kinda unneccessary proposal.
All I meant is that I’m personally not pushing for or insisting on a way to do emphasis, or insisting on my just-thinking-out-loud level “eighth line type” version above.
I meant to say that I’m not quitting Gemini for lack of text formatting. My own personal experience was going from missing text emphasis and inline links to appreciating the lack of them, but, my experience doesn’t have to be universal.
So, neither will I quit Gemini if a standard way of doing text formatting is adopted by the spec.
Having had some failed attempts at involvment in CommonMark, I know that CommonMark as a whole is a bit too much and too messy and too hard to parse and produce consistently. However, perhaps inline text differentiation (such ss usable for inline emphasis) doesn’t have to be a bridge too far. The “eight line type” could be one way, inline paired characters another.
I disagree strongly that this should be just implemented by some clients on their own without talking to each other. If this is to be done, it should be by changing the spec.
I disagree with this statement by gerikson:
I propose client implementers formally or informally agree to parse Markdown-like text styling syntax, if the user so wishes.
I’m not onboard; It need to be announced (such as being part of an, or the, spec) so that clients (especially non-traditipnal, such as audio-only) can properly recognize it and handle it.
Ad-hoc extension is even worse than an expanding standard.
Additionally, using paired asterisks for this has some (solvable, if we just spec it out, but real) problems. How to deal with mid-word asterisks, how to deal with lines that have an odd number of asterisks, and how to deal with multiplication and footnote usage of asterisks.
The most popular document object models are either hierarchical (the document is a nested tree, like XML) or turn-on-turn-off in a flow, like RTF. In RTF, you can start bold text, then start italic text, then write some words, then turn off bold, then turn off italic. In XML, that’s not possible, since it uses a hierarchical document object model where tags can be nested but not overlap.
A Gemtext document is a sequential list of typed lines. It is ambigious which of those two (tree vs turn-on-turn-off) object models it represents. There are no “blocks” or “block-level elements”, only line-level. Adding inline formatting to this is doable but tricky. The spec would need to say whether the formatting needed to start and end on the same line (tree style), or if that’s not a requirement (control char style).
Is it possible to answer all of these questions? Sure. I’m not opposed to that.
Emphasis has legitimate use cases in (English) prose - if nothing else for correctly quoting other works.
I misunderstood what was meant here. Maybe he meant quoting works that contain emphasis.
I first thought he meant cite, and wrote:
Cite and em aren’t the same thing, they only look the same. And some use cases (like introducing foreign words) are neither. This was what my (ultimately misguided) attempt at being involved in CommonMark was about; I wanted them to change asterisks from em to i. In the end, I settled on writing out cite or i when I need cite or i, and use asterisks or underline for when em is OK.
That’s why, in my proposals above, I’ve tried to talk about text differentiation (displayable as cursive or bold, since some terminals don’t have cursive) and not just emphasis.