Skip to content

93 Basic Markdown and text formatting

mgledhill edited this page Oct 14, 2024 · 87 revisions

PAL Logo showing Wiki Documentation heading

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.

⬆️ Top

93.1.       Body text and fonts

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:


A Markdown file
Figure 93.2 — Body text font colour

⬆️ Top

93.1.1       Body text responsive design

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.

⬆️ Top

93.1.2       Body text in sidebars and footers

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.

⬆️ Top

93.1.3       Body text Markdown rules

  1. GitHub will ignore multiple consecutive spaces (it will treat them as a single space)
  2. Always leave a blank line between paragraphs (see below)
  3. Multiple blank lines will be ignored (treated as a single blank line)
  4. Never use the tab character

⬆️ Top

93.1.4       Body text examples

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

⬆️ Top

93.1.5       Alignment of Body text

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.

⬆️ Top

93.1.6       Body text properties

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

⬆️ Top


93.2.       Paragraphs and line breaks

Paragraphs and line breaks can be a bit hit and miss in Markdown; the following explains both:

93.2.1       Paragraphs

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.

⬆️ Top

93.2.2       Forced line break

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
Paragraph 2

Paragraph 3
Paragraph 4

Figure 93.5 — Forced line breaks

⬆️ Top

93.2.3       Trailing space line break

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
Paragraph 2

Figure 93.6 — Trailing space line breaks
∘ indicates a space

⬆️ Top

93.2.4       Paragraph and line break Markdown rules

  1. Always leave a single blank line between paragraphs (multiple blank lines have no effect)
  2. Do not indent paragraphs at all (tabs will be ignored, multiple spaces will be treated as single space)
  3. Always use <br> to force a line break
  4. Do not use trailing spaces to force a line break

⬆️ Top

93.2.5       Paragraph and line break examples

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

⬆️ Top


93.3.       Emphasis with bold

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

And so is this.

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.

⬆️ Top

93.3.1       Markdown rules for bold

  1. Surround the text that is to be in bold with two asterisks (**) before and after
  2. Do not use double underscores (always use asterisks)
  3. Bold text can span lines

⬆️ Top

93.3.2       Bold text examples

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

⬆️ Top


93.4.      Emphasis with italics

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

And so is this.

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.

⬆️ Top

93.4.1       Markdown rules for italics

  1. Surround the text that is to be in italics with an asterisk (*) before and after
  2. Do not use underscores (always use asterisks)
  3. Italic text can span lines

⬆️ Top

93.4.2       Italic text examples

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

⬆️ Top


93.5.       Emphasis with bold and italics

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

And so is this.

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.

⬆️ Top

93.5.1       Markdown rules for bold and italics

  1. Surround the text that is to be in bold with three asterisks (***) before and after
  2. Do not use underscores (always use asterisks)
  3. Bold and italic text can span lines

⬆️ Top

93.5.2       Bold and italic text examples

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

⬆️ Top


93.6.       Emphasis with underlining

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

And so is this.

Figure 93.17 — Underlined text

⬆️ Top

93.6.1       Markdown rules for underlining

  1. The first rule is don’t underline things. Ever! Underlined text can be confused as a link, plus it just looks bad
  2. Use a <u> before the text that is to be underlined and a </u> at the end
  3. Underlining does not span blank lines

⬆️ Top

93.6.2       Underlined text examples

MARKDOWN HTML GITHUB OUTPUT
Not available <p>Lorem.<u>ipsum</u> dolor sit</p> Lorem ipsum dolor sit
Table 93.9 — Underlined text examples

⬆️ Top


93.7.     Strikethrough text

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 struck through

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 the rest of the line is

And so is this.

Figure 93.19 — Strikethrough

⬆️ Top

93.7.1        Markdown rules for strikethrough

  1. Surround the text that is to be in struck through with two tildes (~~) before and after
  2. Strikethrough text cannot span lines

⬆️ Top

93.7.2       Strikethrough text examples

MARKDOWN HTML GITHUB OUTPUT
Lorem ~~ipsum~~ dolor sit <p>Lorem.<s>ipsum</s> dolor sit</p> Lorem ipsum dolor sit
Table 93.10 — Strikethrough text examples

