-
Notifications
You must be signed in to change notification settings - Fork 5
93 Basic Markdown and text formatting
This section lists all the Basic Markdown syntax for formatting text. This stuff is supported by (virtually) every Markdown processor.
It lists the Markdown syntax, the equivalent HTML (where possible) and shows the resultant output as rendered on GitHub.
In some cases there are alternative syntax options. I list these alternatives where they exist, but the main syntax (not the alternative options) is generally the preferred option.
Body text in Markdown is whatever text is on a line that is not formatted by some other instruction. This paragraph is body text and is rendered in the main GitHub Wiki window as shown below:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. In consectetur tortor a tortor ornare, non pretium diam faucibus. Morbi ut mollis dolor, nec pretium tellus. Suspendisse ornare neque placerat orci aliquam, eu sodales dui blandit. Maecenas nec risus vel magna blandit euismod. Suspendisse id finibus purus. Nam ultricies non sapien ac rutrum. |
Figure 93.1 — Body text on a GitHub Wiki page |
The GitHub site is responsive in terms of screen width and sidebar (the sidebar drops to the bottom of the page at lower resolutions), the text narrows and line-wraps as the screen narrows. It does not however, change point size.
GitHub body text is always 16px high and is in the Segoe UI font (on a Windows machine). The line spacing is fixed at 24px (giving a line spacing of 150% which is a bit big; most body text has line spacing in the range 120-145%).
The font colour is a dark grey colour (not black), it is in fact the RGB colour (31, 35, 40) or hex colour (#1F2328). It looks like this:
Figure 93.2 — Body text font colour |
GitHub displays the body text in a responsive manner, at browser screen widths of 1280px or more, the main area of the screen is shown at a full width that never exceeds 896px (this is as wide as it gets). At this width, the body text displays on average 21.2 words per line (this is based on the following extract):
In principle, liquid rocket engines are simple, far simpler than the internal combustion engine. Liquid fuel is pumped into a combustion chamber in the presence of liquid oxygen and a flame. It burns. That’s all there is to it. There are no crankshafts to turn, no pistons to drive. The burning fuel produces energy in the form of gases that exit through the rocket’s nozzle. The force the gases produce against the top of the engine is called thrust. The thrust is transmitted through the rocket’s structure and, if it is greater than the weight of the rocket, the rocket lifts off. Put in its most basic terms, for any rocket to work there are two things that must be done extremely well: The propellants must be brought together, and then they must burn smoothly. In the F-l, just pumping the propellants to the combustion chamber raised unprecedented demands. The F-l used liquid oxygen (LOX) and R.P.-1, a form of kerosene. The pumps, one for the fuel and one for the LOX, had to deliver the kerosene from the tankage to the combustion chamber at the rate of 15,741 gallons per minute, and the LOX at the rate of 24,811 gallons per minute. Driven by a 55,000-horsepower turbine, the pumps had to operate at drastically different temperatures: 60 degrees Fahrenheit for the fuel, –300 degrees for the LOX, while the turbine itself ran at 1,200 degrees. To complicate matters, the whole assembly had to be light and compact enough to fit on board the rocket and nonetheless sturdy enough to resist the pressures, vibrations, and other stresses of launch and flight. Developing the pumps was still not as hard as solving the second basic problem of rocket engines: making the propellants burn smoothly once they had reached the combustion chamber. The pumps brought the kerosene and the LOX to a circular metal slab three feet in diameter and about four inches thick, weighing 1,000 pounds, called the injector plate. The injector plate was pocked with 6,300 holes less than a quarter of an inch in diameter through which the kerosene and LOX entered the combustion chamber. Most of the propellant streams were arranged in groups of five. Two of the five, both kerosene, impinged on each other at a carefully defined distance below the top of the plate, forming a fan-shaped spray. The other three in each five-hole group were of LOX. These also impinged on one another, forming another fan. The two fans intersected. There, given the presence of a flame, they would combust. In the F-l, the combustion chamber was a barrel about thirty-six inches wide and thirty inches long, closed at one end by the injection plate and opening into a nozzle at the other end. A few seconds before ignition, four small pre-burners in the combustion chamber — pilot lights, in effect — were lit, providing a flame at the point of impingement. As the pumps screamed up to speed, valves snapped open and more than a ton of kerosene and two tons of liquid oxygen burst into the combustion chamber. Per second. The gases produced by their ignition roared out through the throat, the open bottom of the barrel, into the cone of the nozzle below. In the course of the few seconds from ignition to full power (mainstage), the interior of the combustion chamber went from ambient temperature to 5,000 degrees Fahrenheit. At the face of the injector plate, pressure went from zero to 1,150 pounds per square inch. Given that combination of propellants, pressures, and nozzle design, the force generated totalled 1.5 million pounds. In the first stage of a Saturn V, five F-l s were to ignite simultaneously and sustain mainstage combustion for 150 seconds.
This is an extract from “Race to the Moon”: Cox, Catherine Bly & Charles Murray (1989). Published by Simon and Schuster. There is a Kindle version by the same authors, but just called Apollo.
Below is a series of lowercase alphabets, also used for page metrics:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
In calculating the metrics for GitHub, a browser screen width in excess of 1280 pixels is assumed (i.e. the main window is at its full width).
Taking the first 29 lines of the above extract (these are complete lines and end with the phrase "to ignite simultaneously and sustain"), the metrics are:
Average number of words per line: | 21.2 |
Average number of characters per line: | 123 (including spaces) |
Lowercase alphabets: | 5.4 |
Table 93.1 — GitHub body text metrics |
By most publishing standards, these figures are way too high, the lines are too long for comfortable reading.
Some good rules of thumb are: to have between 9.5 to 15 words per line, this equates to 45-90 characters per line (including spaces) or between 2-3 lowercase alphabets (without spaces).
While it may be too high, we are however, stuck with it. GitHub determines these things.
Both sidebars and footers can have body text within them. Body text in sidebars and footers is smaller than that in the main window.
GitHub sidebar and footer body text is always 12px high (as opposed to 16px in the main body text) and has a line spacing of 18px (main body text line spacing 24px) or 150% (this is the same ratio as main body text).
There is no difference between body text in sidebars and in footers they are exactly the same.
- GitHub will ignore multiple consecutive spaces (it will treat them as a single space)
- Always leave a blank line between paragraphs (see below)
- Multiple blank lines will be ignored (treated as a single blank line)
- Never use the tab character
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
In principle, liquid rocket engines are simple, far simpler than the internal combustion engine. | <p>In principle, liquid rocket engines are simple, far simpler than the internal combustion engine.</p> | In principle, liquid rocket engines are simple, far simpler than the internal combustion engine. |
Table 93.2 — Body text example |
Markup does not allow for the alignment of body text (it is always left justified), it does however support HTML alignments:
<p align="right">Align text to the right</p>
Will force text to the right-hand side of the body text area, like this.
<p align="centre">Align text to the right</p>
Will centre the text in the area, like this.
MAIN WINDOW PROPERTIES | SIDEBAR AND FOOTER VARIATIONS | |
---|---|---|
Body text |
Font: Segoe UI Colour: rgb(31, 35, 40) #1F2328 Font size: 16px Line spacing: 24px (150%) Underlined: No |
Font: Segoe UI Colour: rgb(31, 35, 40) #1F2328 Font size: 12px Line spacing: 18px (150%) Underlined: No |
Table 93.3 — Body text properties |
Paragraphs and line breaks can be a bit hit and miss in Markdown; the following explains both:
Within Markdown, paragraphs have to be separated by a blank line, the following (on the left) will form two separate paragraphs (shown on the right):
MARKDOWN (with line numbers) | GITHUB OUTPUT |
---|---|
1 Paragraph 1 2 3 Paragraph 2 |
Paragraph 1 Paragraph 2 |
Figure 93.3 — Separate paragraphs |
Leaving out the blank line between paragraphs, causes the paragraphs to merge together:
MARKDOWN (with line numbers) | GITHUB OUTPUT |
---|---|
1 Paragraph 1 2 Paragraph 2 |
Paragraph 1Paragraph 2 |
Figure 93.4 — Not separate paragraphs |
In the second example, GitHub effectively ignores the physical line break after Paragraph 1 (the actual line break cause by hitting the enter key).
Note
GitHub will ignore multiple blank lines, it will consider multiple blank lines to be the same as a single blank line between paragraphs.
This is the correct mechanism for forcing a line break in Markdown.
To force a line break, use <br>
at the end of the line where the break is to occur, the <br>
can also be used within lines:
MARKDOWN (with line numbers) | GITHUB OUTPUT |
---|---|
1 Paragraph 1<br> 2 Paragraph 2 3 4 Paragraph 3<br>Paragraph 4 |
Paragraph 1 |
Figure 93.5 — Forced line breaks |
Caution
DO NOT USE THIS METHOD.
It is a feature of Markdown that two trailing spaces at the end of a line will force a line break.
It is hard to see two spaces at the end of a line (they don’t show up in most editors), The following shows how it works
MARKDOWN (with line numbers) | GITHUB OUTPUT |
---|---|
1 Paragraph 1∘∘ 2 Paragraph 2 |
Paragraph 1 |
Figure 93.6 — Trailing space line breaks | |
∘ indicates a space |
- Always leave a single blank line between paragraphs (multiple blank lines have no effect)
- Do not indent paragraphs at all (tabs will be ignored, multiple spaces will be treated as single space)
- Always use
<br>
to force a line break - Do not use trailing spaces to force a line break
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Lorem ipsum. Consectetur elit. |
<p>Lorem.</p><p>Consectetur elit.</p> | Lorem ipsum. Consectetur elit. |
Table 93.4 — Paragraph examples | ||
Lorem ipsum.<br>Consectetur elit. | <p>Lorem ipsum.<br>Consectetur elit.</p> |
Lorem ipsum. Consectetur elit. |
Table 93.5 — Line break examples |
Any text can be made bold by surrounding it with two asterisks (**) i.e.
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word is in **bold** | The next word is in bold |
Figure 93.7 — Bold text |
Bold can carry over between lines:
MARKDOWN | GITHUB OUTPUT |
---|---|
This is not in bold **the rest of the line is in bold And so is this.** |
This is not in bold the rest of the line is in bold |
Figure 93.8 — Bold text |
A double underscore can be used in exactly the same way
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word is in __bold__ | The next word is in bold |
Figure 93.9 — Bold text |
Caution
DO NOT USE THIS METHOD.
The use of two underscore characters for bold in the middle of a word is misinterpreted by some Markdown applications, don’t use underscores, always use asterisks.
- Surround the text that is to be in bold with two asterisks (**) before and after
- Do not use double underscores (always use asterisks)
- Bold text can span lines
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Lorem **ipsum** dolor sit | <p>Lorem.<strong>ipsum</strong> dolor sit</p> | Lorem ipsum dolor sit |
Lorem **ipsum dolor sit Consectetur** elit. |
<p>Lorem.<strong>ipsum dolor sit</strong></p><p> <strong>Consectetur</strong> elit.</p> |
Lorem ipsum dolor sit Consectetur elit. |
Table 93.6 — Bold text examples |
Any text can be made italic by surrounding it with a single asterisk (*) i.e.
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word is in *italics* | The next word is in italics |
Figure 93.10 — italic text |
Italics can carry over between lines:
MARKDOWN | GITHUB OUTPUT |
---|---|
This is not in italics *the rest of the line is in italics And so is this.* |
This is not in italics the rest of the line is in italics |
Figure 93.11 — italic text |
A single underscore can be used in exactly the same way
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word is in _italics_ | The next word is in italics |
Figure 93.12 — italic text |
Caution
DO NOT USE THIS METHOD.
The use of underscore characters for italics in the middle of a word is misinterpreted by some Markdown applications, don’t use underscores, always use asterisks.
- Surround the text that is to be in italics with an asterisk (*) before and after
- Do not use underscores (always use asterisks)
- Italic text can span lines
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Lorem *ipsum* dolor sit | <p>Lorem.<em>ipsum</strong> dolor sit</p> | Lorem ipsum dolor sit |
Lorem **ipsum dolor sit Consectetur** elit. |
<p>Lorem.<strong>ipsum dolor sit</strong></p><p> <strong>Consectetur</strong> elit.</p> |
Lorem ipsum dolor sit Consectetur elit. |
Table 93.7 — Bold text examples |
Any text can be made both bold and italic by surrounding it with three asterisks (***) i.e.
MARKDOWN | GITHUB OUTPUT |
---|---|
This is both ***bold and italic*** | This is both bold and italci |
Figure 93.13 — Bold and italic text |
Bold and Italic text can carry over between lines:
MARKDOWN | GITHUB OUTPUT |
---|---|
This is normal ***the rest of the line is in bold and italics And so is this.*** |
This is normal the rest of the line is in bold and italics |
Figure 93.14 — Bold and italic text |
Three underscores can be used in exactly the same way
MARKDOWN | GITHUB OUTPUT |
---|---|
This is both ___bold and italic__ | This is both bold and italic |
Figure 93.15 — Bold text |
Caution
DO NOT USE THIS METHOD.
The use of underscore characters in the middle of a word is misinterpreted by some Markdown applications, don’t use underscores, always use asterisks.
- Surround the text that is to be in bold with three asterisks (***) before and after
- Do not use underscores (always use asterisks)
- Bold and italic text can span lines
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Lorem ***ipsum*** dolor sit | <p>Lorem.<strong><em>ipsum</em></strong> dolor sit</p> | Lorem ipsum dolor sit |
Lorem ***ipsum dolor sit Consectetur*** elit. |
<p>Lorem.<strong><em>ipsum dolor sit</em></strong></p><p> <strong><em>Consectetur</em></strong> elit.</p> |
Lorem ipsum dolor sit Consectetur elit. |
Table 93.8 — Bold and italic text examples |
There is no direct support for underlining text in Markdown (nothing with asterisks or underscores), but it can be achieved with the use of the HTML tag <u>…</u>
.
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word is <u>underlined</u> | The next word is underlined |
Figure 93.16 — Underlined text |
Unlike bold and italics, underlining cannot carry over between lines. Each line must be underlined individually
MARKDOWN | GITHUB OUTPUT |
---|---|
This is not underlined <u>the rest of the line is</u> <u>And so is this.</u> |
This is not underlined the rest of the line is |
Figure 93.17 — Underlined text |
- The first rule is don’t underline things. Ever! Underlined text can be confused as a link, plus it just looks bad
- Use a
<u>
before the text that is to be underlined and a</u>
at the end - Underlining does not span blank lines
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Not available | <p>Lorem.<u>ipsum</u> dolor sit</p> | Lorem ipsum dolor sit |
Table 93.9 — Underlined text examples |
Any text can be struck through by surrounding it with a double tilde (~~) i.e.
MARKDOWN | GITHUB OUTPUT |
---|---|
The next word has been ~~struck through~~ | The next word is |
Figure 93.18 — Strikethrough |
Unlike bold and italics, strikethrough cannot carry over between lines. Each line must be struck through individually
MARKDOWN | GITHUB OUTPUT |
---|---|
This is not struck through ~~the rest of the line is~~; ~~And so is this.~~ |
This is not struck through |
Figure 93.19 — Strikethrough |
- Surround the text that is to be in struck through with two tildes (~~) before and after
- Strikethrough text cannot span lines
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
Lorem ~~ipsum~~ dolor sit | <p>Lorem.<s>ipsum</s> dolor sit</p> | Lorem |
Table 93.10 — Strikethrough text examples |
Horizontal rules are thick, grey lines that span a Markdown page indicating some form of break.
Horizontal rules are created using three or more asterisks (***), dashes (---) or underscores (___). That said, the best way to create a horizontal rule is to use the <hr>
tag, this has become the default standard.
If using three dashes, make sure it is surrounded by blank lines, if there is any text on the line immediately above, it will be turned into a heading (see section xxx)
The following are all horizontal rules
MARKDOWN | GITHUB OUTPUT |
---|---|
*** --- ___ <hr> |
|
Figure 93.20 — Horizontal rule |
This is what it looks like on a Wiki page (below):
- Use the
<hr>
tag for horizontal rules - Always put a blank line before and after the
<hr>
MARKDOWN | HTML | GITHUB OUTPUT |
---|---|---|
*** --- ___ <hr> |
<hr> |
|
Table 93.11 — Horizontal rule examples |
Markdown has a mechanism for displaying characters that would otherwise be use to format text (asterisks for example), this mechanism is called “escaping the character”. It is also possible to use Unicode value to display a specific character and all the HTML symbol codes (the ones that begin with an ampersand) are also supported.
With Markdown, to display a literal character (i.e. to make the character appear in the text rather than format the text) precede it with a backslash character (\).
For example if the text:
* Without a backslash this is rendered as a list (see section xxx), it looks like this:
- Without a backslash this is rendered as a list (see section xxx), it looks like this
If a backslash is placed in front of the asterisk
\* With a backslash this is rendered as an asterisk, like this:
* With a backslash this is rendered as an asterisk, like this.
The following characters can all be “escaped” by placing a backslash before the character:
Character | Name | Escape symbol |
---|---|---|
\ |
Backslash |
\\ |
` |
Backtick |
\` |
* |
Asterisk |
\* |
_ |
Underscore |
\_ |
{ } |
Braces |
\{ \} |
[ ] |
Brackets |
\[ \] |
< > |
Angle brackets |
\< \> |
( ) |
Parentheses |
\( \) |
# |
Hash sign |
\# |
+ |
Plus sign |
\+ |
- |
Minus sign (hyphen) |
\- |
. |
Full stop |
\. |
! |
Exclamation mark |
\! |
| |
Pipe |
\| |
Table 93.12 — Markdown escape characters |
In much the same way that Markdown requires escape characters to display characters that are normally used for text formatting, HTML requires the same. HTML makes great use of the less (<) than and greater than signs (>), in fact all HTML tags are surrounded by them.
There are several of these reserved characters in HTML:
html reserved characters | |||
---|---|---|---|
The following have special meaning in HTML: |
|||
Less than |
< |
Replacement code: |
< |
Greater than |
> |
Replacement code: |
> |
Ampersand |
& |
Replacement code: |
& |
Double quotation mark |
" |
Replacement code: |
" |
Single quotation mark |
' |
Replacement code: |
' |
Table 93.13 — HTML reserved characters |
HTML provides two mechanisms for getting around this problem, the first is a series of escape sequences (sometimes called symbol codes) that start with an ampersand (&) followed by a meaningful group of characters (well, meaningful in a way, some require a degree of interpretation) and ending with a semicolon (;). For example, the escape sequence for a less than symbol (<) is <
Basically, HTML escape sequences are a group of characters that are translated by the browser into a different symbol.
Whenever the browser comes across the sequence of characters <
, it will display a less than sign (<).
So whenever you want to put any of the five characters above HTML tag but want the text to be displayed, use the &code that is given as a substitute.
Escape sequences always start with the ampersand character (&) and end with a semicolon (;).
The second mechanism is to use the Unicode value of the character as an “escape code” (as opposed to an escape sequence).
Every character that can be displayed has a Unicode value (a number), specifically a value given using the Unicode transformation format-8 (UTF-8✳1). For example, the letter “A” has a Unicode value of 65, “B” 66 &c., there is a full list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Unicode_characters.
In HTML, any character can be entered by using its Unicode value as an escape code. HTML escape codes are preceded by the ampersand and hash characters (&#) and finished with a semicolon (;).
Continuing the previous example Unicode value for the letter “A” is 65 (decimal). To enter the letter “A” in HTML using an escape code, use the following:
A
GitHub Markdown accepts the use of both HTML escape sequence and escape codes
The following table gives a list of common escape sequence and escape codes:
mathematical | html | code | mathematical | html | code | ||
---|---|---|---|---|---|---|---|
× | Multiplication sign | × | × | ∩ | Intersection | ∩ | ∩ |
÷ | Division sign | ÷ | ÷ | ∫ | Integral | ∫ | ∫ |
− | Minus sign | − | − | ≈ | Almost equal to | ≈ | ≈ |
± | Plus/minus sign | ± | ± | ≠ | Not equal to | ≠ | ≠ |
⁄ | Fraction slash | ⁄ | ⁄ | ≡ | Identical to | ≡ | ≡ |
∏ | N-array product | ∏ | ∏ | < | Less than | < | < |
∑ | N-array summation | ∑ | ∑ | > | Greater than | > | > |
√ | Square root | √ | √ | ≤ | Less than or equal to | ≤ | ≤ |
∞ | Infinity | ∞ | ∞ | ≥ | Greater than or equal to | ≥ | ≥ |
html reserved |
html | code | html reserved | html | code | ||
< | Less than | < | < | " | Quotation mark | " | " |
> | Greater than | > | > | ' | Single quote | ' | ' |
& | Ampersand | & | & | ||||
miscellaneous |
html | code | miscellaneous | html | code | ||
← | Leftwards arrow | ← | ← | ¦ | Broken vertical bar | ¦ | ¦ |
↑ | Upwards arrow | ↑ | ↑ | ° | Degree sign | ° | ° |
→ | Rightwards arrow | → | → | · | Middle dot | · | · |
↓ | Downwards arrow | ↓ | ↓ | • | Bullet | • | • |
↔ | Left right arrow | ↔ | ↔ | ||||
Spacing |
html | code | Spacing | html | code | ||
█ █ | Em space |   |   | █ █ | Space |   | |
█ █ | Number space |   |   | █ █ | Em/4 space |   |   |
█ █ | En space |   |   | █ █ | Punctuation space |   |   |
█ █ | Em/3 space |   |   | █ █ | Thin space |   |   |
█ █ | Non-breaking space | |   | █ █ | Hair space |   |   |
Currency |
html | code | Currency | html | code | ||
$ | Dollar | $ | $ | ¢ | Cent sign | ¢ | ¢ |
£ | Pound sign | £ | £ | ¥ | Yen | ¥ | ¥ |
€ | Euro sign | € | € | ¤ | Curren | ¤ | ¤ |
numbers |
html | code | numbers | html | code | ||
¹ | Superscript one | ¹ | ¹ | ½ | Fraction one half | ½ | ½ |
² | Superscript two | ² | ² | ¼ | Fraction one quarter | ¼ | ¼ |
³ | Superscript three | ³ | ³ | ¾ | Fraction three quarters | ¾ | ¾ |
punctuation |
html | code | punctuation | html | code | ||
¡ | Inverted exclamation mark | ¡ | ¡ | … | Horizontal ellipsis | … | … |
¿ | Inverted question mark | ¿ | ¿ | ‾ | Overline | ‾ | ‾ |
“ | Left double quote | “ | “ | § | Section sign | § | § |
” | Right double quote | ” | ” | ¶ | Paragraph sign | ¶ | ¶ |
„ | Double low-9 quote | „ | „ | © | Copyright sign | © | © |
‘ | Left single quote | ‘ | ‘ | ® | Registered trademark sign | ® | ® |
’ | Right single quote | & rsquo; | ’ | ™ | Trademark sign | ™ | ™ |
‚ | Single low-9 quote | ‚ | ‚ | ¬ | Not sign | ¬ | ¬ |
◊ | Lozenge | ◊ | ◊ | µ | Micro sign | µ | µ |
« | Left double angle quote | « | « | ‰ | Per mille sign | ‰ | ‰ |
» | Right double angle quote | » | » | ′ | Prime (straight quote) | ′ | ′ |
‹ | Single left angle quote | ‹ | ‹ | ″ | Double prime (straight quote) | ″ | ″ |
› | Single right angle quote | › | › | † | Dagger | † | † |
– | En dash | – | – | ‡ | Double dagger | ‡ | ‡ |
— | Em dash | — | — | ||||
Greek small letters |
html | code | Greek capital letters | html | code | ||
α | Alpha | &alpha | α | Α | Alpha | &Alpha | Α |
β | Beta | β | β | Β | Beta | Β | Β |
γ | Gamma | γ | γ | Γ | Gamma | Γ | Γ |
δ | Delta | δ | δ | Δ | Delta | Δ | Δ |
ε | Epsilon | ε | ε | Ε | Epsilon | Ε | Ε |
ζ | Zeta | ζ | ζ | Ζ | Zeta | Ζ | Ζ |
η | Eta | η | η | Η | Eta | Η | Η |
θ | Theta | θ | θ | Θ | Theta | Θ | Θ |
ι | Iota | ι | ι | Ι | Iota | Ι | Ι |
κ | Kappa | κ | κ | Κ | Kappa | Κ | Κ |
λ | Lambda | λ | λ | Λ | Lambda | Λ | Λ |
μ | Mu | μ | μ | Μ | Mu | Μ | Μ |
ν | Nu | ν | ν | Ν | Nu | Ν | Ν |
ξ | Xi | ξ | ξ | Ξ | Xi | Ξ | Ξ |
ο | Omicron | ο | ο | Ο | Omicron | Ο | Ο |
π | Pi | π | π | Π | Pi | Π | Π |
ρ | Rho | ρ | ρ | Ρ | Rho | Ρ | Ρ |
ς | Sigma 1 | ς | ς | Σ | Sigma | Σ | Σ |
σ | Sigma 2 | σ | σ | ||||
τ | Tau | τ | τ | Τ | Tau | Τ | Τ |
υ | Upsilon | υ | υ | Υ | Upsilon | Υ | Υ |
φ | Phi | φ | φ | Φ | Phi | Φ | Φ |
χ | Chi | χ | χ | Χ | Chi | Χ | Χ |
ψ | Psi | ψ | ψ | Ψ | Psi | Ψ | Ψ |
ω | Omega | ω | ω | Ω | Omega | Ω | Ω |
Table 93.14 — HTML common escape sequences and codes |
This table just contains the most common escape sequences and codes, Appendix A has a complete list of all HTML escape sequences (they all work in GitHub Markdown).
✳1 UTF-8 is a Unicode character set that is backwards compatible with the old 7-bit ASCII char-acters that those of us of a certain age will remember. The 8 means it uses 8-bit blocks (bytes to most people, but octets in the Unicode standard) to represent characters, it can have up to 4 bytes and can represent all Unicode characters (there is a lot of them — ‘bout a million).
UTF-8 is the standard character set for web pages and E-mail.
The escape codes in the previous section used decimal numbers for the Unicode characters A
where 65 is the decimal value of the Unicode number for “A”.
The escape codes can also be in hexadecimal and this will work within GitHub Markdown and Wiki pages. The hexadecimal equivalent of 65 is 41. To use the hexadecimal number in an escape code, precede it with &#x and follow it with a semicolon (;). Thus
A
and A
both display the “A” character (first with a decimal number, second with a hexadecimal number).
Markdown (and GitHub Markdown) ignore multiple spaces. In the following example, the two words “TEST” are separated by five spaces:
MARKDOWN | GITHUB OUTPUT |
---|---|
Test∘∘∘∘∘Test | Test Test |
Table 93.15 — Markdown ignores multiple consecutive spaces | |
∘ indicates a space |
Markdown does not, however, ignore the non-breaking space character
, this has exactly the same spacing as a normal space character, but will be rendered by Markdown.
This is the same example with five non-breaking spaces between the two words “TEST”
MARKDOWN | GITHUB OUTPUT |
---|---|
Test Test | Test Test |
Table 93.16 — Markdown does not ignore multiple consecutive non-breaking spaces | |
∘ indicates a space |
Markdown supports several such space characters; this is a full list — the spaces are bounded by full blocks to give an idea of the width of each type of space, the second column shows four of each type of space to emphasize the different relative sizes:
Markdown supports several such space characters; this is a full list — the spaces are bounded by full blocks to give an idea of the width of each type of space, the second column shows four of each type of space to emphasize the different relative sizes:
Single Space |
Four Spaces |
Name | Escape sequence | ||||
---|---|---|---|---|---|---|---|
█ █ |
█ █ |
Em space |
  |
||||
█ █ |
█ █ |
Number space |
  |
||||
█ █ |
█ █ |
En space |
  |
||||
█ █ |
█ █ |
Em/3 space |
  |
||||
█ █ |
█ █ |
Non-breaking space |
|
||||
█ █ |
█ █ |
Em/4 space |
  |
||||
█ █ |
█ █ |
Punctuation space |
  |
||||
█ █ |
█ █ |
Thin space |
  |
||||
█ █ |
█ █ |
Hair space |
  |
||||
Table 93.17 — Differnt spaces and relative widths |
The column containing four consecutive spaces (of each type) is included to amplify the differences in size between the differnet types of spaces. The space types are listed in order of diminishing width.
These different size spaces are used extensively in the PracticalSeries Wiki page headings and tables of contents to ensure that the gaps between the heading numbers and the heading text are consistent. The size of the gap between the number on the left and the text on the right, depends on how many numbers there are (90.10.20. has six numbers, 1.2.4 only has three. Both are valid section numbers, but the first will have a smaller space between the last full stop and the heading text)
The width of each type of space depends on if the space is in a heading (all headings are different) or body text. Similarly, if the text is in a sidebar or footer, the spacings are again different for both headings and body text.
The following tables give the width in pixels of each different type of space character for all headings and body text in both the main page area and sidebars/footers (there is no difference between space sizes in sidebars and in footers, they are the same).
Space witdths in pixels for the main page | |||||||
---|---|---|---|---|---|---|---|
H1 |
H2 |
H3 |
H4 |
H5 |
H6 |
Body text |
|
Em space |
32.00 |
24.00 |
20.00 |
16.00 |
14.00 |
13.60 |
16.00 |
Number space |
17.77 |
13.33 |
11.10 |
8.87 |
7.77 |
7.53 |
8.63 |
En space |
16.00 |
12.00 |
10.00 |
8.00 |
7.00 |
6.80 |
8.00 |
Em/3 space |
10.63 |
8.00 |
6.63 |
5.33 |
4.67 |
4.53 |
5.33 |
Normal space |
8.80 |
6.60 |
5.47 |
4.40 |
3.87 |
3.73 |
4.37 |
Non-breaking space |
8.80 |
6.60 |
5.47 |
4.40 |
3.87 |
3.73 |
4.37 |
Em/4 space |
8.00 |
6.00 |
5.00 |
4.00 |
3.50 |
3.40 |
4.00 |
Punctuation space |
7.70 |
5.80 |
4.80 |
3.87 |
3.37 |
3.27 |
3.47 |
Thin space |
6.40 |
4.83 |
4.00 |
3.20 |
2.80 |
2.70 |
3.20 |
Hair space |
4.00 |
3.00 |
2.50 |
2.00 |
1.77 |
1.70 |
2.00 |
Table 93.18 — Space widths (in pixels) for the main page |
Space witdths in pixels for sidebars and footers | |||||||
---|---|---|---|---|---|---|---|
H1 |
H2 |
H3 |
H4 |
H5 |
H6 |
Body text |
|
Em space |
24.00 |
18.00 |
15.00 |
12.00 |
10.50 |
10.20 |
12.00 |
Number space |
13.33 |
10.00 |
8.30 |
6.67 |
5.83 |
5.63 |
6.47 |
En space |
12.00 |
9.00 |
7.50 |
6.00 |
5.27 |
5.10 |
6.00 |
Em/3 space |
8.00 |
6.00 |
4.97 |
4.00 |
3.50 |
3.40 |
4.00 |
Normal space |
6.60 |
4.93 |
4.10 |
3.30 |
2.90 |
2.80 |
3.30 |
Non-breaking space |
6.60 |
4.93 |
4.10 |
3.30 |
2.90 |
2.80 |
3.30 |
Em/4 space |
6.00 |
4.50 |
3.73 |
3.00 |
2.63 |
2.53 |
3.00 |
Punctuation space |
5.80 |
4.33 |
3.60 |
2.90 |
2.53 |
2.43 |
2.60 |
Thin space |
4.83 |
3.60 |
3.00 |
2.40 |
2.10 |
2.03 |
2.40 |
Hair space |
3.00 |
2.23 |
1.87 |
1.47 |
1.33 |
1.27 |
7.80 |
Table 93.19 — Space widths (in pixels) for the sidebars and footers |
All widths are measured using the Edge browser with page maginification set to 100% on a monitor set to its native resolution (2560 × 1440px).
Emojis and emoticons are pictograms that can be embedded in text to convey some form of emotion, smiley face symbols, that sort of thing. They are popular with teenagers and the intellectually challenged.
A note by the Author |
& ampersand
:flag: Ascension Island:
😀
🟠
🙅
🆖
🟠
🈳
空
👩 🚒
The PracticalSeries of Publications — Copyright © 2021 Michael Gledhill
⬆️ Top | [email protected] | PracticalSeries of Publications | PAL website
The licences and other details
The Licence
Why did I choose the MIT Licence?
Permissive licences
Copyleft licence
Limiting liabilities
Which licence to use?
A note on spelling
1. Introducing the PAL
1.1. The approach taken
1.1.1 The structure of the software
1.1.2 The standard modules
1.1.3 The user interface
1.1.4 Templates and documentation
Template modules
Documentation modules
1.2. Background to the Project
1.3. Regulations and standards
1.4. Assumptions and limitations
2. The controller software and structure
2.1. Internal structure of the Controllers
2.1.1 Programmable blocks
Organisation blocks (OBs)
Functions (FCs)
Function blocks (FBs)
2.1.2 Data storage blocks
Data blocks (DBs)
Instance data blocks (iDBs)
User data types (UDTs)
2.1.3 Built-in system blocks
2.1.4 Block numbering and quantities
2.2. Execution of Controller software
2.2.1 Cyclic programme execution
90. How to build a GitHub Wiki
90.1. What are GitHub Wiki pages?
90.2. Understanding the Wiki pages
90.3. Creating a Wiki for a repository
90.4. Cloning a Wiki to a local machine
90.5. Basic components of a Wiki
90.5.1 Title bar and revision
90.5.2 Contents area
90.5.3 Listing pages in the order you want
90.6. Sidebars and footers
90.6.1 What are sidebars and footers?
90.6.2 Create a sidebar or footer in GitHub
90.6.3 Create a sidebar or footer locally
91. Imposing a folder structure on a Wiki
91.1. The default arrangement
91.2. A practical Wiki folder structure
91.2.1 Page Numbering in the Wiki
91.2.2 Rules for page numbering
91.2.2 Subfolder names for Wiki pages
91.2.3 Page names for Wiki pages
91.2.4 Storing images and other data
92. Markdown, GitHub Markdown and HTML
A note by the Author
Some useful Markdown sites
92.1. An overview of Markdown
92.1.1 How Markdown works
92.1.2 Markdown flavours
GitHub Flavoured Markdown (GFM)
92.1.3 PracticalSeries Markdown
92.2. Basic Markdown and syntax
92.2.1 Body text and fonts
Body text responsive design
Body text in sidebars and footers
Body text examples
Alignment of Body text
Body text properties
92.2.2 Headings
Heading Markdown rules
Heading examples
Heading properties
Heading alternatives
⬇️ End of page |