Gemini上でテキストコンテンツを提供する最も一般的な方法は、Gopher上のような単なるプレーンテキストではなく、「Gemtext」と呼ばれる軽量マークアップ言語(非公式MIMEタイプ text/gemini で提供される)を使用することです。 このドキュメントは、そのマークアップ言語を簡単に紹介するものです。 Markdownと表面的に似ているところがあり、MDを知っていれば簡単に学ぶことができますが、他の点ではかなり異なっています。
このドキュメントを読んだ後、時々以下を読んで記憶を呼び覚ますのもいいかもしれません。
Gemtext チートシートGemtext文書のテキストは「長い行」を使って書かれています。つまり、あなた(またはあなたのエディター)は、80文字ごとに改行文字を挿入してはいけません。 その代わり、デバイスの画面サイズやユーザーの好みに合わせて行を折り返すのは、受信側のGeminiクライアントに任せてください。 こうすることで、Gemtextのコンテンツは、デスクトップモニター、ラップトップ画面、タブレット、スマートフォンで見栄えがよく、読みやすくなります。
Geminiクライアントは、ユーザーの画面より長いテキストの行を分割しますが、Markdown、HTML、LaTeXで起こるような、ユーザーの画面より短い行を結合することはないことに注意してください。 つまり、例えば箇条書きリストや意図的に行を短くした詩などは、作者が余計な作業をしたり、クライアントがそのようなコンテンツを正しく認識して処理するために賢くなったりしなくても、正しく表示されるのです。
ほとんどの「日常的な」文章では、このアプローチは、おそらく1段落に1行だけ使用することを意味します。
空白行は、クライアントがそのまま表示します。つまり、段落の間に2~3行の空白行を入れると、読者は2~3行の空白行を見ることになります。
Gopherのように(そしてMarkdownやHTMLのように)、Gemtextでは他の文書へのリンクをそれ自身の行にしか貼ることができません。つまり、文章の途中の一語をリンクにすることはできません。 これはすなわち、少し慣れが必要ですが、リンクを見つけるのが非常に簡単になり、クライアントが実際のテキストコンテンツの読みやすさを妨げることなく、リンクをさまざまなスタイルで（たとえば、使用するプロトコルを明確にしたり、ユーザーがリンクをたどるかどうかを決めるのに役立つようにドメイン名を表示したり）表示できるということです。
リンク行はこんな感じです。
=> https://example.com カッコいいウェブサイト => gopher://example.com もっとカッコいいジリスの巣穴(gopherhole) => https://example.com 最高にカッコいいGeminiカプセル => sftp://example.com
リンク行については、
上記の例では、著者が衒学的であったため、すべてのURLとラベルがきれいに並んでいます。 しかし、Geminiは気にしないので、以下のようにしても問題ありません。
=>https://example.com カッコいいウェブサイト =>gopher://example.com もっとカッコいいジリスの巣穴 => https://example.com 最高にカッコいいGeminiカプセル => sftp://example.com
Gemtextは3つのレベルの見出しをサポートしています。 見出しは1行に限られ、1つ、2つ、または3つの # 記号で始まり、その後に1つの強制的な空白文字が続きます。
# 大見出し ## 中見出し ### 小見出し
これはサポートされている唯一の見出し構文です。 Markdownのように - や = の記号を使って見出しに下線を引いても、何も起こりません。
見出しに特別な処理をするのは、厳密に言えばクライアントの任意です。 多くのクライアントは見出しを認識し、大きなフォントや異なる色、その他のスタイリングを使用しますが、一部のクライアントはそうせず、通常のテキスト行として扱い、そのまま出力します。 なぜなら、見出しはコンテンツの見た目をコントロールするために使われるものではないからです。 むしろ、見出しはコンテンツの構造に関する重要な意味情報を提供するものだからです。 クライアントによっては、見出しを利用して自動的に目次を生成し、大きな文書を閲覧するのに便利な場合があります。 AtomやRSSフィードを生成するソフトウェアでは、見出しを使ってgemlogの投稿のタイトルを自動的に検出することがあります。
Gemtext は順不同リストをサポートしています。 リストの各項目は、1つの長い行として記述され、その行は1つの * 記号で始まり、1つの必須の空白文字が続きます。
これはサポートされている唯一のリスト構文です。 Markdownのように * の代わりに - を使用しても、何も起こりません。 ネストされたリストはサポートされていません。
リストアイテムに特別なことをするのは厳密に言えばクライアントの任意であり、クライアントによっては他のテキスト行と同じように扱います。 リストが定義されている唯一の理由は、より高度なクライアントが * をより見栄えのする箇条書きの記号に置き換えることができるようにするためと、長すぎてデバイスの画面に収まらないリストアイテムが複数行にまたがる場合、最初の行の後の行を箇条書き記号と同じ量のスペースで余白からオフセットできるようにするためです。 これはタイポグラフィ上の工夫です。
Gemtextはブロック引用に対応しています。 引用された内容は、1つの長い行として記述され、1つの > で始まります。
> Gemtextはブロック引用に対応しています。 引用された内容は、1つの長い行として記述され、1つの > で始まります。
ブロッククオートを使って特別なことをするのは厳密に言えばクライアントの任意であり、クライアントによっては他のテキスト行と同じように扱われます。 リスト項目と同様に、これらは野心的なクライアントでより快適なタイポグラフィを可能にするために厳密に定義されています。
Gemtextは、パースとレンダリングがとてもとても簡単になるように慎重に設計されています。 GeminiクライアントはGemtextを一度に1行ずつ処理し、各行をその前後の行とは独立してレンダリングします。行の最初の数文字を見て、 =>, #, * などをチェックするだけです。
「```」で始まる行は、クライアントに通常の解析モードと「プリフォーマットモード」の切り替えを指示します。 プリフォーマットモードでは、クライアントはその行がリンクか見出しか、あるいは他の何かであるかどうかをチェックしません。 それらは単にそのまま印刷されます。 また、クライアントは通常のテキストには可変幅のフォントを使うことができますが、プリフォーマットモードではクライアントは固定幅のフォントを使わなければなりません。 したがって、一対の ``` 行は HTML の <pre> と </pre> タグと同じような働きをします。
あらかじめフォーマットされたテキストは、クライアントが行を見出しやリスト項目などと間違って解釈することなく、ASCIIアートやソースコードなどのコンテンツをGemtext文書に含められます。 また、Gemtextの構文を例示して説明するこのような文書を書くのにも使えます。上の構文の例は、プリフォーマットモードでレンダリングされているので、クライアントが通常と同じように解釈することなく見ることができます。
整形済み行をトグルする行の ``` 文字の後に来るもの(つまり、文書内でトグルする最初の行、3番目の行、5番目の行など)は、あらかじめフォーマットされたコンテンツの「altテキスト」として扱われることがあります。 一般に、このコンテンツがユーザーから見えることを期待すべきではありませんが、例えば、検索エンジンはこれをインデックス化し、スクリーンリーダーはこれをユーザーに読み聞かせて、整形済みコンテンツを読み上げるべきかどうか(例えば、ASCIIアートは一般にそうすべきではありませんが、ソースコードはおそらくそうすべきです)をユーザーが判断するのに役立つかもしれません。 altテキストはどのようにフォーマットされるべきか、現在確立された規約はありません。