⬆️ Top


93.8.       Horizontal rules

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):


⬆️ Top

93.6.1       Markdown rules for horizontal lines

  1. Use the <hr> tag for horizontal rules
  2. Always put a blank line before and after the <hr>

⬆️ Top

93.6.2       Underlined text examples

MARKDOWN HTML GITHUB OUTPUT
***
            
---

___

<hr>
<hr>
            


            
Table 93.11 — Horizontal rule examples

⬆️ Top


93.9.       Escape characters and character codes

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.

93.9.1       Markdown escape characters

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

⬆️ Top

93.9.2       Unicode and HTML escape sequences

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:

&lt;

Greater than

>

Replacement code:

&gt;

Ampersand

&

Replacement code:

&amp;

Double quotation mark

"

Replacement code:

&quot;

Single quotation mark

'

Replacement code:

&apos;

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 &lt;

⬆️ Top

HTML escape sequences

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 &lt;, 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 (;‍).

⬆️ Top

HTML decimal escape codes

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:

   &#65;

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 &times; &#0215; Intersection &cap; &#8745;
÷ Division sign &divide; &#0247; Integral &int; &#8747;
Minus sign &minus; &#8722; Almost equal to &asymp; &#8776;
± Plus/minus sign &plusmn; &#0177; Not equal to &ne; &#8800;
Fraction slash &frasl; &#8260; Identical to &equiv; &#8801;
N-array product &prod; &#8719; < Less than &lt; &#0060;
N-array summation &sum; &#8721; > Greater than &gt; &#0062;
Square root &radic; &#8730; Less than or equal to &le; &#8804;
Infinity &infin; &#8734; Greater than or equal to &ge; &#8805;



html reserved
html code html reserved html code
< Less than &lt; &#0060; " Quotation mark &quot; &#0034;
> Greater than &gt; &#0062; ' Single quote &apos; &#0039;
& Ampersand &amp; &#0038;



miscellaneous
html code miscellaneous html code
Leftwards arrow &larr; &#8592; ¦ Broken vertical bar &brvbar; &#0166;
Upwards arrow &uarr; &#8593; ° Degree sign &deg; &#0176;
Rightwards arrow &rarr; &#8594; · Middle dot &middot; &#0183;
Downwards arrow &darr; &#8595; Bullet &bull; &#8226;
Left right arrow &harr; &#8596;
   


Spacing
html code     Spacing html code
█ █ Em space &emsp; &#8195; █ █ Space &#0032;
█ █ Number space &numsp; &#8199; █ █ Em/4 space &emsp14; &#8197;
█ █ En space &ensp; &#8194; █ █ Punctuation space &puncsp; &#8200;
█ █ Em/3 space &emsp13; &#8196; █ █ Thin space &thinsp; &#8201;
█ █ Non-breaking space &nbsp; &#0160; █ █ Hair space &hairsp; &#8202;



Currency
html code Currency html code
$ Dollar &dollar; &#0036; ¢ Cent sign &cent; &#0162;
£ Pound sign &pound; &#0163; ¥ Yen &yen; &#0165;
Euro sign &euro; &#0128; ¤ Curren &curren; &#0164;



numbers
html code numbers html code
¹ Superscript one &sup1; &#0185; ½ Fraction one half &frac12; &#0189;
² Superscript two &sup2; &#0178; ¼ Fraction one quarter &frac14 &#0188;
³ Superscript three &sup3; &#0179; ¾ Fraction three quarters &frac34 &#0190;



