mirror of https://tildegit.org/sbgodin/HtmGem.git
Compare commits
20 Commits
e479114cf0
...
41d1e3b289
| Author | SHA1 | Date |
|---|---|---|
 Christophe HENRY
|
41d1e3b289
|
|
|
Christophe HENRY
|
12f823fe5a | |
|
Christophe HENRY
|
86f07b2f2f | |
|
Christophe HENRY
|
c49e214591 | |
|
Christophe HENRY
|
0daecbd624 | |
|
Christophe HENRY
|
5075e7395d | |
|
Christophe HENRY
|
a79347d339 | |
|
Christophe HENRY
|
de1e2c0664 | |
|
Christophe HENRY
|
8207df2b2e | |
|
Christophe HENRY
|
babf80b5ab | |
|
Christophe HENRY
|
a4879c929c | |
|
Christophe HENRY
|
9bb14c4e03 | |
|
Christophe HENRY
|
852e57d800 | |
|
Christophe HENRY
|
ef149dcad8 | |
|
Christophe HENRY
|
c36e9347a6 | |
|
Christophe HENRY
|
0834fd3bc9 | |
|
Christophe HENRY
|
678778ba2c | |
|
Christophe HENRY
|
8e74403bc4 | |
|
Christophe HENRY
|
211518e098 | |
|
Christophe HENRY
|
0079c31e14 |
|
|
@ -4,6 +4,12 @@ All notable changes to this project will be documented in this file.
|
|||
=> https://keepachangelog.com/en/1.0.0/ The format is based on keep a Changelog.
|
||||
=> https://semver.org/spec/v2.0.0.html And this project adheres to Semantic Versioning.
|
||||
|
||||
## [1.5.0] - 2022-08-23
|
||||
* Adds the Lagrange style, thanks to Eric <ortie10 at gmx.fr>
|
||||
* Adds circumlunar css
|
||||
* Removes the page-specific CSS
|
||||
* Rewrites the documentation
|
||||
|
||||
## [1.4.1] - 2022-08-02
|
||||
* Adds link to /htmgem on the icon of the menu
|
||||
* Fixes bug about CSS not applied correctly
|
||||
|
|
|
|||
|
|
@ -0,0 +1,144 @@
|
|||
/* Copied from https://gemini.circumlunar.space 2022-08-01 */
|
||||
|
||||
html {
|
||||
font-family: sans-serif;
|
||||
font-size:16px;
|
||||
line-height:1.6;
|
||||
color:#1E4147;
|
||||
background-color:#AAC789;
|
||||
}
|
||||
|
||||
body {
|
||||
max-width: 920px;
|
||||
margin: 0 auto;
|
||||
padding: 1rem 2rem;
|
||||
}
|
||||
|
||||
h1,h2,h3{
|
||||
line-height:1.2;
|
||||
}
|
||||
|
||||
h1 {
|
||||
text-align: center;
|
||||
margin-bottom: 1em;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
background-color: #eee;
|
||||
border-left: 3px solid #444;
|
||||
margin: 1rem -1rem 1rem calc(-1rem - 3px);
|
||||
padding: 1rem;
|
||||
}
|
||||
|
||||
ul {
|
||||
margin-left: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
li {
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
li:not(:last-child) {
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
a {
|
||||
position: relative;
|
||||
color:#AA2E00;
|
||||
}
|
||||
|
||||
a:visited {
|
||||
color: #802200;
|
||||
}
|
||||
|
||||
/*
|
||||
a:before {
|
||||
content: '⇒';
|
||||
color:#AA2E00;
|
||||
text-decoration: none;
|
||||
font-weight: bold;
|
||||
position: absolute;
|
||||
left: -1.25rem;
|
||||
}
|
||||
*/
|
||||
|
||||
pre {
|
||||
background-color: #eee;
|
||||
margin: 0 -1rem;
|
||||
padding: 1rem;
|
||||
overflow-x: auto;
|
||||
}
|
||||
|
||||
details:not([open]) summary,
|
||||
details:not([open]) summary a {
|
||||
color: gray;
|
||||
}
|
||||
|
||||
details summary a:before {
|
||||
display: none;
|
||||
}
|
||||
|
||||
dl dt {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
dl dt:not(:first-child) {
|
||||
margin-top: 0.5rem;
|
||||
}
|
||||
|
||||
@media(prefers-color-scheme:dark) {
|
||||
html {
|
||||
background-color: #111;
|
||||
color: #eee;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
background-color: #000;
|
||||
}
|
||||
|
||||
pre {
|
||||
background-color: #222;
|
||||
}
|
||||
|
||||
a {
|
||||
color: #0087BD;
|
||||
}
|
||||
|
||||
a:visited {
|
||||
color: #802200;
|
||||
}
|
||||
}
|
||||
|
||||
label {
|
||||
display: block;
|
||||
font-weight: bold;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
input {
|
||||
display: block;
|
||||
border: 1px solid #888;
|
||||
padding: .375rem;
|
||||
line-height: 1.25rem;
|
||||
transition: border-color .15s ease-in-out,box-shadow .15s ease-in-out;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
input:focus {
|
||||
outline: 0;
|
||||
border-color: #80bdff;
|
||||
box-shadow: 0 0 0 0.2rem rgba(0,123,255,.25);
|
||||
}
|
||||
|
||||
|
||||
/* Additions for HtmGem */
|
||||
|
||||
.menu a {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.menu hr {
|
||||
color: red;
|
||||
}
|
||||
|
||||
|
|
@ -1,20 +1,22 @@
|
|||
# Styles
|
||||
|
||||
=> index.gmi|htmgem htmgem.css
|
||||
=> index.gmi|none None
|
||||
=> index.gmi|terminal terminal.css
|
||||
=> index.gmi|black_wide black_wide.css
|
||||
=> index.gmi|simple simple.css
|
||||
=> index.gmi|raw raw.css
|
||||
=> index.gmi|debug debug.css
|
||||
=> index.gmi|pre Source code
|
||||
=> index.gmi|default,htmgem.css default/htmgem.css
|
||||
=> index.gmi|default,base.css default/base.css
|
||||
=> index.gmi|default,circumlunar.css default/circumlunar.css
|
||||
=> index.gmi|lagrange,lagrange.css lagrange/lagrange.css
|
||||
=> index.gmi|default,terminal.css default/terminal.css
|
||||
=> index.gmi|default,black_wide.css default/black_wide.css
|
||||
=> index.gmi|default,simple.css default/simple.css
|
||||
=> index.gmi|default,raw.css default/raw.css
|
||||
=> index.gmi|default,debug.css default/debug.css
|
||||
=> index.gmi|src Source code
|
||||
=> index.gmi|source Download source code
|
||||
|
||||
Lorem ipsum dolor sit amet.
|
||||
//Lorem// **ipsum** __dolor__ ~~sit amet~~.
|
||||
|
||||
* ligne un de liste non ordonnée
|
||||
* ligne deux de liste non ordonnée
|
||||
* 1 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
|
||||
* 2 Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
|
||||
|
||||
> Citation : Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
|
||||
|
||||
|
|
@ -29,11 +31,11 @@ Lorem ipsum dolor sit amet.
|
|||
|| ||
|
||||
```
|
||||
|
||||
# Titre 1
|
||||
# 1 1 1 1 1 1
|
||||
|
||||
## Titre 2
|
||||
## 2 2 2 2 2 2
|
||||
|
||||
### Titre 3
|
||||
### 3 3 3 3 3 3
|
||||
|
||||
=> https://gmi.sbgodin.fr
|
||||
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1,433 @@
|
|||
/*-----------------------
|
||||
|
||||
----------------
|
||||
- Lagrange -
|
||||
----------------
|
||||
|
||||
a template for htmGem
|
||||
|
||||
based on
|
||||
|
||||
https://github.com/skyjake/lagrange
|
||||
|
||||
----------------------------*/
|
||||
|
||||
|
||||
|
||||
@font-face {
|
||||
font-family: nunito;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Nunito Bold'), url(Nunito-Bold.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Mada'), url(Mada-Regular.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: italic;
|
||||
font-weight: normal;
|
||||
src: url(SourceSansPro-Italic.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: bold;
|
||||
font-weight: 800;
|
||||
src: local('Mada Bold'), url(Mada-Bold.ttf) format('truetype');
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: mycourier;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Courier'), url(courier.ttf) format('truetype');
|
||||
}
|
||||
|
||||
|
||||
@font-face {
|
||||
font-family: Roboto Mono;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Roboto Mono'), url(RobotoMono.ttf) format('truetype');
|
||||
}
|
||||
|
||||
|
||||
|
||||
body {
|
||||
font-family: "Mada", sans-serif;
|
||||
font-weight: 400;
|
||||
font-size: 1.5em;
|
||||
margin-top: 0em;
|
||||
margin-left: 0em;
|
||||
margin-right: 0em;
|
||||
padding-right: 0em;
|
||||
}
|
||||
.menu-line {
|
||||
font-size: 105%;
|
||||
padding: 1.8em;
|
||||
}
|
||||
|
||||
|
||||
#gmi {
|
||||
max-width: 1024px;
|
||||
margin: auto;
|
||||
margin-top: 0.5em;
|
||||
margin-bottom: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
.menu li {
|
||||
display: inline-block;
|
||||
list-style: none;
|
||||
margin: 0 1rem;
|
||||
}
|
||||
.menu li::before {
|
||||
content: "";
|
||||
}
|
||||
|
||||
p {
|
||||
margin-left: 2.5em;
|
||||
margin-right: 0.5em;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.05em;
|
||||
}
|
||||
|
||||
p:empty {
|
||||
margin-top: 0.3em;
|
||||
margin-bottom: 0.3em;
|
||||
}
|
||||
|
||||
|
||||
li, ul {
|
||||
margin: 0 0 0.3em;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
|
||||
h1, h2, h3 {
|
||||
font-family: "Nunito", sans-serif;
|
||||
margin: 0 0 0.0em;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
|
||||
|
||||
h1 {
|
||||
font-size: 2.2em;
|
||||
font-weight: 400;
|
||||
margin-left: 0.5em;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.8em;
|
||||
font-weight: 600;
|
||||
margin-left: 0.5em;
|
||||
}
|
||||
h2 span.par-edit {
|
||||
visibility: hidden;
|
||||
font-size: x-small;
|
||||
}
|
||||
h2:hover span.par-edit {
|
||||
visibility: visible;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.6em;
|
||||
font-weight: 700;
|
||||
margin-left: 1em;
|
||||
}
|
||||
h4 {
|
||||
margin-left: 2em;
|
||||
}
|
||||
.link-icon {
|
||||
display: inline-block;
|
||||
width: 1.5em;
|
||||
font-family: Symbola;
|
||||
text-indent: 0;
|
||||
}
|
||||
div.link {
|
||||
text-indent: -1.5em;
|
||||
padding-left: 1.5em;
|
||||
margin-top: 0.15em;
|
||||
margin-bottom: 0.15em;
|
||||
}
|
||||
a {
|
||||
text-decoration: none;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
ul {
|
||||
list-style: none;
|
||||
margin-left: 0;
|
||||
padding-left: 3em;
|
||||
}
|
||||
ol {
|
||||
margin-left: 0;
|
||||
padding-left: 3em;
|
||||
}
|
||||
ul li, ol li {
|
||||
margin-top: 5pt;
|
||||
margin-bottom: 5pt;
|
||||
}
|
||||
ul li::before {
|
||||
content: "•";
|
||||
font-weight: bold;
|
||||
display: inline-block;
|
||||
width: 1.1em;
|
||||
margin-left: -1.1em;
|
||||
}
|
||||
|
||||
|
||||
blockquote {
|
||||
font-style: italic;
|
||||
font-weight: 300;
|
||||
padding-left: 0.75em;
|
||||
font-size: 100%;
|
||||
font-size: 1em;
|
||||
/*border-left: 1px solid #c38b16;
|
||||
*/
|
||||
margin-left: 1em;
|
||||
/* margin-right: 3em;*/
|
||||
margin-top: -1em;
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
blockquote:before {
|
||||
content: '“';
|
||||
font-weight: bold;
|
||||
font-size: 2.6em;
|
||||
line-height: 0.1em;
|
||||
/*vertical-align: -0.4em;*/
|
||||
margin-top: -2em;
|
||||
position: relative;
|
||||
top: 0.85em;
|
||||
left: 0.2em;
|
||||
}
|
||||
|
||||
pre {
|
||||
font-family: Roboto Mono, monospace;
|
||||
font-size: 0.9em;
|
||||
margin-left: 2.8em;
|
||||
margin-bottom: 0.05em;
|
||||
max-width: 100%;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
img {
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
.menu:nth-of-type(1) .menu-line {
|
||||
text-align: left;
|
||||
}
|
||||
.menu:nth-of-type(3) .menu-line {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.menu hr {
|
||||
border: 0;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
#gmi a {
|
||||
margin: -1.5em;
|
||||
}
|
||||
#gmi a:before {
|
||||
content: "🔗 ";
|
||||
}
|
||||
#gmi a:visited {
|
||||
font-weight: normal;
|
||||
/* doesn't work */
|
||||
}
|
||||
|
||||
|
||||
#gmi a.local:before {
|
||||
content: "➤️ ";
|
||||
font-weight: bold;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.local:visited {
|
||||
font-weight: normal;
|
||||
}
|
||||
#gmi a.gemini:before {
|
||||
content: "➤️ ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
#gmi a.gopher:before {
|
||||
content: "📜 ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
#gmi a.https:before {
|
||||
content: "🌐 ";
|
||||
font-weight: bolder;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.http:before {
|
||||
content: "🌐 ";
|
||||
font-weight: lighter;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.mumble:before {
|
||||
content: "🎤 ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.mailto:before {
|
||||
content: "✉️ ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
/* Responsivity */
|
||||
@media only screen and (max-width: 499px) and (orientation: portrait) {
|
||||
body {
|
||||
font-size: 1.2em;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
padding-left: 0;
|
||||
padding-right: 0;
|
||||
margin-left: 0;
|
||||
margin-right: 0;
|
||||
margin-top: 0;
|
||||
}
|
||||
h1 {
|
||||
font-size: 1.9em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 200%;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.5em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 160%;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.3em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 140%;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
margin-left: 1.5em ;
|
||||
}
|
||||
|
||||
blockquote:before {
|
||||
position: relative;
|
||||
top: 0.85em;
|
||||
left: -0.3em;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-left: 0.7em ;
|
||||
}
|
||||
|
||||
#gmi a {
|
||||
margin: 0.3em;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
body {
|
||||
filter: invert(100%) hue-rotate(180deg);
|
||||
}
|
||||
html {
|
||||
background-color: #111;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/* Orange / sepia Colors (for lagrange.css) */
|
||||
|
||||
|
||||
html, body {
|
||||
background: #f5ebd6;
|
||||
color: #192715;
|
||||
}
|
||||
blockquote, pre {
|
||||
/*background: #ede3d0;
|
||||
*/
|
||||
color: #d2780a;
|
||||
}
|
||||
h1 a {
|
||||
color: #eeeeee;
|
||||
font-weight: 800;
|
||||
}
|
||||
h1 {
|
||||
color: #d2780a;
|
||||
font-weight: 800;
|
||||
}
|
||||
h2, h3 {
|
||||
color: #693c05;
|
||||
}
|
||||
a:hover {
|
||||
color: #0a6e82;
|
||||
}
|
||||
a {
|
||||
color: #693c05;
|
||||
}
|
||||
|
||||
ul li::before {
|
||||
color: #503909;
|
||||
}
|
||||
|
||||
|
||||
blockquote:before {
|
||||
color: #e5b77a;
|
||||
}
|
||||
|
||||
.menu-line {
|
||||
background-color: #efd9b7;
|
||||
}
|
||||
.menu-line h1 a {
|
||||
color: #262626;
|
||||
font-weight: 300;
|
||||
}
|
||||
|
||||
.menu a, .menu a:visited {
|
||||
#color: #888;
|
||||
}
|
||||
.menu a:hover {
|
||||
#color: #000;
|
||||
}
|
||||
|
||||
#gmi a:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
|
||||
#gmi a:visited {
|
||||
color: #a25707;
|
||||
}
|
||||
|
||||
#gmi a:hover {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.local:before {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.gemini:before {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.https:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
#gmi a.http:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
|
|
@ -0,0 +1,433 @@
|
|||
/*-----------------------
|
||||
|
||||
----------------
|
||||
- Lagrange -
|
||||
----------------
|
||||
|
||||
a template for htmGem
|
||||
|
||||
based on
|
||||
|
||||
https://github.com/skyjake/lagrange
|
||||
|
||||
----------------------------*/
|
||||
|
||||
|
||||
|
||||
@font-face {
|
||||
font-family: nunito;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Nunito Bold'), url(Nunito-Bold.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Mada'), url(Mada-Regular.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: italic;
|
||||
font-weight: normal;
|
||||
src: url(SourceSansPro-Italic.ttf) format('truetype');
|
||||
}
|
||||
@font-face {
|
||||
font-family: Mada;
|
||||
font-style: bold;
|
||||
font-weight: 800;
|
||||
src: local('Mada Bold'), url(Mada-Bold.ttf) format('truetype');
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: mycourier;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Courier'), url(courier.ttf) format('truetype');
|
||||
}
|
||||
|
||||
|
||||
@font-face {
|
||||
font-family: Roboto Mono;
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: local('Roboto Mono'), url(RobotoMono.ttf) format('truetype');
|
||||
}
|
||||
|
||||
|
||||
|
||||
body {
|
||||
font-family: "Mada", sans-serif;
|
||||
font-weight: 400;
|
||||
font-size: 1.5em;
|
||||
margin-top: 0em;
|
||||
margin-left: 0em;
|
||||
margin-right: 0em;
|
||||
padding-right: 0em;
|
||||
}
|
||||
.menu-line {
|
||||
font-size: 105%;
|
||||
padding: 1.8em;
|
||||
}
|
||||
|
||||
|
||||
#gmi {
|
||||
max-width: 1024px;
|
||||
margin: auto;
|
||||
margin-top: 0.5em;
|
||||
margin-bottom: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
.menu li {
|
||||
display: inline-block;
|
||||
list-style: none;
|
||||
margin: 0 1rem;
|
||||
}
|
||||
.menu li::before {
|
||||
content: "";
|
||||
}
|
||||
|
||||
p {
|
||||
margin-left: 2.5em;
|
||||
margin-right: 0.5em;
|
||||
margin-top: 0;
|
||||
margin-bottom: 0.05em;
|
||||
}
|
||||
|
||||
p:empty {
|
||||
margin-top: 0.3em;
|
||||
margin-bottom: 0.3em;
|
||||
}
|
||||
|
||||
|
||||
li, ul {
|
||||
margin: 0 0 0.3em;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
|
||||
h1, h2, h3 {
|
||||
font-family: "Nunito", sans-serif;
|
||||
margin: 0 0 0.0em;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
|
||||
|
||||
h1 {
|
||||
font-size: 2.2em;
|
||||
font-weight: 400;
|
||||
margin-left: 0.5em;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.8em;
|
||||
font-weight: 600;
|
||||
margin-left: 0.5em;
|
||||
}
|
||||
h2 span.par-edit {
|
||||
visibility: hidden;
|
||||
font-size: x-small;
|
||||
}
|
||||
h2:hover span.par-edit {
|
||||
visibility: visible;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.6em;
|
||||
font-weight: 700;
|
||||
margin-left: 1em;
|
||||
}
|
||||
h4 {
|
||||
margin-left: 2em;
|
||||
}
|
||||
.link-icon {
|
||||
display: inline-block;
|
||||
width: 1.5em;
|
||||
font-family: Symbola;
|
||||
text-indent: 0;
|
||||
}
|
||||
div.link {
|
||||
text-indent: -1.5em;
|
||||
padding-left: 1.5em;
|
||||
margin-top: 0.15em;
|
||||
margin-bottom: 0.15em;
|
||||
}
|
||||
a {
|
||||
text-decoration: none;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
ul {
|
||||
list-style: none;
|
||||
margin-left: 0;
|
||||
padding-left: 3em;
|
||||
}
|
||||
ol {
|
||||
margin-left: 0;
|
||||
padding-left: 3em;
|
||||
}
|
||||
ul li, ol li {
|
||||
margin-top: 5pt;
|
||||
margin-bottom: 5pt;
|
||||
}
|
||||
ul li::before {
|
||||
content: "•";
|
||||
font-weight: bold;
|
||||
display: inline-block;
|
||||
width: 1.1em;
|
||||
margin-left: -1.1em;
|
||||
}
|
||||
|
||||
|
||||
blockquote {
|
||||
font-style: italic;
|
||||
font-weight: 300;
|
||||
padding-left: 0.75em;
|
||||
font-size: 100%;
|
||||
font-size: 1em;
|
||||
/*border-left: 1px solid #c38b16;
|
||||
*/
|
||||
margin-left: 1em;
|
||||
/* margin-right: 3em;*/
|
||||
margin-top: -1em;
|
||||
margin-bottom: 0em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
blockquote:before {
|
||||
content: '“';
|
||||
font-weight: bold;
|
||||
font-size: 2.6em;
|
||||
line-height: 0.1em;
|
||||
/*vertical-align: -0.4em;*/
|
||||
margin-top: -2em;
|
||||
position: relative;
|
||||
top: 0.85em;
|
||||
left: 0.2em;
|
||||
}
|
||||
|
||||
pre {
|
||||
font-family: Roboto Mono, monospace;
|
||||
font-size: 0.9em;
|
||||
margin-left: 2.8em;
|
||||
margin-bottom: 0.05em;
|
||||
max-width: 100%;
|
||||
overflow: auto;
|
||||
}
|
||||
|
||||
img {
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
.menu:nth-of-type(1) .menu-line {
|
||||
text-align: left;
|
||||
}
|
||||
.menu:nth-of-type(3) .menu-line {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.menu hr {
|
||||
border: 0;
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
#gmi a {
|
||||
margin: -1.5em;
|
||||
}
|
||||
#gmi a:before {
|
||||
content: "🔗 ";
|
||||
}
|
||||
#gmi a:visited {
|
||||
font-weight: normal;
|
||||
/* doesn't work */
|
||||
}
|
||||
|
||||
|
||||
#gmi a.local:before {
|
||||
content: "➤️ ";
|
||||
font-weight: bold;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.local:visited {
|
||||
font-weight: normal;
|
||||
}
|
||||
#gmi a.gemini:before {
|
||||
content: "➤️ ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
#gmi a.gopher:before {
|
||||
content: "📜 ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
|
||||
#gmi a.https:before {
|
||||
content: "🌐 ";
|
||||
font-weight: bolder;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.http:before {
|
||||
content: "🌐 ";
|
||||
font-weight: lighter;
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.mumble:before {
|
||||
content: "🎤 ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
#gmi a.mailto:before {
|
||||
content: "✉️ ";
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
|
||||
/* Responsivity */
|
||||
@media only screen and (max-width: 499px) and (orientation: portrait) {
|
||||
body {
|
||||
font-size: 1.2em;
|
||||
-webkit-text-size-adjust: 100%;
|
||||
padding-left: 0;
|
||||
padding-right: 0;
|
||||
margin-left: 0;
|
||||
margin-right: 0;
|
||||
margin-top: 0;
|
||||
}
|
||||
h1 {
|
||||
font-size: 1.9em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 200%;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.5em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 160%;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.3em;
|
||||
font-weight: bold;
|
||||
-webkit-text-size-adjust: 140%;
|
||||
}
|
||||
|
||||
blockquote {
|
||||
margin-left: 1.5em ;
|
||||
}
|
||||
|
||||
blockquote:before {
|
||||
position: relative;
|
||||
top: 0.85em;
|
||||
left: -0.3em;
|
||||
}
|
||||
|
||||
p {
|
||||
margin-left: 0.7em ;
|
||||
}
|
||||
|
||||
#gmi a {
|
||||
margin: 0.3em;
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
body {
|
||||
filter: invert(100%) hue-rotate(180deg);
|
||||
}
|
||||
html {
|
||||
background-color: #111;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/* Grey Colors (for lagrange.css) */
|
||||
|
||||
|
||||
html, body {
|
||||
background: #cecece;
|
||||
color: #343434;
|
||||
}
|
||||
blockquote, pre {
|
||||
/*background: #ede8de;
|
||||
*/
|
||||
color: #6e4900;
|
||||
}
|
||||
h1 a {
|
||||
color: #009966;
|
||||
font-weight: 800;
|
||||
}
|
||||
h1 {
|
||||
color: #009966;
|
||||
font-weight: 800;
|
||||
}
|
||||
h2, h3 {
|
||||
color: #005b3d;
|
||||
}
|
||||
a:hover {
|
||||
color: #0a6e82;
|
||||
}
|
||||
a {
|
||||
color: #000000;
|
||||
}
|
||||
|
||||
ul li::before {
|
||||
color: #503909;
|
||||
}
|
||||
|
||||
|
||||
blockquote:before {
|
||||
color: #a29271;
|
||||
}
|
||||
|
||||
.menu-line {
|
||||
background-color: #e0e0e0;
|
||||
}
|
||||
.menu-line h1 a {
|
||||
color: #005035;
|
||||
font-weight: 300;
|
||||
}
|
||||
|
||||
.menu a, .menu a:visited {
|
||||
#color: #888;
|
||||
}
|
||||
.menu a:hover {
|
||||
#color: #000;
|
||||
}
|
||||
|
||||
#gmi a:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
|
||||
#gmi a:visited {
|
||||
color: #565656;
|
||||
}
|
||||
|
||||
#gmi a:hover {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.local:before {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.gemini:before {
|
||||
color: #0a6e82;
|
||||
}
|
||||
|
||||
#gmi a.https:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
#gmi a.http:before {
|
||||
color: #d2780a;
|
||||
}
|
||||
110
docs/BNF-fr.gmi
110
docs/BNF-fr.gmi
|
|
@ -1,110 +0,0 @@
|
|||
# BNF
|
||||
### Backus-Naur Form
|
||||
=> https://fr.wikipedia.org/wiki/Forme_de_Backus-Naur Wikipedia / BNF
|
||||
|
||||
Le but de ce document est de montrer la BNF que HtmGem utilise et la façon dont il détermine le type de ligne et quelles informations il en tire. Pour cela, il utilise des **accolades** pour montrer explicitement quelles informations il prend. De plus, la **forme canonique** montre comment ça devrait être affiché.
|
||||
|
||||
———————————————————— ✀ ————————————————————
|
||||
|
||||
textgemini = *(link / preformat / heading / ulist / quoted / plain)
|
||||
; Preformat toggle starts as 'false'.
|
||||
|
||||
plain = **{[WSP] text} [WSP]** end-of-line
|
||||
; If preformat toggle is false, wrap text to the
|
||||
; width of the display. Otherwise, do no wrapping.
|
||||
; canonical form = {[WSP] text}
|
||||
|
||||
preformat = "```" **[WSP]** [{alt-text}] **[WSP]** end-of-line
|
||||
; Preformat toggle set to opposite state:
|
||||
; false goes to true
|
||||
; true goes to false
|
||||
; While in preformat toggle is true, link, heading,
|
||||
; ulist and quoted lines are NOT interpreted, but
|
||||
; displayed as is to the user.
|
||||
; canonical form = ``` [SP {alt-text}]
|
||||
|
||||
link = '=>' **[WSP]** [{URI-reference}] [**[WSP]** {text}] end-of-line
|
||||
; canonical form = '=>' SP {uri-reference} [SP {text}]
|
||||
|
||||
heading = '#' **[WSP]** [{text}] **[WSP]** end-of-line
|
||||
/ '##' **[WSP]** {text} **[WSP]** end-of-line
|
||||
/ '###' **[WSP]** {text} **[WSP]** end-of-line
|
||||
; canonical form = ('#' / '##' / '###') [SP {text}]
|
||||
|
||||
ulist = '*' **[WSP]** {text} **[WSP]** end-of-line
|
||||
; canonical form = '*' SP {text}
|
||||
|
||||
quoted = '>' **[WSP]** {text} **[WSP]** end-of-line
|
||||
; canonical form = '>' SP {text}
|
||||
|
||||
alt-text = text
|
||||
text = ***UVCHAR**
|
||||
end-of-line = [CR] LF
|
||||
|
||||
UVCHAR = VCHAR / UTF8-2v / UTF8-3 / UTF8-4
|
||||
UTF8-2v = %xC2 %xA0-BF UTF8-tail ; no C1 control set
|
||||
/ %xC3-DF UTF8-tail
|
||||
|
||||
; CRLF from RFC-5234
|
||||
; DIGIT from RFC-5234
|
||||
; SP from RFC-5234
|
||||
; VCHAR from RFC-5234
|
||||
; OCTET from RFC-5234
|
||||
; WSP from RFC-5234
|
||||
;
|
||||
; UTF8-3 from RFC-3629
|
||||
; UTF8-4 from RFC-3629
|
||||
; UTF8-tail from RFC-3629
|
||||
|
||||
———————————————————— ✀ ————————————————————
|
||||
|
||||
Cette BNF a été adaptée à l’implémentation de HtmGem depuis la version du groupe de travail.
|
||||
=> https://gitlab.com/gemini-specification/gemini-text/-/issues/7 Gitlab / Original ticket
|
||||
|
||||
Changements :
|
||||
* gestion des espaces blancs
|
||||
* capture du texte {}
|
||||
* forme canonique
|
||||
|
||||
Les espaces blancs terminant une ligne ne sont jamais utilisés. Voir la définition de //text// dans la BNF, qui ne contient plus //SP//.
|
||||
|
||||
# Exemples
|
||||
|
||||
## => liens
|
||||
|
||||
### Lien normal
|
||||
> link = '=>' [WSP] [{URI-reference}] [[WSP] {text}] end-of-line
|
||||
> ; canonical form = '=>' SP {uri-reference} [SP {text}]
|
||||
|
||||
Source: => foo.invalid text of the link
|
||||
Data: '=>' {'foo.invalid'} {'text of the link'}
|
||||
Canonical: => foo.invalid text of the link
|
||||
Html: <a href="foo.invalid">text of the link</a>
|
||||
|
||||
Source: =>foo.invalid text of the link
|
||||
Data: '=>' {'foo.invalid'} {'text of the link'}
|
||||
Canonical: => foo.invalid text of the link
|
||||
Html: <a href="foo.invalid">text of the link</a>
|
||||
|
||||
Source: => just_a_page
|
||||
Data: '=>' {'just_a_page'} {}
|
||||
Canonical: => just_a_page
|
||||
Html: <a href="just_a_page">just_a_page</a>
|
||||
|
||||
Source: =>
|
||||
Data: '=>' {''} {''}
|
||||
Canonical: =>
|
||||
Html: <a href=""> </a>
|
||||
|
||||
## # En-têtes
|
||||
> heading = '#' **[WSP]** [{text}] **[WSP]** end-of-line
|
||||
> (…)
|
||||
> ; canonical form = ('#' / '##' / '###') [SP {text}]
|
||||
|
||||
Source: #title
|
||||
Data: '#' {"title"}
|
||||
Canonical: # title
|
||||
|
||||
Source: # title with two spaces between title and with
|
||||
Data: '#' {"title with spaces"}
|
||||
Canonical: # title with two spaces between title and with
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
# Advanced configuration
|
||||
❗️ This page works with URL rewriting enabled ❗️
|
||||
|
||||
By default, the same style is used for all the pages, //htmgem/css/htmgem.css//, except when a file having the same name as the page but with the extension **.css** exists in the same directory. In such as case, it's used.
|
||||
|
||||
When the CSS option is activated in the configuration (see /rewrite// below) other behaviors are possible. **Beware**, it won't work with a Gemini client as HtmGem is only reachable with a web browser.
|
||||
* &style=**htmgem** : Uses the default style.
|
||||
* &style=**none** : The page HTML is sent without style.
|
||||
* &style=**<autre nom>** : The file htmgem/css/<autre nom>.css is used as a style.
|
||||
* &style=**/<path>** : The provided file (absolute path) is used as a style.
|
||||
* &style=**source** : The source code of the page is sent to the browser, see below…
|
||||
* &style=**pre** : The source code of the page is sent to the browser enclosed in //<pre>//, see below…
|
||||
|
||||
## URL rewriting to set the style to use
|
||||
|
||||
Modifying the web server configuration works but it's rather heavy. It's possible to test a particular style this way:
|
||||
> https://site.tld/htmgem/index.php?url=/url/page.gmi&style=<…>
|
||||
|
||||
It's also possible to make a URL rewriting which incorporate the style:
|
||||
> rewrite ^(.+\.gmi)$ /htmgem/index.php?rw=1&url=$1;
|
||||
> rewrite ^(.+\.gmi)\ *\|\ *([\w_]+)$ /htmgem/index.php?rw=1&url=$1&style=$2;
|
||||
|
||||
For instance, when it's activated:
|
||||
=> configuration-en.gmi%20|%20pre Shows the readable source code on the screen, using the markup **<pre>**.
|
||||
=> configuration-en.gmi%20|%20source configuration-en.gmi | source : Downloads the source code.
|
||||
|
||||
### With style already included…
|
||||
|
||||
=> configuration-en.gmi%20|%20htmgem Style //HtmGem//, the default style
|
||||
=> configuration-en.gmi%20|%20none Style //none//
|
||||
=> configuration-en.gmi%20|%20terminal Style //terminal//
|
||||
=> configuration-en.gmi%20|%20black_wide Style //black wide//
|
||||
=> configuration-en.gmi%20|%20simple Style //simple//
|
||||
=> configuration-en.gmi%20|%20raw Style //raw//
|
||||
=> configuration-en.gmi%20|%20debug Style //debug//
|
||||
|
||||
=> ../css Style selector: the page containing the style allows to test them 😎
|
||||
|
||||
## Text decoration
|
||||
|
||||
The text decoration, which interprets the **bold** for instance, is not part of GemText definition. The text decoration applies everywhere except on the titles and preformated texts.
|
||||
|
||||
### Disable the text decoration
|
||||
|
||||
It's possible to:
|
||||
* disable and enable the text decoration with a line **^^^**,
|
||||
* add what follows to the URL **rewriting**:
|
||||
> &textDecoration=0
|
||||
|
||||
## BNF / Syntax
|
||||
|
||||
HtmGem uses a precise implementation of the GemText BNF. It indicates exactly what text portions are to be used.
|
||||
=> BNF-en.gmi BNF
|
||||
|
||||
=> tutogemtext-en.gmi How to build GemText pages?
|
||||
|
||||
———————————————————— ————————————————————
|
||||
|
||||
Amongst the distributed files and directories, only the ones below are useful for HtmGem:
|
||||
* **htmgem/*.php** : These files translate the GemText to HTML.
|
||||
* **htmgem/css/htmgem.css** : If it's missing, the display will be without style — literally.
|
||||
* **htmgem/css/…** : Keep the styles you use.
|
||||
The others can be deleted (included this present file //configuration-en.gmi//) although they are not harmful.
|
||||
|
|
@ -1,63 +0,0 @@
|
|||
# Configuration avancée
|
||||
❗️ Cette page fonctionne avec la réécriture d’URL activée ❗️
|
||||
|
||||
Par défaut, le même style est utilisé pour toutes les pages, //htmgem/css/htmgem.css//, sauf lorsqu’un fichier ayant le même nom que la page mais avec l’extension **.css** existe dans le même répertoire. Dans ce cas, il est utilisé.
|
||||
|
||||
Lorsque l’option css est activé dans la configuration (voir //rewrite// plus bas) d’autres comportements sont possibles. **Attention**, cela ne fonctionnera pas avec un client Gemini puisque HtmGem n’est accessible que via un navigateur web.
|
||||
* &style=**htmgem** : Utilise le style par défaut.
|
||||
* &style=**none** : La page HTML est envoyée sans style.
|
||||
* &style=**<autre nom>** : Le fichier htmgem/css/<autre nom>.css est utilisé en tant que style.
|
||||
* &style=**/<path>** : Le fichier indiqué (chemin absolu) est utilisé en tant que style.
|
||||
* &style=**source** : Le code source de la page est envoyée au navigateur, voir ci-après…
|
||||
* &style=**pre** : Le code source de la page est envoyée au navigateur encadré par des //<pre>//, voir ci-après…
|
||||
|
||||
## Réécriture d’URL pour préciser le style à utiliser
|
||||
|
||||
Modifier la configuration du serveur web fonctionne mais est assez lourd. On peut tester un style en particulier de la façon suivante :
|
||||
> https://site.tld/htmgem/index.php?url=/url/page.gmi&style=<…>
|
||||
|
||||
Il est aussi possible de faire une réécriture d’URL qui intègre le style :
|
||||
> rewrite ^(.+\.gmi)$ /htmgem/index.php?rw=1&url=$1;
|
||||
> rewrite ^(.+\.gmi)\ *\|\ *([\w_]+)$ /htmgem/index.php?rw=1&url=$1&style=$2;
|
||||
|
||||
Par exemple, lorsque ce sera activé :
|
||||
=> configuration-fr.gmi%20|%20pre Produit le code source de façon lisble à l’écran en utilisant la balise **<pre>**.
|
||||
=> configuration-fr.gmi%20|%20source configuration-fr.gmi | source : Téléverse le code source.
|
||||
|
||||
### Avec les styles déjà fournis…
|
||||
|
||||
=> configuration-fr.gmi%20|%20htmgem Style //HtmHem//, le style par défaut
|
||||
=> configuration-fr.gmi%20|%20none Style //none//
|
||||
=> configuration-fr.gmi%20|%20terminal Style //terminal//
|
||||
=> configuration-fr.gmi%20|%20black_wide Style //black wide//
|
||||
=> configuration-fr.gmi%20|%20simple Style //simple//
|
||||
=> configuration-fr.gmi%20|%20raw Style //brut//
|
||||
=> configuration-fr.gmi%20|%20debug Style //debug//
|
||||
|
||||
=> ../css Sélecteur de style : la page contenant les styles permet de les essayer 😎
|
||||
|
||||
## Décoration du texte
|
||||
|
||||
La décoration du texte, qui interprête le **gras** par exemple, ne fait pas partie de la définition de GemText. La décoration du texte s’applique partout sauf sur les titres et blocs préformatés.
|
||||
|
||||
### Désactiver la décoration du texte
|
||||
|
||||
On peut :
|
||||
* désactiver et activer la décoration du texte avec une ligne **^^^**,
|
||||
* ajouter ce qui suit à la **réécriture** d’URL :
|
||||
> &textDecoration=0
|
||||
|
||||
## BNF / Syntax
|
||||
|
||||
HtmGem utilise une implémentation précise de la BNF de GemText. Il indique exactement quelle portions de texte doivent être utilisées.
|
||||
=> BNF-fr.gmi BNF
|
||||
|
||||
=> tutogemtext-fr.gmi Comment faire des pages GemText ?
|
||||
|
||||
———————————————————— ————————————————————
|
||||
|
||||
Parmi les fichiers et répertoires distribués, seuls sont utiles pour le fonctionnement de HtmGem :
|
||||
* **htmgem/*.php** : Ces fichiers se chargent de traduire le GemText en HTML.
|
||||
* **htmgem/css/htmgem.css** : S’il manque, l’affichage sera dépourvu de style — littéralement.
|
||||
* **htmgem/css/…** : Conservez les styles que vous utilisez.
|
||||
Les autres peuvent être supprimés (y compris ce présent fichier //configuration-fr.gmi//) bien qu’ils ne présentent aucun danger.
|
||||
|
|
@ -1,9 +1,14 @@
|
|||
# Developers' documentation
|
||||
|
||||
=> BNF-en.gmi BNF / Backus-Naur Form
|
||||
# Documentation
|
||||
|
||||
=> https://gmi.sbgodin.fr/htmgem Project main page
|
||||
=> https://tildegit.org/Sbgodin/htmgem Source code, comments
|
||||
=> https://gemini.circumlunar.space Main Gemini capsule
|
||||
|
||||
=> ../CHANGELOG.gmi Change log
|
||||
=> ../COPYING.gmi Licence Gnu Affero General Public License v3 — 19 november 2007
|
||||
=> ../COPYING.gmi License Gnu Affero General Public License v3 — 19 november 2007
|
||||
=> BNF.gmi BNF / Backus-Naur Form
|
||||
=> specification_Gemini_v0.16.1.gmi Specification Gemini v0.16.1 (no impact on HtmGem)
|
||||
=> specification_Gemini_v0.14.3.gmi Specification Gemini v0.14.3
|
||||
|
||||
=> ../css Styles 😎
|
||||
=> ../tests Tests 😅
|
||||
|
|
|
|||
|
|
@ -1,42 +1,50 @@
|
|||
# HtmGem, installation
|
||||
# To install HtmGem
|
||||
|
||||
To run HtmGem — after having copied the files — there is nothing to do but to add the URL rewriting rules.
|
||||
* Download HtmGem
|
||||
=> https://tildegit.org/sbgodin/HtmGem/archive/master.zip
|
||||
* Copy the files at the root of the website.
|
||||
* Configurer la réécriture d’URL (//URL Rewriting//).
|
||||
* Write some text in /index.gmi.
|
||||
* Just open your website!
|
||||
|
||||
## Prerequisites
|
||||
* Go to /htmgem to get the documentation.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* Php v7.3 minimum
|
||||
* Module **php-mbstring** to manage unicode
|
||||
* A web server (Apache and Nginx tested)
|
||||
* Module **mod-rewrite** to handle the Gemini pages
|
||||
|
||||
## Installation
|
||||
|
||||
### Download
|
||||
=> https://tildegit.org/sbgodin/HtmGem/archive/master.zip Stable version
|
||||
=> https://tildegit.org/Sbgodin/htmgem Project repository
|
||||
* Module **Php-mbstring** to handle l’unicode
|
||||
* A web server (Apache and Nginx supported)
|
||||
* Module **mod-rewrite** for the URL rewriting
|
||||
|
||||
### Nginx
|
||||
```
|
||||
# This text must be placed in the server's configuration
|
||||
index index.gmi index.php index.html
|
||||
rewrite ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1;
|
||||
rewrite ^(.+\.gmi)$ /htmgem/index.php?rw=1&url=$1&style=default,htmgem.css;
|
||||
error_page 403 /htmgem;
|
||||
location = /favicon.ico { alias /var/www/dev/htmgem/favicon.ico; }
|
||||
```
|
||||
|
||||
### Apache
|
||||
```
|
||||
# This text can be placed at the root of the web site in a file ".htaccess".
|
||||
DirectoryIndex index.gmi index.php index.html
|
||||
RewriteEngine on
|
||||
RewriteRule ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1
|
||||
rewriteRule ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1&style=default,htmgem.css
|
||||
```
|
||||
|
||||
Afterwards,
|
||||
* When a file ends by **.gmi.** is asked, HtmGem will display it in the browser.
|
||||
* When only the directory is asked (http://site.tld/path) the file //index.gmi// will be automatically choosen.
|
||||
Other available styles:
|
||||
* style=lagrange,lagrange.css
|
||||
* style=lagrange,lagrange_gray.css
|
||||
* style=default,circumlunar.css
|
||||
* etc…
|
||||
|
||||
=> tutogemtext-en.gmi How to build GemText pages?
|
||||
## Text decoration
|
||||
|
||||
## Advanced configuration
|
||||
The text decoration, which interprets the bold for instance, is not part of GemText definition. The text decoration applies everywhere except on the titles and preformated texts.
|
||||
|
||||
Add additional styles as a link parameter or adapt the text decoration:
|
||||
=> configuration-en.gmi Advanced configuration
|
||||
It's possible to disable the text decoration with a line **^^^** or add to the URL rewriting:
|
||||
> &textDecoration=0
|
||||
|
||||
|
||||
=> ../css Styles
|
||||
|
||||
=> tutogemtext-en.gmi How to make GemText pages?
|
||||
|
|
|
|||
|
|
@ -1,42 +1,50 @@
|
|||
# HtmGem, installation
|
||||
# Pour installer HtmGem
|
||||
|
||||
Pour faire fonctionner HtmGem — après avoir copié les fichiers — il ne reste qu’à ajouter les règles de réécriture d’URL (//URL Rewriting//).
|
||||
* Télécharger HtmGem
|
||||
=> https://tildegit.org/sbgodin/HtmGem/archive/master.zip
|
||||
* Copier les fichiers à la racine du site.
|
||||
* Configurer la réécriture d’URL (//URL Rewriting//).
|
||||
* Écrire du texte dans /index.gmi.
|
||||
* Ouvrir la page du site!
|
||||
|
||||
* Accéder à /htmgem pour la documentation.
|
||||
|
||||
## Prérequis
|
||||
|
||||
* Php v7.3 minimum
|
||||
* Module **Php-mbstring** pour gérer l’unicode
|
||||
* Un serveur web (Apache et Nginx testés)
|
||||
* Module **mod-rewrite** pour prendre en charge les pages Gemini
|
||||
|
||||
## Installation
|
||||
|
||||
### Téléchargement
|
||||
=> https://tildegit.org/sbgodin/HtmGem/archive/master.zip Version stable
|
||||
=> https://tildegit.org/Sbgodin/htmgem Dépôt du projet
|
||||
* Un serveur web (Apache et Nginx supportés)
|
||||
* Module **mod-rewrite** pour la réécriture d’URL
|
||||
|
||||
### Nginx
|
||||
```
|
||||
# Ce texte doit être placé dans la configuration du serveur.
|
||||
index index.gmi index.php index.html
|
||||
rewrite ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1;
|
||||
rewrite ^(.+\.gmi)$ /htmgem/index.php?rw=1&url=$1&style=default,htmgem.css;
|
||||
error_page 403 /htmgem;
|
||||
location = /favicon.ico { alias /var/www/dev/htmgem/favicon.ico; }
|
||||
```
|
||||
|
||||
### Apache
|
||||
```
|
||||
# Ce texte peut se placer à la racine du site dans un fichier ".htaccess".
|
||||
DirectoryIndex index.gmi index.php index.html
|
||||
RewriteEngine on
|
||||
RewriteRule ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1
|
||||
rewriteRule ^(.+\.gmi)$ htmgem/index.php?rw=1&url=$1&style=default,htmgem.css
|
||||
```
|
||||
|
||||
Par la suite,
|
||||
* Quand un fichier se terminant par **.gmi** sera demandé, HtmGem l’affichera dans le navigateur.
|
||||
* Quand seul le répertoire sera demandé (http://site.tld/path) le fichier //index.gmi// sera automatiquement choisi.
|
||||
Autres styles disponibles :
|
||||
* style=lagrange,lagrange.css
|
||||
* style=lagrange,lagrange_gray.css
|
||||
* style=default,circumlunar.css
|
||||
* etc…
|
||||
|
||||
## Décoration du texte
|
||||
|
||||
La décoration du texte, qui interprête le **gras** par exemple, ne fait pas partie de la définition de GemText. La décoration du texte s’applique partout sauf sur les titres et blocs préformatés.
|
||||
|
||||
On peut désactiver la décoration du texte avec une ligne **^^^** ou ajouter à la **réécriture** d’URL :
|
||||
> &textDecoration=0
|
||||
|
||||
|
||||
=> ../css Styles
|
||||
|
||||
=> tutogemtext-fr.gmi Comment faire des pages GemText ?
|
||||
|
||||
## Configuration avancée
|
||||
|
||||
Ajoutez des styles supplémentaires en paramètre de lien ou adaptez la décoration du texte :
|
||||
=> configuration-fr.gmi Configuration avancée
|
||||
|
|
|
|||
|
|
@ -0,0 +1,355 @@
|
|||
```
|
||||
NOTE: this page was downloaded on 2021-03-04 from the original capsule
|
||||
gemini://gemini.circumlunar.space/docs/specification.gmi Gemini
|
||||
https://gemini.circumlunar.space/docs/specification.gmi Web
|
||||
```
|
||||
^^^
|
||||
|
||||
# Project Gemini
|
||||
|
||||
## Speculative specification
|
||||
|
||||
v0.14.3, November 29th 2020
|
||||
|
||||
This is an increasingly less rough sketch of an actual spec for Project Gemini. Although not finalised yet, further changes to the specification are likely to be relatively small. You can write code to this pseudo-specification and be confident that it probably won't become totally non-functional due to massive changes next week, but you are still urged to keep an eye on ongoing development of the protocol and make changes as required.
|
||||
|
||||
This is provided mostly so that people can quickly get up to speed on what I'm thinking without having to read lots and lots of old phlog posts and keep notes.
|
||||
|
||||
Feedback on any part of this is extremely welcome, please email solderpunk@posteo.net.
|
||||
|
||||
# 1 Overview
|
||||
|
||||
Gemini is a client-server protocol featuring request-response transactions, broadly similar to gopher or HTTP. Connections are closed at the end of a single transaction and cannot be reused. When Gemini is served over TCP/IP, servers should listen on port 1965 (the first manned Gemini mission, Gemini 3, flew in March '65). This is an unprivileged port, so it's very easy to run a server as a "nobody" user, even if e.g. the server is written in Go and so can't drop privileges in the traditional fashion.
|
||||
|
||||
## 1.1 Gemini transactions
|
||||
|
||||
There is one kind of Gemini transaction, roughly equivalent to a gopher request or a HTTP "GET" request. Transactions happen as follows:
|
||||
|
||||
C: Opens connection
|
||||
S: Accepts connection
|
||||
C/S: Complete TLS handshake (see section 4)
|
||||
C: Validates server certificate (see 4.2)
|
||||
C: Sends request (one CRLF terminated line) (see section 2)
|
||||
S: Sends response header (one CRLF terminated line), closes connection
|
||||
under non-success conditions (see 3.1 and 3.2)
|
||||
S: Sends response body (text or binary data) (see 3.3)
|
||||
S: Closes connection
|
||||
C: Handles response (see 3.4)
|
||||
|
||||
## 1.2 Gemini URI scheme
|
||||
|
||||
Resources hosted via Gemini are identified using URIs with the scheme "gemini". This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986, but does not support all components of the generic syntax. In particular, the authority component is allowed and required, but its userinfo subcomponent is NOT allowed. The host subcomponent is required. The port subcomponent is optional, with a default value of 1965. The path, query and fragment components are allowed and have no special meanings beyond those defined by the generic syntax. Spaces in gemini URIs should be encoded as %20, not +.
|
||||
|
||||
# 2 Gemini requests
|
||||
|
||||
Gemini requests are a single CRLF-terminated line with the following structure:
|
||||
|
||||
<URL><CR><LF>
|
||||
|
||||
<URL> is a UTF-8 encoded absolute URL, including a scheme, of maximum length 1024 bytes.
|
||||
|
||||
Sending an absolute URL instead of only a path or selector is effectively equivalent to building in a HTTP "Host" header. It permits virtual hosting of multiple Gemini domains on the same IP address. It also allows servers to optionally act as proxies. Including schemes other than "gemini" in requests allows servers to optionally act as protocol-translating gateways to e.g. fetch gopher resources over Gemini. Proxying is optional and the vast majority of servers are expected to only respond to requests for resources at their own domain(s).
|
||||
|
||||
# 3 Gemini responses
|
||||
|
||||
Gemini response consist of a single CRLF-terminated header line, optionally followed by a response body.
|
||||
|
||||
## 3.1 Response headers
|
||||
|
||||
Gemini response headers look like this:
|
||||
|
||||
<STATUS><SPACE><META><CR><LF>
|
||||
|
||||
<STATUS> is a two-digit numeric status code, as described below in 3.2 and in Appendix 1.
|
||||
|
||||
<SPACE> is a single space character, i.e. the byte 0x20.
|
||||
|
||||
<META> is a UTF-8 encoded string of maximum length 1024 bytes, whose meaning is <STATUS> dependent.
|
||||
|
||||
<STATUS> and <META> are separated by a single space character.
|
||||
|
||||
If <STATUS> does not belong to the "SUCCESS" range of codes, then the server MUST close the connection after sending the header and MUST NOT send a response body.
|
||||
|
||||
If a server sends a <STATUS> which is not a two-digit number or a <META> which exceeds 1024 bytes in length, the client SHOULD close the connection and disregard the response header, informing the user of an error.
|
||||
|
||||
## 3.2 Status codes
|
||||
|
||||
Gemini uses two-digit numeric status codes. Related status codes share the same first digit. Importantly, the first digit of Gemini status codes do not group codes into vague categories like "client error" and "server error" as per HTTP. Instead, the first digit alone provides enough information for a client to determine how to handle the response. By design, it is possible to write a simple but feature complete client which only looks at the first digit. The second digit provides more fine-grained information, for unambiguous server logging, to allow writing comfier interactive clients which provide a slightly more streamlined user interface, and to allow writing more robust and intelligent automated clients like content aggregators, search engine crawlers, etc.
|
||||
|
||||
The first digit of a response code unambiguously places the response into one of six categories, which define the semantics of the <META> line.
|
||||
|
||||
### 3.2.1 1x (INPUT)
|
||||
|
||||
Status codes beginning with 1 are INPUT status codes, meaning:
|
||||
|
||||
The requested resource accepts a line of textual user input. The <META> line is a prompt which should be displayed to the user. The same resource should then be requested again with the user's input included as a query component. Queries are included in requests as per the usual generic URL definition in RFC3986, i.e. separated from the path by a ?. Reserved characters used in the user's input must be "percent-encoded" as per RFC3986, and space characters should also be percent-encoded.
|
||||
|
||||
### 3.2.2 2x (SUCCESS)
|
||||
|
||||
Status codes beginning with 2 are SUCCESS status codes, meaning:
|
||||
|
||||
The request was handled successfully and a response body will follow the response header. The <META> line is a MIME media type which applies to the response body.
|
||||
|
||||
### 3.2.3 3x (REDIRECT)
|
||||
|
||||
Status codes beginning with 3 are REDIRECT status codes, meaning:
|
||||
|
||||
The server is redirecting the client to a new location for the requested resource. There is no response body. <META> is a new URL for the requested resource. The URL may be absolute or relative. The redirect should be considered temporary, i.e. clients should continue to request the resource at the original address and should not performance convenience actions like automatically updating bookmarks. There is no response body.
|
||||
|
||||
### 3.2.4 4x (TEMPORARY FAILURE)
|
||||
|
||||
Status codes beginning with 4 are TEMPORARY FAILURE status codes, meaning:
|
||||
|
||||
The request has failed. There is no response body. The nature of the failure is temporary, i.e. an identical request MAY succeed in the future. The contents of <META> may provide additional information on the failure, and should be displayed to human users.
|
||||
|
||||
### 3.2.5 5x (PERMANENT FAILURE)
|
||||
|
||||
Status codes beginning with 5 are PERMANENT FAILURE status codes, meaning:
|
||||
|
||||
The request has failed. There is no response body. The nature of the failure is permanent, i.e. identical future requests will reliably fail for the same reason. The contents of <META> may provide additional information on the failure, and should be displayed to human users. Automatic clients such as aggregators or indexing crawlers should not repeat this request.
|
||||
|
||||
### 3.2.6 6x (CLIENT CERTIFICATE REQUIRED)
|
||||
|
||||
Status codes beginning with 6 are CLIENT CERTIFICATE REQUIRED status codes, meaning:
|
||||
|
||||
The requested resource requires a client certificate to access. If the request was made without a certificate, it should be repeated with one. If the request was made with a certificate, the server did not accept it and the request should be repeated with a different certificate. The contents of <META> (and/or the specific 6x code) may provide additional information on certificate requirements or the reason a certificate was rejected.
|
||||
|
||||
### 3.2.7 Notes
|
||||
|
||||
Note that for basic interactive clients for human use, errors 4 and 5 may be effectively handled identically, by simply displaying the contents of <META> under a heading of "ERROR". The temporary/permanent error distinction is primarily relevant to well-behaving automated clients. Basic clients may also choose not to support client-certificate authentication, in which case only four distinct status handling routines are required (for statuses beginning with 1, 2, 3 or a combined 4-or-5).
|
||||
|
||||
The full two-digit system is detailed in Appendix 1. Note that for each of the six valid first digits, a code with a second digit of zero corresponds is a generic status of that kind with no special semantics. This means that basic servers without any advanced functionality need only be able to return codes of 10, 20, 30, 40 or 50.
|
||||
|
||||
The Gemini status code system has been carefully designed so that the increased power (and correspondingly increased complexity) of the second digits is entirely "opt-in" on the part of both servers and clients.
|
||||
|
||||
## 3.3 Response bodies
|
||||
|
||||
Response bodies are just raw content, text or binary, ala gopher. There is no support for compression, chunking or any other kind of content or transfer encoding. The server closes the connection after the final byte, there is no "end of response" signal like gopher's lonely dot.
|
||||
|
||||
Response bodies only accompany responses whose header indicates a SUCCESS status (i.e. a status code whose first digit is 2). For such responses, <META> is a MIME media type as defined in RFC 2046.
|
||||
|
||||
Internet media types are registered with a canonical form. Content transferred via Gemini MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
|
||||
|
||||
When in canonical form, media subtypes of the "text" type use CRLF as the text line break. Gemini relaxes this requirement and allows the transport of text media with plain LF alone (but NOT a plain CR alone) representing a line break when it is done consistently for an entire response body. Gemini clients MUST accept CRLF and bare LF as being representative of a line break in text media received via Gemini.
|
||||
|
||||
If a MIME type begins with "text/" and no charset is explicitly given, the charset should be assumed to be UTF-8. Compliant clients MUST support UTF-8-encoded text/* responses. Clients MAY optionally support other encodings. Clients receiving a response in a charset they cannot decode SHOULD gracefully inform the user what happened instead of displaying garbage.
|
||||
|
||||
If <META> is an empty string, the MIME type MUST default to "text/gemini; charset=utf-8". The text/gemini media type is defined in section 5.
|
||||
|
||||
## 3.4 Response body handling
|
||||
|
||||
Response handling by clients should be informed by the provided MIME type information. Gemini defines one MIME type of its own (text/gemini) whose handling is discussed below in section 5. In all other cases, clients should do "something sensible" based on the MIME type. Minimalistic clients might adopt a strategy of printing all other text/* responses to the screen without formatting and saving all non-text responses to the disk. Clients for unix systems may consult /etc/mailcap to find installed programs for handling non-text types.
|
||||
|
||||
# 4 TLS
|
||||
|
||||
Use of TLS for Gemini transactions is mandatory.
|
||||
|
||||
Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting.
|
||||
|
||||
## 4.1 Version requirements
|
||||
|
||||
Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version 1.3 or higher. TLS 1.2 is reluctantly permitted for now to avoid drastically reducing the range of available implementation libraries. Hopefully TLS 1.3 or higher can be specced in the near future. Clients who wish to be "ahead of the curve MAY refuse to connect to servers using TLS version 1.2 or lower.
|
||||
|
||||
## 4.2 Server certificate validation
|
||||
|
||||
Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
|
||||
|
||||
TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
|
||||
|
||||
This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
|
||||
|
||||
## 4.3 Client certificates
|
||||
|
||||
Although rarely seen on the web, TLS permits clients to identify themselves to servers using certificates, in exactly the same way that servers traditionally identify themselves to the client. Gemini includes the ability for servers to request in-band that a client repeats a request with a client certificate. This is a very flexible, highly secure but also very simple notion of client identity with several applications:
|
||||
|
||||
* Short-lived client certificates which are generated on demand and deleted immediately after use can be used as "session identifiers" to maintain server-side state for applications. In this role, client certificates act as a substitute for HTTP cookies, but unlike cookies they are generated voluntarily by the client, and once the client deletes a certificate and its matching key, the server cannot possibly "resurrect" the same value later (unlike so-called "super cookies").
|
||||
* Long-lived client certificates can reliably identify a user to a multi-user application without the need for passwords which may be brute-forced. Even a stolen database table mapping certificate hashes to user identities is not a security risk, as rainbow tables for certificates are not feasible.
|
||||
* Self-hosted, single-user applications can be easily and reliably secured in a manner familiar from OpenSSH: the user generates a self-signed certificate and adds its hash to a server-side list of permitted certificates, analogous to the .authorized_keys file for SSH).
|
||||
|
||||
Gemini requests will typically be made without a client certificate. If a requested resource requires a client certificate and one is not included in a request, the server can respond with a status code of 60, 61 or 62 (see Appendix 1 below for a description of all status codes related to client certificates). A client certificate which is generated or loaded in response to such a status code has its scope bound to the same hostname as the request URL and to all paths below the path of the request URL path. E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc., until such time as the user decides to delete the certificate or to temporarily deactivate it. Interactive clients for human users are strongly recommended to make such actions easy and to generally give users full control over the use of client certificates.
|
||||
|
||||
# 5 The text/gemini media type
|
||||
|
||||
## 5.1 Overview
|
||||
|
||||
In the same sense that HTML is the "native" response format of HTTP and plain text is the native response format of gopher, Gemini defines its own native response format - though of course, thanks to the inclusion of a MIME type in the response header Gemini can be used to serve plain text, rich text, HTML, Markdown, LaTeX, etc.
|
||||
|
||||
Response bodies of type "text/gemini" are a kind of lightweight hypertext format, which takes inspiration from gophermaps and from Markdown. The format permits richer typographic possibilities than the plain text of Gopher, but remains extremely easy to parse. The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently. As per gopher, links can only be displayed one per line, encouraging neat, list-like structure.
|
||||
|
||||
Similar to how the two-digit Gemini status codes were designed so that simple clients can function correctly while ignoring the second digit, the text/gemini format has been designed so that simple clients can ignore the more advanced features and still remain very usable.
|
||||
|
||||
## 5.2 Parameters
|
||||
|
||||
As a subtype of the top-level media type "text", "text/gemini" inherits the "charset" parameter defined in RFC 2046. However, as noted in 3.3, the default value of "charset" is "UTF-8" for "text" content transferred via Gemini.
|
||||
|
||||
A single additional parameter specific to the "text/gemini" subtype is defined: the "lang" parameter. The value of "lang" denotes the natural language or language(s) in which the textual content of a "text/gemini" document is written. The presence of the "lang" parameter is optional. When the "lang" parameter is present, its interpretation is defined entirely by the client. For example, clients which use text-to-speech technology to make Gemini content accessible to visually impaired users may use the value of "lang" to improve pronunciation of content. Clients which render text to a screen may use the value of "lang" to determine whether text should be displayed left-to-right or right-to-left. Simple clients for users who only read languages written left-to-right may simply ignore the value of "lang". When the "lang" parameter is not present, no default value should be assumed and clients which require some notion of a language in order to process the content (such as text-to-speech screen readers) should rely on user-input to determine how to proceed in the absence of a "lang" parameter.
|
||||
|
||||
Valid values for the "lang" parameter are comma-separated lists of one or more language tags as defined in RFC4646. For example:
|
||||
|
||||
* "text/gemini; lang=en" Denotes a text/gemini document written in English
|
||||
* "text/gemini; lang=fr" Denotes a text/gemini document written in French
|
||||
* "text/gemini; lang=en,fr" Denotes a text/gemini document written in a mixture of English and French
|
||||
* "text/gemini; lang=de-CH" Denotes a text/gemini document written in Swiss German
|
||||
* "text/gemini; lang=sr-Cyrl" Denotes a text/gemini document written in Serbian using the Cyrllic script
|
||||
* "text/gemini; lang=zh-Hans-CN" Denotes a text/gemini document written in Chinese using the Simplified script as used in mainland China
|
||||
|
||||
## 5.3 Line-orientation
|
||||
|
||||
As mentioned, the text/gemini format is line-oriented. Each line of a text/gemini document has a single "line type". It is possible to unambiguously determine a line's type purely by inspecting its first three characters. A line's type determines the manner in which it should be presented to the user. Any details of presentation or rendering associated with a particular line type are strictly limited in scope to that individual line.
|
||||
|
||||
There are 7 different line types in total. However, a fully functional and specification compliant Gemini client need only recognise and handle 4 of them - these are the "core line types", (see 5.4). Advanced clients can also handle the additional "advanced line types" (see 5.5). Simple clients can treat all advanced line types as equivalent to one of the core line types and still offer an adequate user experience.
|
||||
|
||||
## 5.4 Core line types
|
||||
|
||||
The four core line types are:
|
||||
|
||||
### 5.4.1 Text lines
|
||||
|
||||
Text lines are the most fundamental line type - any line which does not match the definition of another line type defined below defaults to being a text line. The majority of lines in a typical text/gemini document will be text lines.
|
||||
|
||||
Text lines should be presented to the user, after being wrapped to the appropriate width for the client's viewport (see below). Text lines may be presented to the user in a visually pleasing manner for general reading, the precise meaning of which is at the client's discretion. For example, variable width fonts may be used, spacing may be normalised, with spaces between sentences being made wider than spacing between words, and other such typographical niceties may be applied. Clients may permit users to customise the appearance of text lines by altering the font, font size, text and background colour, etc. Authors should not expect to exercise any control over the precise rendering of their text lines, only of their actual textual content. Content such as ASCII art, computer source code, etc. which may appear incorrectly when treated as such should be enclosed between preformatting toggle lines (see 5.4.3).
|
||||
|
||||
Blank lines are instances of text lines and have no special meaning. They should be rendered individually as vertical blank space each time they occur. In this way they are analogous to <br/> tags in HTML. Consecutive blank lines should NOT be collapsed into a fewer blank lines. Note also that consecutive non-blank text lines do not form any kind of coherent unit or block such as a "paragraph": all text lines are independent entities.
|
||||
|
||||
Text lines which are longer than can fit on a client's display device SHOULD be "wrapped" to fit, i.e. long lines should be split (ideally at whitespace or at hyphens) into multiple consecutive lines of a device-appropriate width. This wrapping is applied to each line of text independently. Multiple consecutive lines which are shorter than the client's display device MUST NOT be combined into fewer, longer lines.
|
||||
|
||||
In order to take full advantage of this method of text formatting, authors of text/gemini content SHOULD avoid hard-wrapping to a specific fixed width, in contrast to the convention in Gopherspace where text is typically wrapped at 80 characters or fewer. Instead, text which should be displayed as a contiguous block should be written as a single long line. Most text editors can be configured to "soft-wrap", i.e. to write this kind of file while displaying the long lines wrapped at word boundaries to fit the author's display device.
|
||||
|
||||
Authors who insist on hard-wrapping their content MUST be aware that the content will display neatly on clients whose display device is as wide as the hard-wrapped length or wider, but will appear with irregular line widths on narrower clients.
|
||||
|
||||
### 5.4.2 Link lines
|
||||
|
||||
Lines beginning with the two characters "=>" are link lines, which have the following syntax:
|
||||
|
||||
```
|
||||
=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
|
||||
```
|
||||
|
||||
where:
|
||||
|
||||
* <whitespace> is any non-zero number of consecutive spaces or tabs
|
||||
* Square brackets indicate that the enclosed content is optional.
|
||||
* <URL> is a URL, which may be absolute or relative.
|
||||
|
||||
All the following examples are valid link lines:
|
||||
|
||||
```
|
||||
=> gemini://example.org/
|
||||
=> gemini://example.org/ An example link
|
||||
=> gemini://example.org/foo Another example link at the same host
|
||||
=> foo/bar/baz.txt A relative link
|
||||
=> gopher://example.org:70/1 A gopher link
|
||||
```
|
||||
|
||||
URLs in link lines must have reserved characters and spaces percent-encoded as per RFC 3986.
|
||||
|
||||
Note that link URLs may have schemes other than gemini. This means that Gemini documents can simply and elegantly link to documents hosted via other protocols, unlike gophermaps which can only link to non-gopher content via a non-standard adaptation of the `h` item-type.
|
||||
|
||||
Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).
|
||||
|
||||
### 5.4.3 Preformatting toggle lines
|
||||
|
||||
Any line whose first three characters are "```" (i.e. three consecutive back ticks with no leading whitespace) are preformatted toggle lines. These lines should NOT be included in the rendered output shown to the user. Instead, these lines toggle the parser between preformatted mode being "on" or "off". Preformatted mode should be "off" at the beginning of a document. The current status of preformatted mode is the only internal state a parser is required to maintain. When preformatted mode is "on", the usual rules for identifying line types are suspended, and all lines should be identified as preformatted text lines (see 5.4.4).
|
||||
|
||||
Preformatting toggle lines can be thought of as analogous to <pre> and </pre> tags in HTML.
|
||||
|
||||
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting.
|
||||
|
||||
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode off MUST be ignored by clients.
|
||||
|
||||
### 5.4.4 Preformatted text lines
|
||||
|
||||
Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements. Graphical clients should use scrolling mechanisms to present preformatted text lines which are longer than the client viewport, in preference to wrapping. In displaying preformatted text lines, clients should keep in mind applications like ASCII art and computer source code: in particular, source code in languages with significant whitespace (e.g. Python) should be able to be copied and pasted from the client into a file and interpreted/compiled without any problems arising from the client's manner of displaying them.
|
||||
|
||||
## 5.5 Advanced line types
|
||||
|
||||
The following advanced line types MAY be recognised by advanced clients. Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function.
|
||||
|
||||
### 5.5.1 Heading lines
|
||||
|
||||
Lines beginning with "#" are heading lines. Heading lines consist of one, two or three consecutive "#" characters, followed by optional whitespace, followed by heading text. The number of # characters indicates the "level" of header; #, ## and ### can be thought of as analogous to <h1>, <h2> and <h3> in HTML.
|
||||
|
||||
Heading text should be presented to the user, and clients MAY use special formatting, e.g. a larger or bold font, to indicate its status as a header (simple clients may simply print the line, including its leading #s, without any styling at all). However, the main motivation for the definition of heading lines is not stylistic but to provide a machine-readable representation of the internal structure of the document. Advanced clients can use this information to, e.g. display an automatically generated and hierarchically formatted "table of contents" for a long document in a side-pane, allowing users to easily jump to specific sections without excessive scrolling. CMS-style tools automatically generating menus or Atom/RSS feeds for a directory of text/gemini files can use first
|
||||
heading in the file as a human-friendly title.
|
||||
|
||||
### 5.5.2 Unordered list items
|
||||
|
||||
Lines beginning with "* " are unordered list items. This line type exists purely for stylistic reasons. The * may be replaced in advanced clients by a bullet symbol. Any text after the "* " should be presented to the user as if it were a text line, i.e. wrapped to fit the viewport and formatted "nicely". Advanced clients can take the space of the bullet symbol into account when wrapping long list items to ensure that all lines of text corresponding to the item are offset an equal distance from the left of the screen.
|
||||
|
||||
### 5.5.3 Quote lines
|
||||
|
||||
Lines beginning with ">" are quote lines. This line type exists so that advanced clients may use distinct styling to convey to readers the important semantic information that certain text is being quoted from an external source. For example, when wrapping long lines to the the viewport, each resultant line may have a ">" symbol placed at the front.
|
||||
|
||||
# Appendix 1. Full two digit status codes
|
||||
|
||||
## 10 INPUT
|
||||
|
||||
As per definition of single-digit code 1 in 3.2.
|
||||
|
||||
## 11 SENSITIVE INPUT
|
||||
|
||||
As per status code 10, but for use with sensitive input such as passwords. Clients should present the prompt as per status code 10, but the user's input should not be echoed to the screen to prevent it being read by "shoulder surfers".
|
||||
|
||||
## 20 SUCCESS
|
||||
|
||||
As per definition of single-digit code 2 in 3.2.
|
||||
|
||||
## 30 REDIRECT - TEMPORARY
|
||||
|
||||
As per definition of single-digit code 3 in 3.2.
|
||||
|
||||
## 31 REDIRECT - PERMANENT
|
||||
|
||||
The requested resource should be consistently requested from the new URL provided in future. Tools like search engine indexers or content aggregators should update their configurations to avoid requesting the old URL, and end-user clients may automatically update bookmarks, etc. Note that clients which only pay attention to the initial digit of status codes will treat this as a temporary redirect. They will still end up at the right place, they just won't be able to make use of the knowledge that this redirect is permanent, so they'll pay a small performance penalty by having to follow the redirect each time.
|
||||
|
||||
## 40 TEMPORARY FAILURE
|
||||
|
||||
As per definition of single-digit code 4 in 3.2.
|
||||
|
||||
## 41 SERVER UNAVAILABLE
|
||||
|
||||
The server is unavailable due to overload or maintenance. (cf HTTP 503)
|
||||
|
||||
## 42 CGI ERROR
|
||||
|
||||
A CGI process, or similar system for generating dynamic content, died unexpectedly or timed out.
|
||||
|
||||
## 43 PROXY ERROR
|
||||
|
||||
A proxy request failed because the server was unable to successfully complete a transaction with the remote host. (cf HTTP 502, 504)
|
||||
|
||||
## 44 SLOW DOWN
|
||||
|
||||
Rate limiting is in effect. <META> is an integer number of seconds which the client must wait before another request is made to this server. (cf HTTP 429)
|
||||
|
||||
## 50 PERMANENT FAILURE
|
||||
|
||||
As per definition of single-digit code 5 in 3.2.
|
||||
|
||||
## 51 NOT FOUND
|
||||
|
||||
The requested resource could not be found but may be available in the future. (cf HTTP 404) (struggling to remember this important status code? Easy: you can't find things hidden at Area 51!)
|
||||
|
||||
## 52 GONE
|
||||
|
||||
The resource requested is no longer available and will not be available again. Search engines and similar tools should remove this resource from their indices. Content aggregators should stop requesting the resource and convey to their human users that the subscribed resource is gone. (cf HTTP 410)
|
||||
|
||||
## 53 PROXY REQUEST REFUSED
|
||||
|
||||
The request was for a resource at a domain not served by the server and the server does not accept proxy requests.
|
||||
|
||||
## 59 BAD REQUEST
|
||||
|
||||
The server was unable to parse the client's request, presumably due to a malformed request. (cf HTTP 400)
|
||||
|
||||
## 60 CLIENT CERTIFICATE REQUIRED
|
||||
|
||||
As per definition of single-digit code 6 in 3.2.
|
||||
|
||||
## 61 CERTIFICATE NOT AUTHORISED
|
||||
|
||||
The supplied client certificate is not authorised for accessing the particular requested resource. The problem is not with the certificate itself, which may be authorised for other resources.
|
||||
|
||||
## 62 CERTIFICATE NOT VALID
|
||||
|
||||
The supplied client certificate was not accepted because it is not valid. This indicates a problem with the certificate in and of itself, with no consideration of the particular requested resource. The most likely cause is that the certificate's validity start date is in the future or its expiry date has passed, but this code may also indicate an invalid signature, or a violation of a X509 standard requirements. The <META> should provide more information about the exact error.
|
||||
|
|
@ -0,0 +1,365 @@
|
|||
```
|
||||
NOTE: this page was downloaded on 2022-08-01 from the original capsule
|
||||
gemini://gemini.circumlunar.space/docs/specification.gmi Gemini
|
||||
https://gemini.circumlunar.space/docs/specification.gmi Web
|
||||
```
|
||||
^^^
|
||||
|
||||
# Project Gemini
|
||||
|
||||
## Speculative specification
|
||||
|
||||
v0.16.1, January 30th 2022
|
||||
|
||||
This is an increasingly less rough sketch of an actual spec for Project Gemini. Although not finalised yet, further changes to the specification are likely to be relatively small. You can write code to this pseudo-specification and be confident that it probably won't become totally non-functional due to massive changes next week, but you are still urged to keep an eye on ongoing development of the protocol and make changes as required.
|
||||
|
||||
This is provided mostly so that people can quickly get up to speed on what I'm thinking without having to read lots and lots of old phlog posts and keep notes.
|
||||
|
||||
Feedback on any part of this is extremely welcome, please email solderpunk@posteo.net.
|
||||
|
||||
# Conventions used in this document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14.
|
||||
|
||||
# 1 Overview
|
||||
|
||||
Gemini is a client-server protocol featuring request-response transactions, broadly similar to gopher or HTTP. Connections are closed at the end of a single transaction and cannot be reused. When Gemini is served over TCP/IP, servers should listen on port 1965 (the first manned Gemini mission, Gemini 3, flew in March '65). This is an unprivileged port, so it's very easy to run a server as a "nobody" user, even if e.g. the server is written in Go and so can't drop privileges in the traditional fashion.
|
||||
|
||||
## 1.1 Gemini transactions
|
||||
|
||||
There is one kind of Gemini transaction, roughly equivalent to a gopher request or a HTTP "GET" request. Transactions happen as follows:
|
||||
|
||||
C: Opens connection
|
||||
S: Accepts connection
|
||||
C/S: Complete TLS handshake (see section 4)
|
||||
C: Validates server certificate (see 4.2)
|
||||
C: Sends request (one CRLF terminated line) (see section 2)
|
||||
S: Sends response header (one CRLF terminated line), closes connection under non-success conditions (see 3.1 and 3.2)
|
||||
S: Sends response body (text or binary data) (see 3.3)
|
||||
S: Closes connection (including TLS close_notify, see section 4)
|
||||
C: Handles response (see 3.4)
|
||||
|
||||
Note that clients are not obligated to wait until the server closes the connection to begin handling the response. This is shown above only for simplicity/clarity, to emphasise that responsibility for closing the connection under typical conditions lies with the server and that the connection should be closed immediately after the completion of the response body.
|
||||
|
||||
## 1.2 Gemini URI scheme
|
||||
|
||||
Resources hosted via Gemini are identified using URIs with the scheme "gemini". This scheme is syntactically compatible with the generic URI syntax defined in RFC 3986, but does not support all components of the generic syntax. In particular, the authority component is allowed and required, but its userinfo subcomponent is NOT allowed. The host subcomponent is required. The port subcomponent is optional, with a default value of 1965. The path, query and fragment components are allowed and have no special meanings beyond those defined by the generic syntax. An empty path is equivalent to a path consisting only of "/". Spaces in paths should be encoded as %20, not as +.
|
||||
|
||||
Clients SHOULD normalise URIs (as per section 6.2.3 of RFC 3986) before sending requests (see section 2) and servers SHOULD normalise received URIs before processing a request.
|
||||
|
||||
# 2 Gemini requests
|
||||
|
||||
Gemini requests are a single CRLF-terminated line with the following structure:
|
||||
|
||||
<URL><CR><LF>
|
||||
|
||||
<URL> is a UTF-8 encoded absolute URL, including a scheme, of maximum length 1024 bytes. The request MUST NOT begin with a U+FEFF byte order mark.
|
||||
|
||||
Sending an absolute URL instead of only a path or selector is effectively equivalent to building in a HTTP "Host" header. It permits virtual hosting of multiple Gemini domains on the same IP address. It also allows servers to optionally act as proxies. Including schemes other than "gemini" in requests allows servers to optionally act as protocol-translating gateways to e.g. fetch gopher resources over Gemini. Proxying is optional and the vast majority of servers are expected to only respond to requests for resources at their own domain(s).
|
||||
|
||||
Clients MUST NOT send anything after the first occurrence of <CR><LF> in a request, and servers MUST ignore anything sent after the first occurrence of a <CR><LF>.
|
||||
|
||||
# 3 Gemini responses
|
||||
|
||||
Gemini response consist of a single CRLF-terminated header line, optionally followed by a response body.
|
||||
|
||||
## 3.1 Response headers
|
||||
|
||||
Gemini response headers look like this:
|
||||
|
||||
<STATUS><SPACE><META><CR><LF>
|
||||
|
||||
<STATUS> is a two-digit numeric status code, as described below in 3.2 and in Appendix 1.
|
||||
|
||||
<SPACE> is a single space character, i.e. the byte 0x20.
|
||||
|
||||
<META> is a UTF-8 encoded string of maximum length 1024 bytes, whose meaning is <STATUS> dependent.
|
||||
|
||||
The response header as a whole and <META> as a sub-string both MUST NOT begin with a U+FEFF byte order mark.
|
||||
|
||||
If <STATUS> does not belong to the "SUCCESS" range of codes, then the server MUST close the connection after sending the header and MUST NOT send a response body.
|
||||
|
||||
If a server sends a <STATUS> which is not a two-digit number or a <META> which exceeds 1024 bytes in length, the client SHOULD close the connection and disregard the response header, informing the user of an error.
|
||||
|
||||
## 3.2 Status codes
|
||||
|
||||
Gemini uses two-digit numeric status codes. Related status codes share the same first digit. Importantly, the first digit of Gemini status codes do not group codes into vague categories like "client error" and "server error" as per HTTP. Instead, the first digit alone provides enough information for a client to determine how to handle the response. By design, it is possible to write a simple but feature complete client which only looks at the first digit. The second digit provides more fine-grained information, for unambiguous server logging, to allow writing comfier interactive clients which provide a slightly more streamlined user interface, and to allow writing more robust and intelligent automated clients like content aggregators, search engine crawlers, etc.
|
||||
|
||||
The first digit of a response code unambiguously places the response into one of six categories, which define the semantics of the <META> line.
|
||||
|
||||
### 3.2.1 1x (INPUT)
|
||||
|
||||
Status codes beginning with 1 are INPUT status codes, meaning:
|
||||
|
||||
The requested resource accepts a line of textual user input. The <META> line is a prompt which should be displayed to the user. The same resource should then be requested again with the user's input included as a query component. Queries are included in requests as per the usual generic URL definition in RFC3986, i.e. separated from the path by a ?. Reserved characters used in the user's input must be "percent-encoded" as per RFC3986, and space characters should also be percent-encoded.
|
||||
|
||||
### 3.2.2 2x (SUCCESS)
|
||||
|
||||
Status codes beginning with 2 are SUCCESS status codes, meaning:
|
||||
|
||||
The request was handled successfully and a response body will follow the response header. The <META> line is a MIME media type which applies to the response body.
|
||||
|
||||
### 3.2.3 3x (REDIRECT)
|
||||
|
||||
Status codes beginning with 3 are REDIRECT status codes, meaning:
|
||||
|
||||
The server is redirecting the client to a new location for the requested resource. There is no response body. <META> is a new URL for the requested resource. The URL may be absolute or relative. If relative, it should be resolved against the URL used in the original request. If the URL used in the original request contained a query string, the client MUST NOT apply this string to the redirect URL, instead using the redirect URL "as is". The redirect should be considered temporary, i.e. clients should continue to request the resource at the original address and should not perform convenience actions like automatically updating bookmarks. There is no response body.
|
||||
|
||||
### 3.2.4 4x (TEMPORARY FAILURE)
|
||||
|
||||
Status codes beginning with 4 are TEMPORARY FAILURE status codes, meaning:
|
||||
|
||||
The request has failed. There is no response body. The nature of the failure is temporary, i.e. an identical request MAY succeed in the future. The contents of <META> may provide additional information on the failure, and should be displayed to human users.
|
||||
|
||||
### 3.2.5 5x (PERMANENT FAILURE)
|
||||
|
||||
Status codes beginning with 5 are PERMANENT FAILURE status codes, meaning:
|
||||
|
||||
The request has failed. There is no response body. The nature of the failure is permanent, i.e. identical future requests will reliably fail for the same reason. The contents of <META> may provide additional information on the failure, and should be displayed to human users. Automatic clients such as aggregators or indexing crawlers should not repeat this request.
|
||||
|
||||
### 3.2.6 6x (CLIENT CERTIFICATE REQUIRED)
|
||||
|
||||
Status codes beginning with 6 are CLIENT CERTIFICATE REQUIRED status codes, meaning:
|
||||
|
||||
The requested resource requires a client certificate to access. If the request was made without a certificate, it should be repeated with one. If the request was made with a certificate, the server did not accept it and the request should be repeated with a different certificate. The contents of <META> (and/or the specific 6x code) may provide additional information on certificate requirements or the reason a certificate was rejected.
|
||||
|
||||
### 3.2.7 Notes
|
||||
|
||||
Note that for basic interactive clients for human use, errors 4 and 5 may be effectively handled identically, by simply displaying the contents of <META> under a heading of "ERROR". The temporary/permanent error distinction is primarily relevant to well-behaving automated clients. Basic clients may also choose not to support client-certificate authentication, in which case only four distinct status handling routines are required (for statuses beginning with 1, 2, 3 or a combined 4-or-5).
|
||||
|
||||
The full two-digit system is detailed in Appendix 1. Note that for each of the six valid first digits, a code with a second digit of zero corresponds is a generic status of that kind with no special semantics. This means that basic servers without any advanced functionality need only be able to return codes of 10, 20, 30, 40 or 50.
|
||||
|
||||
The Gemini status code system has been carefully designed so that the increased power (and correspondingly increased complexity) of the second digits is entirely "opt-in" on the part of both servers and clients.
|
||||
|
||||
## 3.3 Response bodies
|
||||
|
||||
Response bodies are just raw content, text or binary, à la gopher. There is no support for compression, chunking or any other kind of content or transfer encoding. The server closes the connection after the final byte, there is no "end of response" signal like gopher's lonely dot.
|
||||
|
||||
Response bodies only accompany responses whose header indicates a SUCCESS status (i.e. a status code whose first digit is 2). For such responses, <META> is a MIME media type as defined in RFC 2046.
|
||||
|
||||
Internet media types are registered with a canonical form. Content transferred via Gemini MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
|
||||
|
||||
When in canonical form, media subtypes of the "text" type use CRLF as the text line break. Gemini relaxes this requirement and allows the transport of text media with plain LF alone (but NOT a plain CR alone) representing a line break when it is done consistently for an entire response body. Gemini clients MUST accept CRLF and bare LF as being representative of a line break in text media received via Gemini.
|
||||
|
||||
If a MIME type begins with "text/" and no charset is explicitly given, the charset should be assumed to be UTF-8. Compliant clients MUST support UTF-8-encoded text/* responses. Clients MAY optionally support other encodings. Clients receiving a response in a charset they cannot decode SHOULD gracefully inform the user what happened instead of displaying garbage.
|
||||
|
||||
If <META> is an empty string, the MIME type MUST default to "text/gemini; charset=utf-8". The text/gemini media type is defined in section 5.
|
||||
|
||||
## 3.4 Response body handling
|
||||
|
||||
Response handling by clients should be informed by the provided MIME type information. Gemini defines one MIME type of its own (text/gemini) whose handling is discussed below in section 5. In all other cases, clients should do "something sensible" based on the MIME type. Minimalistic clients might adopt a strategy of printing all other text/* responses to the screen without formatting and saving all non-text responses to the disk. Clients for unix systems may consult /etc/mailcap to find installed programs for handling non-text types.
|
||||
|
||||
# 4 TLS
|
||||
|
||||
Use of TLS for Gemini transactions is mandatory.
|
||||
|
||||
Use of the Server Name Indication (SNI) extension to TLS is also mandatory, to facilitate name-based virtual hosting.
|
||||
|
||||
As per RFCs 5246 and 8446, Gemini servers MUST send a TLS `close_notify` prior to closing the connection after sending a complete response. This is essential to disambiguate completed responses from responses closed prematurely due to network error or attack.
|
||||
|
||||
## 4.1 Version requirements
|
||||
|
||||
Servers MUST use TLS version 1.2 or higher and SHOULD use TLS version 1.3 or higher. TLS 1.2 is reluctantly permitted for now to avoid drastically reducing the range of available implementation libraries. Hopefully TLS 1.3 or higher can be specced in the near future. Clients who wish to be "ahead of the curve MAY refuse to connect to servers using TLS version 1.2 or lower.
|
||||
|
||||
## 4.2 Server certificate validation
|
||||
|
||||
Clients can validate TLS connections however they like (including not at all) but the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go).
|
||||
|
||||
TOFU stands for "Trust On First Use" and is public-key security model similar to that used by OpenSSH. The first time a Gemini client connects to a server, it accepts whatever certificate it is presented. That certificate's fingerprint and expiry date are saved in a persistent database (like the .known_hosts file for SSH), associated with the server's hostname. On all subsequent connections to that hostname, the received certificate's fingerprint is computed and compared to the one in the database. If the certificate is not the one previously received, but the previous certificate's expiry date has not passed, the user is shown a warning, analogous to the one web browser users are shown when receiving a certificate without a signature chain leading to a trusted CA.
|
||||
|
||||
This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally.
|
||||
|
||||
## 4.3 Client certificates
|
||||
|
||||
Although rarely seen on the web, TLS permits clients to identify themselves to servers using certificates, in exactly the same way that servers traditionally identify themselves to the client. Gemini includes the ability for servers to request in-band that a client repeats a request with a client certificate. This is a very flexible, highly secure but also very simple notion of client identity with several applications:
|
||||
|
||||
* Short-lived client certificates which are generated on demand and deleted immediately after use can be used as "session identifiers" to maintain server-side state for applications. In this role, client certificates act as a substitute for HTTP cookies, but unlike cookies they are generated voluntarily by the client, and once the client deletes a certificate and its matching key, the server cannot possibly "resurrect" the same value later (unlike so-called "super cookies").
|
||||
* Long-lived client certificates can reliably identify a user to a multi-user application without the need for passwords which may be brute-forced. Even a stolen database table mapping certificate hashes to user identities is not a security risk, as rainbow tables for certificates are not feasible.
|
||||
* Self-hosted, single-user applications can be easily and reliably secured in a manner familiar from OpenSSH: the user generates a self-signed certificate and adds its hash to a server-side list of permitted certificates, analogous to the .authorized_keys file for SSH).
|
||||
|
||||
Gemini requests will typically be made without a client certificate. If a requested resource requires a client certificate and one is not included in a request, the server can respond with a status code of 60, 61 or 62 (see Appendix 1 below for a description of all status codes related to client certificates). A client certificate which is generated or loaded in response to such a status code has its scope bound to the same hostname as the request URL and to all paths below the path of the request URL path. E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc., until such time as the user decides to delete the certificate or to temporarily deactivate it. Interactive clients for human users are strongly recommended to make such actions easy and to generally give users full control over the use of client certificates.
|
||||
|
||||
# 5 The text/gemini media type
|
||||
|
||||
## 5.1 Overview
|
||||
|
||||
In the same sense that HTML is the "native" response format of HTTP and plain text is the native response format of gopher, Gemini defines its own native response format - though of course, thanks to the inclusion of a MIME type in the response header Gemini can be used to serve plain text, rich text, HTML, Markdown, LaTeX, etc.
|
||||
|
||||
Response bodies of type "text/gemini" are a kind of lightweight hypertext format, which takes inspiration from gophermaps and from Markdown. The format permits richer typographic possibilities than the plain text of Gopher, but remains extremely easy to parse. The format is line-oriented, and a satisfactory rendering can be achieved with a single pass of a document, processing each line independently. As per gopher, links can only be displayed one per line, encouraging neat, list-like structure.
|
||||
|
||||
Similar to how the two-digit Gemini status codes were designed so that simple clients can function correctly while ignoring the second digit, the text/gemini format has been designed so that simple clients can ignore the more advanced features and still remain very usable.
|
||||
|
||||
## 5.2 Parameters
|
||||
|
||||
As a subtype of the top-level media type "text", "text/gemini" inherits the "charset" parameter defined in RFC 2046. However, as noted in 3.3, the default value of "charset" is "UTF-8" for "text" content transferred via Gemini.
|
||||
|
||||
A single additional parameter specific to the "text/gemini" subtype is defined: the "lang" parameter. The value of "lang" denotes the natural language or language(s) in which the textual content of a "text/gemini" document is written. The presence of the "lang" parameter is optional. When the "lang" parameter is present, its interpretation is defined entirely by the client. For example, clients which use text-to-speech technology to make Gemini content accessible to visually impaired users may use the value of "lang" to improve pronunciation of content. Clients which render text to a screen may use the value of "lang" to determine whether text should be displayed left-to-right or right-to-left. Simple clients for users who only read languages written left-to-right may simply ignore the value of "lang". When the "lang" parameter is not present, no default value should be assumed and clients which require some notion of a language in order to process the content (such as text-to-speech screen readers) should rely on user-input to determine how to proceed in the absence of a "lang" parameter.
|
||||
|
||||
Valid values for the "lang" parameter are comma-separated lists of one or more language tags as defined in BCP47. For example:
|
||||
|
||||
* "text/gemini; lang=en" Denotes a text/gemini document written in English
|
||||
* "text/gemini; lang=fr" Denotes a text/gemini document written in French
|
||||
* "text/gemini; lang=en,fr" Denotes a text/gemini document written in a mixture of English and French
|
||||
* "text/gemini; lang=de-CH" Denotes a text/gemini document written in Swiss German
|
||||
* "text/gemini; lang=sr-Cyrl" Denotes a text/gemini document written in Serbian using the Cyrllic script
|
||||
* "text/gemini; lang=zh-Hans-CN" Denotes a text/gemini document written in Chinese using the Simplified script as used in mainland China
|
||||
|
||||
## 5.3 Line-orientation
|
||||
|
||||
As mentioned, the text/gemini format is line-oriented. Each line of a text/gemini document has a single "line type". It is possible to unambiguously determine a line's type purely by inspecting its first three characters. A line's type determines the manner in which it should be presented to the user. Any details of presentation or rendering associated with a particular line type are strictly limited in scope to that individual line.
|
||||
|
||||
There are 7 different line types in total. However, a fully functional and specification compliant Gemini client need only recognise and handle 4 of them - these are the "core line types", (see 5.4). Advanced clients can also handle the additional "advanced line types" (see 5.5). Simple clients can treat all advanced line types as equivalent to one of the core line types and still offer an adequate user experience.
|
||||
|
||||
## 5.4 Core line types
|
||||
|
||||
The four core line types are:
|
||||
|
||||
### 5.4.1 Text lines
|
||||
|
||||
Text lines are the most fundamental line type - any line which does not match the definition of another line type defined below defaults to being a text line. The majority of lines in a typical text/gemini document will be text lines.
|
||||
|
||||
Text lines should be presented to the user, after being wrapped to the appropriate width for the client's viewport (see below). Text lines may be presented to the user in a visually pleasing manner for general reading, the precise meaning of which is at the client's discretion. For example, variable width fonts may be used, spacing may be normalised, with spaces between sentences being made wider than spacing between words, and other such typographical niceties may be applied. Clients may permit users to customise the appearance of text lines by altering the font, font size, text and background colour, etc. Authors should not expect to exercise any control over the precise rendering of their text lines, only of their actual textual content. Content such as ASCII art, computer source code, etc. which may appear incorrectly when treated as such should be enclosed between preformatting toggle lines (see 5.4.3).
|
||||
|
||||
Blank lines are instances of text lines and have no special meaning. They should be rendered individually as vertical blank space each time they occur. In this way they are analogous to <br/> tags in HTML. Consecutive blank lines should NOT be collapsed into fewer blank lines. Note also that consecutive non-blank text lines do not form any kind of coherent unit or block such as a "paragraph": all text lines are independent entities.
|
||||
|
||||
Text lines which are longer than can fit on a client's display device SHOULD be "wrapped" to fit, i.e. long lines should be split (ideally at whitespace or at hyphens) into multiple consecutive lines of a device-appropriate width. This wrapping is applied to each line of text independently. Multiple consecutive lines which are shorter than the client's display device MUST NOT be combined into fewer, longer lines.
|
||||
|
||||
In order to take full advantage of this method of text formatting, authors of text/gemini content SHOULD avoid hard-wrapping to a specific fixed width, in contrast to the convention in Gopherspace where text is typically wrapped at 80 characters or fewer. Instead, text which should be displayed as a contiguous block should be written as a single long line. Most text editors can be configured to "soft-wrap", i.e. to write this kind of file while displaying the long lines wrapped at word boundaries to fit the author's display device.
|
||||
|
||||
Authors who insist on hard-wrapping their content MUST be aware that the content will display neatly on clients whose display device is as wide as the hard-wrapped length or wider, but will appear with irregular line widths on narrower clients.
|
||||
|
||||
### 5.4.2 Link lines
|
||||
|
||||
Lines beginning with the two characters "=>" are link lines, which have the following syntax:
|
||||
|
||||
```
|
||||
=>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]
|
||||
```
|
||||
|
||||
where:
|
||||
|
||||
* <whitespace> is any non-zero number of consecutive spaces or tabs
|
||||
* Square brackets indicate that the enclosed content is optional.
|
||||
* <URL> is a URL, which may be absolute or relative.
|
||||
|
||||
All the following examples are valid link lines:
|
||||
|
||||
```
|
||||
=> gemini://example.org/
|
||||
=> gemini://example.org/ An example link
|
||||
=> gemini://example.org/foo Another example link at the same host
|
||||
=> foo/bar/baz.txt A relative link
|
||||
=> gopher://example.org:70/1 A gopher link
|
||||
```
|
||||
|
||||
URLs in link lines must have reserved characters and spaces percent-encoded as per RFC 3986.
|
||||
|
||||
Note that link URLs may have schemes other than gemini. This means that Gemini documents can simply and elegantly link to documents hosted via other protocols, unlike gophermaps which can only link to non-gopher content via a non-standard adaptation of the `h` item-type.
|
||||
|
||||
Clients can present links to users in whatever fashion the client author wishes, however clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.).
|
||||
|
||||
### 5.4.3 Preformatting toggle lines
|
||||
|
||||
Any line whose first three characters are "```" (i.e. three consecutive back ticks with no leading whitespace) are preformatted toggle lines. These lines should NOT be included in the rendered output shown to the user. Instead, these lines toggle the parser between preformatted mode being "on" or "off". Preformatted mode should be "off" at the beginning of a document. The current status of preformatted mode is the only internal state a parser is required to maintain. When preformatted mode is "on", the usual rules for identifying line types are suspended, and all lines should be identified as preformatted text lines (see 5.4.4).
|
||||
|
||||
Preformatting toggle lines can be thought of as analogous to <pre> and </pre> tags in HTML.
|
||||
|
||||
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode on MAY be interpreted by the client as "alt text" pertaining to the preformatted text lines which follow the toggle line. Use of alt text is at the client's discretion, and simple clients may ignore it. Alt text is recommended for ASCII art or similar non-textual content which, for example, cannot be meaningfully understood when rendered through a screen reader or usefully indexed by a search engine. Alt text may also be used for computer source code to identify the programming language which advanced clients may use for syntax highlighting.
|
||||
|
||||
Any text following the leading "```" of a preformat toggle line which toggles preformatted mode off MUST be ignored by clients.
|
||||
|
||||
### 5.4.4 Preformatted text lines
|
||||
|
||||
Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements. Graphical clients should use scrolling mechanisms to present preformatted text lines which are longer than the client viewport, in preference to wrapping. In displaying preformatted text lines, clients should keep in mind applications like ASCII art and computer source code: in particular, source code in languages with significant whitespace (e.g. Python) should be able to be copied and pasted from the client into a file and interpreted/compiled without any problems arising from the client's manner of displaying them.
|
||||
|
||||
## 5.5 Advanced line types
|
||||
|
||||
The following advanced line types MAY be recognised by advanced clients. Simple clients may treat them all as text lines as per 5.4.1 without any loss of essential function.
|
||||
|
||||
### 5.5.1 Heading lines
|
||||
|
||||
Lines beginning with "#" are heading lines. Heading lines consist of one, two or three consecutive "#" characters, followed by optional whitespace, followed by heading text. The number of # characters indicates the "level" of header; #, ## and ### can be thought of as analogous to <h1>, <h2> and <h3> in HTML.
|
||||
|
||||
Heading text should be presented to the user, and clients MAY use special formatting, e.g. a larger or bold font, to indicate its status as a header (simple clients may simply print the line, including its leading #s, without any styling at all). However, the main motivation for the definition of heading lines is not stylistic but to provide a machine-readable representation of the internal structure of the document. Advanced clients can use this information to, e.g. display an automatically generated and hierarchically formatted "table of contents" for a long document in a side-pane, allowing users to easily jump to specific sections without excessive scrolling. CMS-style tools automatically generating menus or Atom/RSS feeds for a directory of text/gemini files can use the first heading in the file as a human-friendly title.
|
||||
|
||||
### 5.5.2 Unordered list items
|
||||
|
||||
Lines beginning with "* " are unordered list items. This line type exists purely for stylistic reasons. The * may be replaced in advanced clients by a bullet symbol. Any text after the "* " should be presented to the user as if it were a text line, i.e. wrapped to fit the viewport and formatted "nicely". Advanced clients can take the space of the bullet symbol into account when wrapping long list items to ensure that all lines of text corresponding to the item are offset an equal distance from the left of the screen.
|
||||
|
||||
### 5.5.3 Quote lines
|
||||
|
||||
Lines beginning with ">" are quote lines. This line type exists so that advanced clients may use distinct styling to convey to readers the important semantic information that certain text is being quoted from an external source. For example, when wrapping long lines to the viewport, each resultant line may have a ">" symbol placed at the front.
|
||||
|
||||
# Appendix 1. Full two digit status codes
|
||||
|
||||
## 10 INPUT
|
||||
|
||||
As per definition of single-digit code 1 in 3.2.
|
||||
|
||||
## 11 SENSITIVE INPUT
|
||||
|
||||
As per status code 10, but for use with sensitive input such as passwords. Clients should present the prompt as per status code 10, but the user's input should not be echoed to the screen to prevent it being read by "shoulder surfers".
|
||||
|
||||
## 20 SUCCESS
|
||||
|
||||
As per definition of single-digit code 2 in 3.2.
|
||||
|
||||
## 30 REDIRECT - TEMPORARY
|
||||
|
||||
As per definition of single-digit code 3 in 3.2.
|
||||
|
||||
## 31 REDIRECT - PERMANENT
|
||||
|
||||
The requested resource should be consistently requested from the new URL provided in future. Tools like search engine indexers or content aggregators should update their configurations to avoid requesting the old URL, and end-user clients may automatically update bookmarks, etc. Note that clients which only pay attention to the initial digit of status codes will treat this as a temporary redirect. They will still end up at the right place, they just won't be able to make use of the knowledge that this redirect is permanent, so they'll pay a small performance penalty by having to follow the redirect each time.
|
||||
|
||||
## 40 TEMPORARY FAILURE
|
||||
|
||||
As per definition of single-digit code 4 in 3.2.
|
||||
|
||||
## 41 SERVER UNAVAILABLE
|
||||
|
||||
The server is unavailable due to overload or maintenance. (cf HTTP 503)
|
||||
|
||||
## 42 CGI ERROR
|
||||
|
||||
A CGI process, or similar system for generating dynamic content, died unexpectedly or timed out.
|
||||
|
||||
## 43 PROXY ERROR
|
||||
|
||||
A proxy request failed because the server was unable to successfully complete a transaction with the remote host. (cf HTTP 502, 504)
|
||||
|
||||
## 44 SLOW DOWN
|
||||
|
||||
Rate limiting is in effect. <META> is an integer number of seconds which the client must wait before another request is made to this server. (cf HTTP 429)
|
||||
|
||||
## 50 PERMANENT FAILURE
|
||||
|
||||
As per definition of single-digit code 5 in 3.2.
|
||||
|
||||
## 51 NOT FOUND
|
||||
|
||||
The requested resource could not be found but may be available in the future. (cf HTTP 404) (struggling to remember this important status code? Easy: you can't find things hidden at Area 51!)
|
||||
|
||||
## 52 GONE
|
||||
|
||||
The resource requested is no longer available and will not be available again. Search engines and similar tools should remove this resource from their indices. Content aggregators should stop requesting the resource and convey to their human users that the subscribed resource is gone. (cf HTTP 410)
|
||||
|
||||
## 53 PROXY REQUEST REFUSED
|
||||
|
||||
The request was for a resource at a domain not served by the server and the server does not accept proxy requests.
|
||||
|
||||
## 59 BAD REQUEST
|
||||
|
||||
The server was unable to parse the client's request, presumably due to a malformed request. (cf HTTP 400)
|
||||
|
||||
## 60 CLIENT CERTIFICATE REQUIRED
|
||||
|
||||
As per definition of single-digit code 6 in 3.2.
|
||||
|
||||
## 61 CERTIFICATE NOT AUTHORISED
|
||||
|
||||
The supplied client certificate is not authorised for accessing the particular requested resource. The problem is not with the certificate itself, which may be authorised for other resources.
|
||||
|
||||
## 62 CERTIFICATE NOT VALID
|
||||
|
||||
The supplied client certificate was not accepted because it is not valid. This indicates a problem with the certificate in and of itself, with no consideration of the particular requested resource. The most likely cause is that the certificate's validity start date is in the future or its expiry date has passed, but this code may also indicate an invalid signature, or a violation of X509 standard requirements. The <META> should provide more information about the exact error.
|
||||
|
|
@ -71,4 +71,4 @@ HtmGem allows to host Gemini pages and publish them on a web server with **Php**
|
|||
### License of this page
|
||||
This page is under the free licence **CC BY-SA 2.0**.
|
||||
=> https://creativecommons.org/licenses/by-sa/2.0/en/ Text under license CC BY-SA 2.0
|
||||
=> gemini://gmi.sbgodin.fr/ gemini://gmi.sbgodin.fr/ ⸻ Christophe HENRY
|
||||
=> https://gmi.sbgodin.fr/ https://gmi.sbgodin.fr/ ⸻ Christophe HENRY
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ HtmGem permet d’héberger des pages Gemini et de les publier sur un serveur we
|
|||
=> https://gmi.sbgodin.fr/htmgem
|
||||
|
||||
|
||||
### License de cette page
|
||||
### Licence de cette page
|
||||
Cette page est sous licence libre **CC BY-SA 2.0**.
|
||||
=> https://creativecommons.org/licenses/by-sa/2.0/fr/ Texte sous licence CC BY-SA 2.0
|
||||
=> gemini://gmi.sbgodin.fr/ gemini://gmi.sbgodin.fr/ ⸻ Christophe HENRY
|
||||
=> https://gmi.sbgodin.fr/ https://gmi.sbgodin.fr/ ⸻ Christophe HENRY
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
24
index.gmi
24
index.gmi
|
|
@ -1,13 +1,19 @@
|
|||
# HtmGem
|
||||
```
|
||||
__ __ __ ______
|
||||
|\ \ |\ \ |\ \ /\ \ v1.5.0
|
||||
| ▓▓ | ▓▓_| ▓▓_ ______ ____ | ▓▓▓▓▓▓\
|
||||
| ▓▓__| ▓▓ ▓▓ \ |\ \ \| ▓▓ __\▓▓/\ \| \ \
|
||||
| ▓▓ ▓▓\▓▓▓▓▓▓ | ▓▓▓▓▓▓\▓▓▓▓\ ▓▓| \ ▓▓▓▓▓▓\ ▓▓▓▓▓▓\▓▓▓▓\
|
||||
| ▓▓▓▓▓▓▓▓ | ▓▓ __| ▓▓ | ▓▓ | ▓▓ ▓▓ \▓▓▓▓ ▓▓ ▓▓ ▓▓ | ▓▓ | ▓▓
|
||||
| ▓▓ | ▓▓ | ▓▓| \ ▓▓ | ▓▓ | ▓▓ ▓▓__| ▓▓ ▓▓▓▓▓▓▓▓ ▓▓ | ▓▓ | ▓▓
|
||||
| ▓▓ | ▓▓ \▓▓ ▓▓ ▓▓ | ▓▓ | ▓▓\▓▓ ▓▓\▓▓ \ ▓▓ | ▓▓ | ▓▓
|
||||
\▓▓ \▓▓ \▓▓▓▓ \▓▓ \▓▓ \▓▓ \▓▓▓▓▓▓ \▓▓▓▓▓▓▓\▓▓ \▓▓ \▓▓
|
||||
|
||||
=> docs/installation-fr.gmi Installation de HtmGem, en français
|
||||
HtmGem rend vos pages **Gemini** accessibles sur le web. Il fonctionne aussi en hébergement mutualisé.
|
||||
=> docs/tutogemtext-fr.gmi Tutoriel GemText
|
||||
```
|
||||
|
||||
=> docs/installation-en.gmi HtmGem installation, in English
|
||||
HtmGem makes your **Gemini** pages reachable on the web. It can be used on a shared host.
|
||||
=> docs/tutogemtext-en.gmi GemText tutorial
|
||||
=> docs/installation-fr.gmi 🇫🇷 HtmGem rend vos pages **Gemini** accessibles sur le web.
|
||||
|
||||
=> docs/installation-en.gmi 🇺🇸 HtmGem makes your **Gemini** pages reachable on the web.
|
||||
|
||||
|
||||
=> docs/index.gmi **Developers' documentation**
|
||||
The documentation (in English) for the developers's stands here. Please read them carefully before doing anything on the source code.
|
||||
=> docs/index.gmi 🇺🇸 **Documentation**
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
<head>
|
||||
<title>HtmGem</title>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||||
<link type='text/css' rel='StyleSheet' href='css/htmgem.css'>
|
||||
<link type='text/css' rel='StyleSheet' href='css/default/htmgem.css'>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HtmGem</h1>
|
||||
|
|
|
|||
28
index.php
28
index.php
|
|
@ -4,6 +4,8 @@ require_once "lib-htmgem.inc.php";
|
|||
require_once "lib-html.inc.php";
|
||||
require_once "lib-io.inc.php";
|
||||
|
||||
define("DEFAULT_CSS", "/css/default/htmgem.css");
|
||||
|
||||
$documentRoot = $_SERVER['DOCUMENT_ROOT'];
|
||||
$scheme = (@$_SERVER['REQUEST_SCHEME']??"http")."://";
|
||||
$domain = $_SERVER['HTTP_HOST'];
|
||||
|
|
@ -24,7 +26,7 @@ if (empty($url)) {
|
|||
http_response_code(403);
|
||||
} else {
|
||||
$gt_html = new \htmgem\GemTextTranslate_html(file_get_contents("index.gmi"), true, "$php_self?url=", $php_self_dir);
|
||||
if (empty($gt_html->getCss)) $gt_html->addCss($php_self_dir."/css/htmgem.css");
|
||||
if (empty($gt_html->getCss)) $gt_html->addCss($php_self_dir.DEFAULT_CSS);
|
||||
|
||||
// No URL Rewritting assumed
|
||||
echo \htmgem\html\getHtmlWithMenu($gt_html, $scheme, $domain, $php_self, "$php_self?url=");
|
||||
|
|
@ -91,7 +93,7 @@ if ("source" == $style) {
|
|||
header('Content-Length: ' . filesize($filePath));
|
||||
echo $fileContents;
|
||||
exit();
|
||||
} elseif ("pre" == $style) {
|
||||
} elseif ("src" == $style) {
|
||||
# Gets the page title: the first occurrence with # at the line start
|
||||
mb_ereg("#\s*([^\n]+)\n", $fileContents, $matches);
|
||||
$page_title = @$matches[1];
|
||||
|
|
@ -116,23 +118,11 @@ if ($urlRewriting)
|
|||
else
|
||||
$gt_html = new \htmgem\GemTextTranslate_html($fileContents, $gt_htmlextDecoration, "$php_self?url=", dirname($url));
|
||||
|
||||
if ("none" == $style) {
|
||||
#$gt_html->addCss("");
|
||||
} elseif ("/" == @$style[0]) {
|
||||
$gt_html->addCss($style);
|
||||
} elseif (empty($style)) {
|
||||
$parts = pathinfo($filePath);
|
||||
$localCss = $parts["filename"].".css";
|
||||
$localCssFilePath = $parts["dirname"]."/".$localCss;
|
||||
if (file_exists($localCssFilePath)) {
|
||||
# Warning, using htmhem.php?url=… will make $localCss not found
|
||||
# as the path is relative to htmgem.php and not / !
|
||||
$gt_html->addCss($localCss);
|
||||
} else { // No local style
|
||||
$gt_html->addCss($php_self_dir."/css/htmgem.css");
|
||||
}
|
||||
} else { #TODO: regex check for $style
|
||||
$gt_html->addCss("$php_self_dir/css/$style.css");
|
||||
if (empty($style)) {
|
||||
$gt_html->addCss($php_self_dir.DEFAULT_CSS);
|
||||
} else {
|
||||
$style = preg_replace("/,/", "/", $style);
|
||||
$gt_html->addCss("$php_self_dir/css/$style");
|
||||
}
|
||||
|
||||
if ($urlRewriting)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ namespace htmgem\html;
|
|||
mb_internal_encoding("UTF-8");
|
||||
mb_regex_encoding("UTF-8");
|
||||
|
||||
$txt_icon = "H͜͡m ";
|
||||
define("TXT_ICON", "H͜͡m ");
|
||||
|
||||
function getHeader(\htmgem\GemtextTranslate_html $gt_html) {
|
||||
$css = $gt_html->getCss();
|
||||
|
|
@ -36,7 +36,6 @@ function array_key_last_slice($array) {
|
|||
* @param $pageLink if not null, means no URL rewritting
|
||||
*/
|
||||
function getMenu(string $scheme, string $domain, string $path, string $prefix=null) {
|
||||
global $txt_icon;
|
||||
$links = \htmgem\split_path_links($path, $prefix);
|
||||
|
||||
// Removes the last part, as it won't hold a link
|
||||
|
|
@ -55,7 +54,7 @@ function getMenu(string $scheme, string $domain, string $path, string $prefix=nu
|
|||
}
|
||||
$linkList [] = $lastLink."\n"; // The last part holds no link
|
||||
$output = "<div class='menu-line'>\n";
|
||||
$output .= "<strong><a class='logo' href='/htmgem'>$txt_icon</a></strong>$scheme\n";
|
||||
$output .= "<strong><a class='logo' href='/htmgem'>".TXT_ICON."</a></strong>$scheme\n";
|
||||
$output .= implode(" / ", $linkList);
|
||||
$output .= "</div>\n";
|
||||
return $output;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
$fileName = $argv[1];
|
||||
|
||||
require_once dirname(__FILE__)."/../lib-htmgem.inc.php";
|
||||
require_once dirname(__FILE__)."/../../lib-htmgem.inc.php";
|
||||
|
||||
$text = file_get_contents($fileName);
|
||||
$parsedGemtext = \htmgem\gemtextParser($text);
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ exec('phpunit tests', $output, $returnCode);
|
|||
array_shift($output);
|
||||
|
||||
if ($returnCode !== 0) {
|
||||
echo PHP_EOL . implode($output, PHP_EOL) . PHP_EOL;
|
||||
echo PHP_EOL . implode(PHP_EOL, $output) . PHP_EOL;
|
||||
echo "Tests failed…" . PHP_EOL;
|
||||
exit(1);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
# Tests
|
||||
|
||||
This test suite aims to check the quality of the translation of the fulltext source pages to HTML pages. As usual, its purpose is to protect the project against regression. So these tests should be run before commits (see **./cli/precommit.git**).
|
||||
This test suite aims to check the quality of the translation of the fulltext source pages to HTML pages.
|
||||
|
||||
In the HtmGem root directory, just type **phpunit tests** to check.
|
||||
|
||||
### parserTest.php
|
||||
The parser takes the gemtext contained in the **.gmi** file and returns the internal format.
|
||||
|
|
@ -11,9 +13,10 @@ The translator takes the gemtext, parse it and returns an HTML representation.
|
|||
### translateToGemtextTest.php
|
||||
This translator takes the gemtext, parse it and rebuild the gemtext. The output must be identical of the input. When there are optional spaces, they are trimmed. In such cases, the translation will return a kind of normalised gemtext — that is, without the spaces.
|
||||
|
||||
### ./cli
|
||||
It contains files to play around with the API:
|
||||
### cli
|
||||
The directory contains files to play around with the API:
|
||||
* parse_gemtext: outputs a //print_r()// of the internal representation
|
||||
* translate_to_gemtext: outputs the regenerated gemtext
|
||||
* translate_to_html: outputs the html-ified gemtext
|
||||
//pre-commit.git// is to be moved to //./.git/hooks/pre-commit//, be //chmod x//-ed to run this test suit before committing.
|
||||
|
||||
//pre-commit.git// is to be moved to //./.git/hooks/pre-commit// and //chmod x//-ed to run this test suit before committing.
|
||||
|
|
|
|||
Loading…
Reference in New Issue