Use unicode characters directly

When we use asciidoctor-pdf, UTF-8 is supported.

chapters/beam.asciidoc

@@ -1,7 +1,7 @@
 [[CH-BEAM]]
 == The Erlang Virtual Machine: BEAM
 
-BEAM (Bogumil's/Björn's Abstract Machine) is the machine that executes
+BEAM (Bogumil's/Björn’s Abstract Machine) is the machine that executes
 the code in the Erlang Runtime System. It is a garbage collecting,
 reduction counting, virtual, non-preemptive, directly threaded,
 register machine. If that doesn't tell you much, don't worry, in the
@@ -539,9 +539,9 @@ in the BEAM we just use them to illustrate this example):
 
 -------------------------------------------
 
-Note that the star in "+goto+ +*+" does not mean dereference, the
+Note that the star in `+goto *+` does not mean dereference, the
 expression means jump to an address pointer, we should really write it
-as "+goto*+".
+as `+goto*+`.
 
 Now imagine that the compiled C code for these instructions end up at
 memory addresses 0x3000, 0x3100, and 0x3200. When the BEAM code is
@@ -564,9 +564,9 @@ that the code (+{move,{x,0},{x,1}}, {move,{y,0},{x,0}},
 -------------------------------------------
 
 The word at address 0x1000 points to the implementation of
-the move_xx instruction. If the register +I+ contains the instruction
-pointer, pointing to 0x1000 then the dispatch will be to fetch +*I+
-(i.e. 0x3000) and jump to that address. ("+goto*+ +*I+")
+the move_xx instruction. If the register `I` contains the instruction
+pointer, pointing to 0x1000 then the dispatch will be to fetch `+*I+`
+(i.e. 0x3000) and jump to that address. (`+goto* *I+`)
 
 In xref:CH-Instructions[] we will look more closely at some real
 BEAM instructions and how they are implemented.

chapters/beam_modules.asciidoc

@@ -15,11 +15,11 @@ NOTE: What is a module. How is code loaded. How does hot code loading work. How
 
 The definite source of information about the beam file format is obviously the source code of beam_lib.erl (see link:$$https://github.com/erlang/otp/blob/maint/lib/stdlib/src/beam_lib.erl$$[]). There is actually also a more readable but slightly dated description of the format written by the main developer and maintainer of Beam (see link:$$http://www.erlang.se/~bjorn/beam_file_format.html$$[]).
 
-The beam file format is based on the interchange file format (EA IFF)#, with two small changes. We will get to those shortly. An IFF file starts with a header followed by a number of “chunks”. There are a number of standard chunk types in the IFF specification dealing mainly with images and music. But the IFF standard also lets you specify your own named chunks, and this is what BEAM does.
+The beam file format is based on the interchange file format (EA IFF)#, with two small changes. We will get to those shortly. An IFF file starts with a header followed by a number of “chunks”. There are a number of standard chunk types in the IFF specification dealing mainly with images and music. But the IFF standard also lets you specify your own named chunks, and this is what BEAM does.
 
-NOTE: Beam files differ from standard IFF files, in that each chunk is aligned on 4-byte boundary (i.e. 32 bit word) instead of on a 2-byte boundary as in the IFF standard. To indicate that this is not a standard IFF file the IFF header is tagged with “FOR1” instead of “FORM”. The IFF specification suggests this tag for future extensions.
+NOTE: Beam files differ from standard IFF files, in that each chunk is aligned on 4-byte boundary (i.e. 32 bit word) instead of on a 2-byte boundary as in the IFF standard. To indicate that this is not a standard IFF file the IFF header is tagged with “FOR1” instead of “FOR”. The IFF specification suggests this tag for future extensions.
 
-Beam uses form type “BEAM”. A beam file header has the following layout:
+Beam uses form type “BEAM”. A beam file header has the following layout:
 
 [source,erlang]
 ----
@@ -265,7 +265,7 @@ parse_code_info(<<Instructionset:32/integer,
 
 
 
-We will learn how to decode the beam instructions in a later chapter, aptly named &ldquo;BEAM Instructions&rdquo;.
+We will learn how to decode the beam instructions in a later chapter, aptly named “BEAM Instructions”.
 
 
 ==== String table chunk

chapters/introduction.asciidoc

@@ -326,7 +326,7 @@ Erlang Node.
 
 ****
 *BEAM:* The name BEAM originally stood for Bogdan's Erlang Abstract
- Machine, but nowadays most people refer to it as Björn's
+ Machine, but nowadays most people refer to it as Björn’s
 Erlang Abstract Machine, after the current maintainer.
  
 ****

chapters/memory.asciidoc

@@ -167,7 +167,7 @@ ends up in one of these corner cases.
 
 For a nice story about the troubles the system might get into
 and how to analyze and correct the behavior read
-Fred Hébert's essay https://blog.heroku.com/archives/2013/11/7/logplex-down-the-rabbit-hole["Troubleshooting Down the Logplex Rabbit Hole"].
+Fred Hébert’s essay https://blog.heroku.com/archives/2013/11/7/logplex-down-the-rabbit-hole["Troubleshooting Down the Logplex Rabbit Hole"].
 
 
 When we are talking about a memory allocator in this book we