punctuation
html code punctuation html code
¡ Inverted exclamation mark &iexcl; &#0161; Horizontal ellipsis &hellip; &#8230;
¿ Inverted question mark &iquest; &#0191; Overline &oline; &#8254;
Left double quote &ldquo; &#8220; § Section sign &sect; &#0167;
Right double quote &rdquo; &#8221; Paragraph sign &para; &#0182;
Double low-9 quote &bdquo; &#8222; © Copyright sign &copy; &#0169;
Left single quote &lsquo; &#8216; ® Registered trademark sign &reg; &#0174;
Right single quote & rsquo; &#8217; Trademark sign &trade; &#8482;
Single low-9 quote &sbquo; &#8218; ¬ Not sign &not; &#0172;
Lozenge &loz; &#9674; µ Micro sign &micro; &#0181;
« Left double angle quote &laquo; &#0171; Per mille sign &permil; &#8240;
» Right double angle quote &raquo; &#0187; Prime (straight quote) &prime; &#8242;
Single left angle quote &lsaquo; &#8249; Double prime (straight quote) &Prime; &#8243;
Single right angle quote &rsaquo; &#8250; Dagger &dagger; &#8224;
En dash &ndash; &#8211; Double dagger &Dagger; &#8225;
Em dash &mdash; &#8212;



Greek small letters
html code Greek capital letters html code
α Alpha &alpha &#0945; Α Alpha &Alpha &#0913;
β Beta &beta; &#0946; Β Beta &Beta; &#0914;
γ Gamma &gamma; &#0947; Γ Gamma &Gamma; &#0915;
δ Delta &delta; &#0948; Δ Delta &Delta; &#0916;
ε Epsilon &epsilon; &#0949; Ε Epsilon &Epsilon; &#0917;
ζ Zeta &zeta; &#0950; Ζ Zeta &Zeta; &#0918;
η Eta &eta; &#0951; Η Eta &Eta; &#0919;
θ Theta &theta; &#0952; Θ Theta &Theta; &#0920;
ι Iota &iota; &#0953; Ι Iota &Iota; &#0921;
κ Kappa &kappa; &#0954; Κ Kappa &Kappa; &#0922;
λ Lambda &lambda; &#0955; Λ Lambda &Lambda; &#0923;
μ Mu &mu; &#0956; Μ Mu &Mu; &#0924;
ν Nu &nu; &#0957; Ν Nu &Nu; &#0925;
ξ Xi &xi; &#0958; Ξ Xi &Xi; &#0926;
ο Omicron &omicron; &#0959; Ο Omicron &Omicron; &#0927;
π Pi &pi; &#0960; Π Pi &Pi; &#0928;
ρ Rho &rho; &#0961; Ρ Rho &Rho; &#0929;
ς Sigma 1 &sigmaf; &#0962; Σ Sigma &Sigma; &#0931;
σ Sigma 2 &sigma; &#0963;
τ Tau &tau; &#0964; Τ Tau &Tau; &#0932;
υ Upsilon &upsilon; &#0965; Υ Upsilon &Upsilon; &#0933;
φ Phi &phi; &#0966; Φ Phi &Phi; &#0934;
χ Chi &chi; &#0967; Χ Chi &Chi; &#0935;
ψ Psi &psi; &#0968; Ψ Psi &Psi; &#0936;
ω Omega &omega; &#0969; Ω Omega &Omega; &#0937;
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.

⬆️ Top

HTML hexadecimal escape codes

The escape codes in the previous section used decimal numbers for the Unicode characters &#65; 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

   &#65; and &#x41; both display the “A” character (first with a decimal number, second with a hexadecimal number).

⬆️ Top

93.9.3       The use of special space characters

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 &nbsp;, 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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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

&emsp;

█ █

█    █

Number space

&numsp;

█ █

█    █

En space

&ensp;

█ █

█    █

Em/3 space

&emsp13;

█ █

█    █

Non-breaking space

&nbsp;

█ █

█    █

Em/4 space

&emsp14;

█ █

█    █

Punctuation space

&puncsp;

█ █

█    █

Thin space

&thinsp;

█ █

█    █

Hair space

&hairsp;

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).

⬆️ Top

20.10.    Emojis and emoticons

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

Well, I’m an engineer and engineers in particular are not at home to emojis
(we’re not generally tainted with emotion).

Engineer have only one rule for using emojis:

DON’T EVER!

A Markdown file

& ampersand

:flag: Ascension Island:

😀

🟠

🙅

🆖

🟠

🈳

👩 ‍ 🚒




Wiki contents           

Previous page Previous chapter Home Next chapter Next page

     Casenotes

   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

99.  Template
⬇️ End of page
Clone this wiki locally