Docs: Make our AsciiDoc markup more compatible with AsciiDoctor.

Start using markup that is preferred by Asciidoctor but compatible with
both generators.

Add a missing "cpp" attribute and set a couple of Asciidoctor-specific
compatibility attributes.

Change-Id: Iff4c31362e4493b97a85f46db2c39b18c336536f
Reviewed-on: https://code.wireshark.org/review/25600
Reviewed-by: Gerald Combs <gerald@wireshark.org>

10 files changed, 267 insertions, 267 deletions

diff --git a/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc b/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
index 9643746361..8162d6cbb9 100644
--- a/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_build_intro.asciidoc
@@ -12,11 +12,11 @@
 
 Wireshark consists of the following major parts:
 
-* Packet dissection - in the '/epan/dissector' and '/plugin/*' directories
+* Packet dissection - in the _/epan/dissector_ and _/plugin/\*_ directories
 
 * File I/O - using Wireshark's own wiretap library
 
-* Capture - using the libpcap/winpcap library, in '/wiretap'
+* Capture - using the libpcap/winpcap library, in _/wiretap_
 
 * User interface - using the Qt or $$GTK+$$ and associated libraries
 
@@ -29,7 +29,7 @@ Wireshark consists of the following major parts:
 === Coding Style
 
 The coding style guides for Wireshark can be found in the "Code style"
-section of the file 'doc/README.developer'.
+section of the file _doc/README.developer_.
 
 [[ChCodeGLib]]
 
diff --git a/docbook/wsdg_src/WSDG_chapter_capture.asciidoc b/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
index a6cd4dc930..ccae1815da 100644
--- a/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_capture.asciidoc
@@ -1,7 +1,7 @@
 ++++++++++++++++++++++++++++++++++++++
 <!-- WSDG Chapter Capture -->
 ++++++++++++++++++++++++++++++++++++++
-    
+
 [[ChapterCapture]]
 
 == Packet capturing
@@ -17,12 +17,12 @@ This chapter needs to be reviewed and extended.
 The following is an updated excerpt from a developer mailing list mail about
 adding ISO 9141 and 14230 (simple serial line card diagnostics) to Wireshark:
 
-For libpcap, the first thing you'd need to do would be to get +$$DLT_*$$+ values
+For libpcap, the first thing you'd need to do would be to get +{dlt-glob}+ values
 for all the link-layer protocols you'd need. If ISO 9141 and 14230 use the same
-link-layer protocol, they might be able to share a +$$DLT_*$$+ value, unless the
+link-layer protocol, they might be able to share a +{dlt-glob}+ value, unless the
 only way to know what protocols are running above the link layer is to know
 which link-layer protocol is being used, in which case you might want separate
-+$$DLT_*$$+ values.
++{dlt-glob}+ values.
 
 For the rest of the libpcap discussion, I'll assume you're working with libpcap
 1.0 or later and that this is on a UN*X platform. You probably don't want to
@@ -30,45 +30,45 @@ work with a version older than 1.0, even if whatever OS you're using happens to
 include libpcap - older versions are not as friendly towards adding support for
 devices other than standard network interfaces.
 
-Then you'd probably add to the +pcap_open_live()+ routine, for whatever
+Then you'd probably add to the `pcap_open_live()` routine, for whatever
 platform or platforms this code should work, something such as a check
 for device names that look like serial port names and, if the check
 succeeds, a call to a routine to open the serial port.
 
-See, for example, the +#ifdef HAVE_DAG_API+ code in 'pcap-linux.c' and
-'pcap-bpf.c'.
+See, for example, the `#ifdef HAVE_DAG_API` code in _pcap-linux.c_ and
+_pcap-bpf.c_.
 
 The serial port open routine would open the serial port device, set the baud
-rate and do anything else needed to open the device. It'd allocate a +pcap_t+,
-set its +fd+ member to the file descriptor for the serial device, set the
-+snapshot+ member to the argument passed to the open routine, set the +linktype+
-member to one of the +$$DLT_*$$+ values, and set the +selectable_fd+ member to
-the same value as the +fd+ member. It should also set the +dlt_count+ member to
-the number of +$$DLT_*$$+ values to support, and allocate an array of
-+dlt_count+ +u_int+s, assign it to the +dlt_list+ member, and fill in that list
-with all the +$$DLT_*$$+ values.
+rate and do anything else needed to open the device. It'd allocate a `pcap_t`,
+set its `fd` member to the file descriptor for the serial device, set the
+`snapshot` member to the argument passed to the open routine, set the `linktype`
+member to one of the +{dlt-glob}+ values, and set the `selectable_fd` member to
+the same value as the `fd` member. It should also set the `dlt_count` member to
+the number of +{dlt-glob}+ values to support, and allocate an array of
+`dlt_count` `u_int`s, assign it to the `dlt_list` member, and fill in that list
+with all the +{dlt-glob}+ values.
 
-You'd then set the various +$$*_op$$+ fields to routines to handle the operations in
-question. +read_op+ is the routine that'd read packets from the device. +inject_op+
+You'd then set the various `_*_op` fields to routines to handle the operations in
+question. `read_op` is the routine that'd read packets from the device. `inject_op`
 would be for sending packets; if you don't care about that, you'd set it to a
-routine that returns an error indication. +setfilter_op+ can probably just be set
-to +install_bpf_program+. +set_datalink+ would just set the +linktype+ member to the
+routine that returns an error indication. `setfilter_op` can probably just be set
+to `install_bpf_program`. `set_datalink` would just set the `linktype` member to the
 specified value if it's one of the values for OBD, otherwise it should return an
-error. +getnonblock_op+ can probably be set to +pcap_getnonblock_fd+. +setnonblock_op+
-can probably be set to +pcap_setnonblock_fd+. +stats_op+ would be set to a routine
-that reports statistics. +close_op+ can probably be set to +pcap_close_common+.
+error. `getnonblock_op` can probably be set to `pcap_getnonblock_fd`. `setnonblock_op`
+can probably be set to `pcap_setnonblock_fd`. `stats_op` would be set to a routine
+that reports statistics. `close_op` can probably be set to `pcap_close_common`.
 
-If there's more than one +$$DLT_*$$+ value, you definitely want a +set_datalink+
+If there's more than one +{dlt-glob}+ value, you definitely want a `set_datalink`
 routine so that the user can select the appropriate link-layer type.
 
-For Wireshark, you'd add support for those +$$DLT_*$$+ values to
-'wiretap/libpcap.c', which might mean adding one or more +WTAP_ENCAP+ types to
-'wtap.h' and to the +$$encap_table[]$$+ table in 'wiretap/wtap.c'. You'd then
+For Wireshark, you'd add support for those +{dlt-glob}+ values to
+_wiretap/libpcap.c_, which might mean adding one or more _WTAP_ENCAP_ types to
+_wtap.h_ and to the `encap_table[]` table in _wiretap/wtap.c_. You'd then
 have to write a dissector or dissectors for the link-layer protocols or
-protocols and have them register themselves with the +wtap_encap+ dissector
-table, with the appropriate +WTAP_ENCAP+ values by calling
-+dissector_add_uint()+.
+protocols and have them register themselves with the `wtap_encap` dissector
+table, with the appropriate _WTAP_ENCAP_ values by calling
+`dissector_add_uint()`.
 
 ++++++++++++++++++++++++++++++++++++
 <!-- End of WSDG Chapter Capture -->
-++++++++++++++++++++++++++++++++++++
\ No newline at end of file
+++++++++++++++++++++++++++++++++++++
diff --git a/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc b/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
index 0070bbc59b..6ecf36a95b 100644
--- a/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_dissection.asciidoc
@@ -36,7 +36,7 @@ the finished code may make more sense as a built-in dissector.
 [NOTE]
 .Read README.dissector
 ====
-The file 'doc/README.dissector' contains detailed information about implementing
+The file _doc/README.dissector_ contains detailed information about implementing
 a dissector. In many cases it is more up to date than this document.
 ====
 
@@ -93,18 +93,18 @@ proto_register_foo(void)
 Let's go through this a bit at a time. First we have some boilerplate
 include files. These will be pretty constant to start with.
 
-Next we have an int that is initialised to +$$-1$$+ that records our protocol.
+Next we have an int that is initialised to `-1` that records our protocol.
 This will get updated when we register this dissector with the main program.
 It's good practice to make all variables and functions that aren't exported
 static to keep name space pollution down. Normally this isn't a problem unless your
 dissector gets so big it has to span multiple files.
 
-Then a +#define+ for the UDP port that carries _foo_ traffic.
+Then a `#define` for the UDP port that carries _foo_ traffic.
 
 Now that we have the basics in place to interact with the main program, we'll
 start with two protocol dissector setup functions.
 
-First we'll call +proto_register_protocol()+ which registers the protocol. We
+First we'll call `proto_register_protocol()` which registers the protocol. We
 can give it three names that will be used for display in various places. The
 full and short name are used in e.g. the "Preferences" and "Enabled protocols"
 dialogs as well as the generated field name list in the documentation. The
@@ -132,8 +132,8 @@ be called to do the actual dissecting. Then we associate the handle with a UDP
 port number so that the main program will know to call us when it gets UDP
 traffic on that port.
 
-The standard Wireshark dissector convention is to put +proto_register_foo()+ and
-+proto_reg_handoff_foo()+ as the last two functions in the dissector source.
+The standard Wireshark dissector convention is to put `proto_register_foo()` and
+`proto_reg_handoff_foo()` as the last two functions in the dissector source.
 
 Now at last we get to write some dissecting code. For the moment we'll
 leave it as a basic placeholder.
@@ -168,19 +168,19 @@ At this point we should have a basic dissector ready to compile and install.
 It doesn't do much at present, other than identify the protocol and label it.
 
 In order to compile this dissector and create a plugin a couple of support files
-are required, besides the dissector source in 'packet-foo.c':
+are required, besides the dissector source in _packet-foo.c_:
 
-* 'Makefile.am' - The UNIX/Linux makefile template.
+* _Makefile.am_ - The UNIX/Linux makefile template.
 
-* 'CMakeLists.txt' - Contains the CMake file and version info for this plugin.
+* _CMakeLists.txt_ - Contains the CMake file and version info for this plugin.
 
-* 'packet-foo.c' - Your dissector source.
+* _packet-foo.c_ - Your dissector source.
 
-* 'plugin.rc.in' - Contains the DLL resource template for Windows. (optional)
+* _plugin.rc.in_ - Contains the DLL resource template for Windows. (optional)
 
 You can find a good example for these files in the gryphon plugin directory.
-'Makefile.am' has to be modified to reflect the relevant files and dissector
-name. 'CMakeLists.txt' has to be modified with the correct
+_Makefile.am_ has to be modified to reflect the relevant files and dissector
+name. _CMakeLists.txt_ has to be modified with the correct
 plugin name and version info, along with the relevant files to compile.
 In the main top-level source directory, copy CMakeListsCustom.txt.example to
 CMakeListsCustom.txt and add the path of your plugin to the list in
@@ -226,7 +226,7 @@ up the display when not required.
 We are also marking the area of data that is being consumed by this
 protocol. In our case it's all that has been passed to us, as we're assuming
 this protocol does not encapsulate another.
-Therefore, we add the new tree node with +proto_tree_add_item()+,
+Therefore, we add the new tree node with `proto_tree_add_item()`,
 adding it to the passed in tree, label it with the protocol, use the passed in
 tvb buffer as the data, and consume from 0 to the end (-1) of this data.
 ENC_NA ("not applicable") is specified as the "encoding" parameter.
@@ -236,11 +236,11 @@ and selecting this will highlight the remaining contents of the packet.
 
 Now let's go to the next step and add some protocol dissection. For this step
 we'll need to construct a couple of tables that help with dissection. This needs
-some additions to the +proto_register_foo()+ function shown previously.
+some additions to the `proto_register_foo()` function shown previously.
 
 Two statically allocated arrays are added at the beginning of
-+proto_register_foo()+. The arrays are then registered after the call to
-+proto_register_protocol()+.
+`proto_register_foo()`. The arrays are then registered after the call to
+`proto_register_protocol()`.
 
 .Registering data structures.
 ====
@@ -274,7 +274,7 @@ proto_register_foo(void)
 ----
 ====
 
-The variables +hf_foo_pdu_type+ and +ett_foo+ also need to be declared somewhere near the top of the file.
+The variables `hf_foo_pdu_type` and `ett_foo` also need to be declared somewhere near the top of the file.
 
 .Dissector data structure globals.
 ====
@@ -300,34 +300,34 @@ Now the dissection is starting to look more interesting. We have picked apart
 our first bit of the protocol. One byte of data at the start of the packet
 that defines the packet type for foo protocol.
 
-The +proto_item_add_subtree()+ call has added a child node
+The `proto_item_add_subtree()` call has added a child node
 to the protocol tree which is where we will do our detail dissection.
-The expansion of this node is controlled by the +ett_foo+
+The expansion of this node is controlled by the `ett_foo`
 variable. This remembers if the node should be expanded or not as you move
 between packets. All subsequent dissection will be added to this tree,
 as you can see from the next call.
-A call to +proto_tree_add_item()+ in the foo_tree,
-this time using the +hf_foo_pdu_type+ to control the formatting
+A call to `proto_tree_add_item()` in the foo_tree,
+this time using the `hf_foo_pdu_type` to control the formatting
 of the item. The pdu type is one byte of data, starting at 0. We assume it is
-in network order (also called big endian), so that is why we use +ENC_BIG_ENDIAN+.
+in network order (also called big endian), so that is why we use `ENC_BIG_ENDIAN`.
 For a 1-byte quantity, there is no order issue, but it is good practice to
 make this the same as any multibyte fields that may be present, and as we will
 see in the next section, this particular protocol uses network order.
 
-If we look in detail at the +hf_foo_pdu_type+ declaration in
+If we look in detail at the `hf_foo_pdu_type` declaration in
 the static array we can see the details of the definition.
 
-* 'hf_foo_pdu_type' - The index for this node.
+* _hf_foo_pdu_type_ - The index for this node.
 
-* 'FOO PDU Type' - The label for this item.
+* _FOO PDU Type_ - The label for this item.
 
-* 'foo.type' - This is the filter string. It enables us to type constructs such
-as +foo.type=1+ into the filter box.
+* _foo.type_ - This is the filter string. It enables us to type constructs such
+as `foo.type=1` into the filter box.
 
-* 'FT_UINT8' - This specifies this item is an 8bit unsigned integer.
+* _FT_UINT8_ - This specifies this item is an 8bit unsigned integer.
 This tallies with our call above where we tell it to only look at one byte.
 
-* 'BASE_DEC' - For an integer type, this tells it to be printed as a decimal
+* _BASE_DEC_ - For an integer type, this tells it to be printed as a decimal
 number. It could be hexadecimal (BASE_HEX) or octal (BASE_OCT) if that made more sense.
 
 We'll ignore the rest of the structure for now.
@@ -425,7 +425,7 @@ static const value_string packettypenames[] = {
 This is a handy data structure that can be used to look up a name for a value.
 There are routines to directly access this lookup table, but we don't need to
 do that, as the support code already has that added in. We just have to give
-these details to the appropriate part of the data, using the +VALS+ macro.
+these details to the appropriate part of the data, using the `VALS` macro.
 
 .Adding Names to the protocol.
 ====
@@ -498,7 +498,7 @@ proto_register_foo(void) {
 ====
 
 Some things to note here. For the flags, as each bit is a different flag, we use
-the type +FT_BOOLEAN+, as the flag is either on or off. Second, we include the flag
+the type `FT_BOOLEAN`, as the flag is either on or off. Second, we include the flag
 mask in the 7th field of the data, which allows the system to mask the relevant bit.
 We've also changed the 5th field to 8, to indicate that we are looking at an 8 bit
 quantity when the flags are extracted. Then finally we add the extra constructs
@@ -509,7 +509,7 @@ other things we can do to make things look even more pretty. At the moment our
 dissection shows the packets as "Foo Protocol" which whilst correct is a little
 uninformative. We can enhance this by adding a little more detail. First, let's
 get hold of the actual value of the protocol type. We can use the handy function
-+tvb_get_guint8()+ to do this. With this value in hand, there are a couple of
+`tvb_get_guint8()` to do this. With this value in hand, there are a couple of
 things we can do. First we can set the INFO column of the non-detailed view to
 show what sort of PDU it is - which is extremely helpful when looking at
 protocol traces. Second, we can also display this information in the dissection
@@ -543,7 +543,7 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
 ====
 
 So here, after grabbing the value of the first 8 bits, we use it with one of the
-built-in utility routines +val_to_str()+, to lookup the value. If the value
+built-in utility routines `val_to_str()`, to lookup the value. If the value
 isn't found we provide a fallback which just prints the value in hex. We use
 this twice, once in the INFO field of the columns -- if it's displayed, and
 similarly we append this data to the base of our dissecting tree.
@@ -598,16 +598,16 @@ within the protocol. If it's not, it may be part of the compression routine to
 work it out for you, in which case the logic would be different.
 
 So armed with the size, a buffer is allocated to receive the uncompressed data
-using +wmem_alloc()+ in pinfo->pool memory, and the packet is decompressed into
-it. The +tvb_get_ptr()+ function is useful to get a pointer to the raw data of
+using `wmem_alloc()` in pinfo->pool memory, and the packet is decompressed into
+it. The `tvb_get_ptr()` function is useful to get a pointer to the raw data of
 the packet from the offset onwards. In this case the decompression routine also
 needs to know the length, which is given by the
-+tvb_captured_length_remaining()+ function.
+`tvb_captured_length_remaining()` function.
 
 Next we build a new tvb buffer from this data, using the
-+tvb_new_child_real_data()+ call. This data is a child of our original data, so
+`tvb_new_child_real_data()` call. This data is a child of our original data, so
 calling this function also acknowledges that. No need to call
-+tvb_set_free_cb()+ as the pinfo->pool was used (the memory block will be
+`tvb_set_free_cb()` as the pinfo->pool was used (the memory block will be
 automatically freed when the pinfo pool lifetime expires). Finally we add this
 tvb as a new data source, so that the detailed display can show the
 decompressed bytes as well as the original.
@@ -616,7 +616,7 @@ After this has been set up the remainder of the dissector can dissect the buffer
 next_tvb, as it's a new buffer the offset needs to be 0 as we start again from
 the beginning of this buffer. To make the rest of the dissector work regardless
 of whether compression was involved or not, in the case that compression was not
-signaled, we use +tvb_new_subset_remaining()+ to deliver us a new buffer based
+signaled, we use `tvb_new_subset_remaining()` to deliver us a new buffer based
 on the old one but starting at the current offset, and extending to the end.
 This makes dissecting the packet from this point on exactly the same regardless
 of compression.
@@ -634,7 +634,7 @@ arrived and then start the dissection.
 
 The following sections will guide you through two common cases. For a
 description of all possible functions, structures and parameters, see
-'epan/reassemble.h'.
+_epan/reassemble.h_.
 
 [[ChDissectReassembleUdp]]
 
@@ -694,10 +694,10 @@ if (flags & FL_FRAGMENT) { /* fragmented */
 We start by saving the fragmented state of this packet, so we can restore it
 later. Next comes some protocol specific stuff, to dig the fragment data out of
 the stream if it's present. Having decided it is present, we let the function
-+fragment_add_seq_check()+ do its work. We need to provide this with a certain
+`fragment_add_seq_check()` do its work. We need to provide this with a certain
 amount of parameters:
 
-* The +msg_reassembly_table+ table is for bookkeeping and is described later.
+* The `msg_reassembly_table` table is for bookkeeping and is described later.
 
 * The tvb buffer we are dissecting.
 
@@ -709,7 +709,7 @@ amount of parameters:
   fragments in flight, and this is used to key the relevant one to be used for
   reassembly.
 
-* Optional additional data for identifying the fragment. Can be set to +NULL+
+* Optional additional data for identifying the fragment. Can be set to `NULL`
   (as is done in the example) for most dissectors.
 
 * msg_num is the packet number within the sequence.
@@ -760,7 +760,7 @@ unless the fragments have been reassembled as there won't be much to find.
 Sometimes the first packet in the sequence can be partially decoded though if
 you wish.
 
-Now the mysterious data we passed into the +fragment_add_seq_check()+.
+Now the mysterious data we passed into the `fragment_add_seq_check()`.
 
 .Reassembling fragments - Initialisation
 ====
@@ -776,14 +776,14 @@ proto_register_msg(void)
 ----
 ====
 
-First a +reassembly_table+ structure is declared and initialised in the protocol
+First a `reassembly_table` structure is declared and initialised in the protocol
 initialisation routine. The second parameter specifies the functions that should
 be used for identifying fragments. We will use
-+addresses_ports_reassembly_table_functions+ in order to identify fragments by
-the given sequence number (+msg_seqid+), the source and destination addresses
+`addresses_ports_reassembly_table_functions` in order to identify fragments by
+the given sequence number (`msg_seqid`), the source and destination addresses
 and ports from the packet.
 
-Following that, a +fragment_items+ structure is allocated and filled in with a
+Following that, a `fragment_items` structure is allocated and filled in with a
 series of ett items, hf data items, and a string tag. The ett and hf values
 should be included in the relevant tables like all the other variables your
 protocol may use. The hf variables need to be placed in the structure something
@@ -883,7 +883,7 @@ from the reassembled one. The other variables are used for flagging up errors.
 
 ==== How to reassemble split TCP Packets
 
-A dissector gets a +tvbuff_t+ pointer which holds the payload
+A dissector gets a `tvbuff_t` pointer which holds the payload
 of a TCP packet. This payload contains the header and data
 of your application layer protocol.
 
@@ -897,8 +897,8 @@ More than one messages can be transmitted in one TCP packet,
 so that a message can start at an arbitrary position.
 
 This sounds complicated, but there is a simple solution.
-+tcp_dissect_pdus()+ does all this tcp packet reassembling for you.
-This function is implemented in 'epan/dissectors/packet-tcp.h'.
+`tcp_dissect_pdus()` does all this tcp packet reassembling for you.
+This function is implemented in _epan/dissectors/packet-tcp.h_.
 
 .Reassembling TCP fragments
 ====
@@ -942,12 +942,12 @@ dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data)
 ----
 ====
 
-As you can see this is really simple. Just call +tcp_dissect_pdus()+ in your
+As you can see this is really simple. Just call `tcp_dissect_pdus()` in your
 main dissection routine and move you message parsing code into another function.
 This function gets called whenever a message has been reassembled.
 
 The parameters tvb, pinfo, tree and data are just handed over to
-+tcp_dissect_pdus()+. The 4th parameter is a flag to indicate if the data should
+`tcp_dissect_pdus()`. The 4th parameter is a flag to indicate if the data should
 be reassembled or not. This could be set according to a dissector preference as
 well. Parameter 5 indicates how much data has at least to be available to be
 able to determine the length of the foo message. Parameter 6 is a function
@@ -973,7 +973,7 @@ then called on each dissection. Some arbitrary protocol specific data
 is provided with the routine that can be used.
 
 To create a tap, you first need to register a tap. A tap is registered with an
-integer handle, and registered with the routine +register_tap()+. This takes a
+integer handle, and registered with the routine `register_tap()`. This takes a
 string name with which to find it again.
 
 .Initialising a tap
@@ -1007,7 +1007,7 @@ included in a header file so that it can be included by other components that
 want to listen in to the tap.
 
 Once you have these defined, it's simply a case of populating the protocol
-specific structure and then calling +tap_queue_packet+, probably as the last part
+specific structure and then calling `tap_queue_packet`, probably as the last part
 of the dissector.
 
 .Calling a protocol tap
@@ -1063,17 +1063,17 @@ WS_DLL_PUBLIC_DEF void plugin_register_tap_listener(void)
 ====
 
 Working from the bottom up, first the plugin interface entry point is defined,
-+plugin_register_tap_listener()+. This simply calls the initialisation function
-+register_foo_stat_trees()+.
+`plugin_register_tap_listener()`. This simply calls the initialisation function
+`register_foo_stat_trees()`.
 
-This in turn calls the +stats_tree_register_plugin()+ function, which takes three
+This in turn calls the `stats_tree_register_plugin()` function, which takes three
 strings, an integer, and three callback functions.
 
 . This is the tap name that is registered.
 
 . An abbreviation of the stats name.
 
-. The name of the stats module. A $$'/'$$ character can be used to make sub menus.
+. The name of the stats module. A `/' character can be used to make sub menus.
 
 . Flags for per-packet callback
 
@@ -1121,8 +1121,8 @@ static int foo_stats_tree_packet(stats_tree* st, packet_info* pinfo, epan_dissec
 ====
 
 In this case the processing of the stats is quite simple. First we call the
-+tick_stat_node+ for the +st_str_packets+ packet node, to count packets. Then a
-call to +stats_tree_tick_pivot()+ on the +st_node_packet_types+ subtree allows
+`tick_stat_node` for the `st_str_packets` packet node, to count packets. Then a
+call to `stats_tree_tick_pivot()` on the `st_node_packet_types` subtree allows
 us to record statistics by packet type.
 
 [[ChDissectConversation]]
@@ -1130,7 +1130,7 @@ us to record statistics by packet type.
 === How to use conversations
 
 Some info about how to use conversations in a dissector can be found in the file
-'doc/README.dissector', chapter 2.2.
+_doc/README.dissector_, chapter 2.2.
 
 [[ChDissectIdl2wrs]]
 
@@ -1146,7 +1146,7 @@ file and attempts to build a dissector that can decode the IDL traffic over
 GIOP. The resulting file is ``C'' code, that should compile okay as a Wireshark
 dissector.
 
-+idl2wrs+ parses the data struct given to it by the `omniidl` compiler,
+`idl2wrs` parses the data struct given to it by the `omniidl` compiler,
 and using the GIOP API available in packet-giop.[ch], generates get_CDR_xxx
 calls to decode the CORBA traffic on the wire.
 
@@ -1183,9 +1183,9 @@ It is also COOL to work on a great Open Source project such as the case with
 
 To use the idl2wrs to generate Wireshark dissectors, you need the following:
 
-* Python must be installed.  See link:$$http://python.org/$$[]
+* Python must be installed.  See link:http://python.org/[]
 
-* +omniidl+ from the omniORB package must be available. See link:$$http://omniorb.sourceforge.net/$$[]
+* `omniidl` from the omniORB package must be available. See link:http://omniorb.sourceforge.net/[]
 
 * Of course you need Wireshark installed to compile the code and tweak it if
 required. idl2wrs is part of the standard Wireshark distribution
diff --git a/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc b/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
index 74b6ee0601..1e76ae80a2 100644
--- a/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_env_intro.asciidoc
@@ -128,7 +128,7 @@ Wireshark mailing lists available.
 ==== Programming languages used
 
 Most of Wireshark is implemented in plain ANSI C. A notable exception is
-the code in 'ui/qt', which is written in $$C++$$.
+the code in _ui/qt_, which is written in {cpp}.
 
 The typical task for a new Wireshark developer is to extend an existing,
 or write a new dissector for a specific network protocol. As (almost) any
@@ -375,15 +375,15 @@ typically more up to date and the HTML format is easier to use.
 If you don't find the information you need inside this book, there are
 various other sources of information:
 
-* The file 'doc/README.developer' and all the other README.xxx files in the
+* The file _doc/README.developer_ and all the other README.xxx files in the
   source code. These are various documentation files on different topics
 
 [NOTE]
 .Read the README
 ====
-'README.developer' is packed full with all kinds of details relevant
+_README.developer_ is packed full with all kinds of details relevant
 to the developer of Wireshark source code. Its companion file
-'README.dissector' advises you around common
+_README.dissector_ advises you around common
 pitfalls, shows you basic layout of dissector code, shows details of the
 APIs available to the dissector developer, etc.
 ====
@@ -538,7 +538,7 @@ echoed. The ^D
 (Control-D, that is, press the Control key and the D key
 together) will cause `gdb` to exit. This will
 leave you with a file called
-'bt.txt' in the current directory.
+_bt.txt_ in the current directory.
 Include the file with your bug report.
 
 If you do not have `gdb` available, you
diff --git a/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc b/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
index dbfaa1c833..0cc3d3987c 100644
--- a/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_libraries.asciidoc
@@ -13,11 +13,11 @@
 Several libraries are needed to build and run Wireshark. Most of them
 are split into three packages:
 
-. 'Runtime'. System and third party libraries such as 'MSVCR110.dll' and 'libglib-2.0-0.dll'.
+. _Runtime_. System and third party libraries such as _MSVCR110.dll_ and _libglib-2.0-0.dll_.
 
-. 'Developer'. Documentation, header files, import libraries, and other files needed for compilation.
+. _Developer_. Documentation, header files, import libraries, and other files needed for compilation.
 
-. 'Source'. Library sources, which are usually not required to
+. _Source_. Library sources, which are usually not required to
 build Wireshark.
 
 [TIP]
@@ -99,8 +99,8 @@ For more information on the Qt libraries, see <<ChUIQt>>.
 
 Most Linux distributions provide Qt and its development libraries as standard packages.
 The required libraries and tools will likely be split across several packages. For example,
-building on Ubuntu requires 'qttools5-dev', 'qttools5-dev-tools', 'libqt5svg5-dev,
-'qtmultimedia5-dev', and possibly others.
+building on Ubuntu requires _qttools5-dev_, _qttools5-dev-tools_, _libqt5svg5-dev_,
+_qtmultimedia5-dev_, and possibly others.
 
 The Qt Project provides an installation tool for macOS, similar to Windows.
 It is available at https://www.qt.io/download-open-source/#section-2[].
@@ -243,7 +243,7 @@ platform, you can get it at {tcpdump-main-url}.
 
 ==== Win32 MSVC: WinPcap
 
-You can get the "Windows packet capture library" at:
+You can get the ``Windows packet capture library'' at:
 https://www.winpcap.org/install/[]
 
 [[ChLibsGNUTLS]]
diff --git a/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc b/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
index 36cd714166..218785eb5b 100644
--- a/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_quick_setup.asciidoc
@@ -65,7 +65,7 @@ You need to install, in exactly this order:
 
 . C compiler:
 https://go.microsoft.com/fwlink/?LinkId=532606&clcid=0x409[Download]
-and install "Microsoft Visual Studio 2015 Community Edition." This is a small
+and install ``Microsoft Visual Studio 2015 Community Edition.'' This is a small
 download that then downloads all the other required parts (which are quite large).
 
 Select the "Custom" install and then uncheck all the optional components other
@@ -120,9 +120,9 @@ Note that installation of separate Qt components are required for 32 bit
 and 64 bit builds, e.g. ``msvc2015 32-bit'' and ``msvc2015 64-bit''. The
 environment variable `QT5_BASE_DIR` should be set as appropriate for your
 environment and should point to the Qt directory that contains the bin
-directory, e.g. 'C:\Qt\5.9.1\msvc2015_64'
+directory, e.g. _C:\Qt\5.9.1\msvc2015_64_
 
-The Qt maintenance tool ('C:\Qt\MaintenanceTool.exe') can be used to
+The Qt maintenance tool (_C:\Qt\MaintenanceTool.exe_) can be used to
 upgrade Qt to newer versions.
 
 [[ChSetupCygwin]]
@@ -177,7 +177,7 @@ PS$>choco install cyg-get
 ----
 //PS$>choco install sed asciidoc [...] -source cygwin
 
-Chocolatey installs Cygwin in 'C:\tools\cygwin' by default.
+Chocolatey installs Cygwin in _C:\tools\cygwin_ by default.
 
 You can directly download packages via `cyg-get`
 
@@ -197,9 +197,9 @@ PS$>choco install winflexbison
 ==== Install Python
 
 Get the Python 3.5 or 2.7 installer from http://python.org/download/[] and
-install Python into the default location ('C:\Python35' or 'C:\Python27').
+install Python into the default location (_C:\Python35_ or _C:\Python27_).
 
-Why is this recommended? Cygwin's '/usr/bin/python' is a Cygwin-specific
+Why is this recommended? Cygwin's _/usr/bin/python_ is a Cygwin-specific
 symbolic link which cannot be run from Windows. The native package is faster
 as well.
 
@@ -215,7 +215,7 @@ or
 PS$>choco install python2
 ----
 
-Chocolatey installs Python in 'C:\tools\python3' and 'C:\tools\python2' by default.
+Chocolatey installs Python in _C:\tools\python3_ and _C:\tools\python2_ by default.
 
 [[ChSetupGit]]
 
@@ -235,9 +235,9 @@ available at the URLs below or via https://chocolatey.org/[Chocolatey].
 Note that many of the GUI interfaces depend on the command line version.
 
 If installing the Windows version of git select the
-'Use Git from the Windows Command Prompt' (in chocolatey the '/GitOnlyOnPath'
-option).  Do *not* select the 'Use Git and optional Unix tools from the Windows Command Prompt'
-option (in chocolatey the '/GitAndUnixToolsOnPath' option).
+_Use Git from the Windows Command Prompt_ (in chocolatey the _/GitOnlyOnPath_
+option).  Do *not* select the _Use Git and optional Unix tools from the Windows Command Prompt_
+option (in chocolatey the _/GitAndUnixToolsOnPath_ option).
 
 ===== The Official Windows Installer
 
@@ -296,7 +296,7 @@ Git Extensions but any other Git client should work as well.
 // XXX -
 
 *Download sources* Download Wireshark sources into
-'C:\Development\wireshark' using either the command line or Git Extensions:
+_C:\Development\wireshark_ using either the command line or Git Extensions:
 
 Using the command line:
 
@@ -316,9 +316,9 @@ Using Git extensions:
 +
 Repository to clone: *`https://code.wireshark.org/review/wireshark`*
 +
-Destination: Your top-level development directory, e.g. 'C:\Development'.
+Destination: Your top-level development directory, e.g. _C:\Development_.
 +
-Subdirectory to create: Anything you'd like. Usually 'wireshark'.
+Subdirectory to create: Anything you'd like. Usually _wireshark_.
 +
 [TIP]
 .Check your paths
@@ -478,7 +478,7 @@ to build Wireshark.
 version, e.g.: Version {wireshark-version}-myprotocol123
 congratulations! You have compiled your own version of Wireshark!
 
-You may also open the Wireshark solution file ('Wireshark.sln') in the Visual Studio IDE and build there.
+You may also open the Wireshark solution file (_Wireshark.sln_) in the Visual Studio IDE and build there.
 
 TIP: If compilation fails for suspicious reasons after you changed some source
 files try to clean the build files by running *`msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln /t:Clean`*
@@ -494,7 +494,7 @@ on using the <<ChToolsDebugger, Debugger Tools>>.
 ==== Optional: Create User's and Developer's Guide
 
 Detailed information to build these guides can be found in the file
-'docbook\README.txt' in the Wireshark sources.
+_docbook\README.txt_ in the Wireshark sources.
 
 ==== Optional: Create a Wireshark Installer
 
@@ -502,7 +502,7 @@ Note: You should have successfully built Wireshark
 before doing the following.
 
 If you want to build your own
-'Wireshark-win32-{wireshark-version}-myprotocol123.exe',
+_Wireshark-win32-{wireshark-version}-myprotocol123.exe_,
 you'll need NSIS.
 
 . NSIS:
@@ -512,13 +512,13 @@ Note that the 32-bit version of NSIS will work for both 32-bit and
 64-bit versions of Wireshark. NSIS v3 is recommended and may be required
 in the future.
 
-Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in './wireshark-win**XX**-libs' (where *'XX'* is 32 or 64) you will need to download the appropriate file and place it in './wireshark-win**XX**-libs' before starting this step.
+Note: If you do not yet have a copy of vcredist_x86.exe or vcredist_x64.exe in _./wireshark-win**XX**-libs_ (where *_XX_* is 32 or 64) you will need to download the appropriate file and place it in _./wireshark-win**XX**-libs_ before starting this step.
 
-If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory ('vcredist_x86.exe' in 'wireshark-32-libs' or 'vcredist_x64.exe' in 'wireshark-win64-libs').
+If building an x86 version using a Visual Studio "Express" edition or an x64 version with any edition, then you must have the appropriate vcredist file for your compiler in the support libraries directory (_vcredist_x86.exe_ in _wireshark-32-libs_ or _vcredist_x64.exe_ in _wireshark-win64-libs_).
 
 The files can be located in the Visual Studio install directory for non-Express edition builds, or downloaded from Microsoft for Expresss edition builds.
 
-Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name ('vcredist_x86.exe' or 'vcredist_x64.exe').  You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
+Note you must use the correct version of vcredist for your compiler, unfortunately they all have the same name (_vcredist_x86.exe_ or _vcredist_x64.exe_).  You can use Windows Explorer and examine the `Properties -> Details' tab for a vcredist file to determine which compiler version the file is for use with.
 
 . If you've closed the Visual Studio Command Prompt <<ChSetupPrepareCommandCom,prepare>> it again.
 
diff --git a/docbook/wsdg_src/WSDG_chapter_sources.asciidoc b/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
index 2177c445ed..01b2a59778 100644
--- a/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_sources.asciidoc
@@ -84,8 +84,8 @@ http://en.wikipedia.org/wiki/Branching_%28revision_control%29[branching] to
 manage different copies of the source code and allow parallel development.
 Wireshark uses the following branches for official releases:
 
-* 'master': Main feature development and odd-numbered "feature" releases.
-* 'master-x.y': Stable release maintenance. For example, master-1.10 is used
+* _master_: Main feature development and odd-numbered "feature" releases.
+* _master-x.y_: Stable release maintenance. For example, master-1.10 is used
   to manage the 1.10.x official releases.
 
 [[ChSrcObtain]]
@@ -155,7 +155,7 @@ select _Settings_.
 
 . Under _Profile_ set a username. This will be the username that
 you use for SSH access. For the steps below we'll assume that your
-username is +henry.perry+.
+username is `henry.perry`.
 
 . Select _SSH Public Keys_ and add one or more keys. You will typically
 upload a key for each computer that you use.
@@ -361,7 +361,7 @@ error-prone than using Git.
 
 The sources contain several documentation files. It's a good idea to read these
 files first. After obtaining the sources, tools and libraries, the first place
-to look at is 'doc/README.developer'. Inside you will find the latest
+to look at is _doc/README.developer_. Inside you will find the latest
 information for Wireshark development for all supported platforms.
 
 .Build Wireshark before changing anything
@@ -731,15 +731,15 @@ as described at <<ChSrcGit>>.
 Some tips that will make the merging of your changes into Git much more likely
 (and you want exactly that, don't you?):
 
-* 'Use the latest Git sources.' It's a good idea to work with the same
+* _Use the latest Git sources._ It's a good idea to work with the same
   sources that are used by the other developers. This usually makes it much
   easier to apply your patch. For information about the different ways to get
   the sources, see <<ChSrcObtain>>.
 
-* 'Update your sources just before making a patch.' For the same reasons as the
+* _Update your sources just before making a patch._ For the same reasons as the
   previous point.
 
-* 'Inspect your patch carefully.' Run `git diff` and make sure you aren't
+* _Inspect your patch carefully._ Run `git diff` and make sure you aren't
   adding, removing, or omitting anything you shouldn't.
 
 // * 'Do a "make clean" before generating the patch.' This removes a lot of
@@ -748,11 +748,11 @@ Some tips that will make the merging of your changes into Git much more likely
 //   the patch again.
 
 // XXX - What *are* good topic names?
-* 'Find a good descriptive topic name for your patch.' Short, specific
-  names are preferred. 'snowcone-machine-protocol' is good, your name or
+* _Find a good descriptive topic name for your patch._ Short, specific
+  names are preferred. _snowcone-machine-protocol_ is good, your name or
   your company name isn't.
 
-* 'Don't put unrelated things into one large patch.' A few smaller patches are
+* _Don't put unrelated things into one large patch._ A few smaller patches are
   usually easier to apply (but also don't put every changed line into a separate
   patch.
 
@@ -785,13 +785,13 @@ Ignoring the code requirements will make it very likely that your patch will
 be rejected.
 ====
 
-* 'Follow the Wireshark source code style guide.' Just because something
+* _Follow the Wireshark source code style guide._ Just because something
   compiles on your platform, that doesn't mean it'll compile on all of the other
   platforms for which Wireshark is built. Wireshark runs on many platforms, and
   can be compiled with a number of different compilers. See <<ChCodeStyle>>for
   details.
 
-* 'Submit dissectors as built-in whenever possible.' Developing a new dissector
+* _Submit dissectors as built-in whenever possible._ Developing a new dissector
 as a plugin is a good idea because compiling and testing is quicker, but it's
 best to convert dissectors to the built-in style before submitting for check in.
 This reduces the number of files that must be installed with Wireshark and
@@ -802,7 +802,7 @@ can easily be put into "the big pile", while some are ASN.1 based which takes a
 different approach, and some multiple source file dissectors are more suitable to
 be placed separately as plugins.
 
-* 'Ensure Wireshark Git Pre-Commit Hook is in the repository.'  In your local
+* _Ensure Wireshark Git Pre-Commit Hook is in the repository._  In your local
 repository directory, there will be a .git/hooks/ directory, with sample git hooks
 for running automatic actions before and after git commands. You can also
 optionally install other hooks that you find useful.
@@ -823,7 +823,7 @@ change, you can run git commit --no-verify to skip running the hooks. Warning: u
 Change-ID to your commit. In case you are not updating an existing patch you may generate
 a Change-ID by running git review -i (or git commit --amend if don't use git review).
 
-* 'Fuzz test your changes!' Fuzz testing is a very
+* _Fuzz test your changes!_ Fuzz testing is a very
 effective way to automatically find a lot of dissector related bugs.
 You'll take a capture file containing packets affecting your dissector
 and the fuzz test will randomly change bytes in this file, so that unusual
@@ -943,11 +943,11 @@ of the patch and your source files match.
 
 ==== Using patch
 
-Given the file 'new.diff' containing a unified diff,
+Given the file _new.diff_ containing a unified diff,
 the right way to call the patch tool depends on what the pathnames in
-'new.diff' look like.
+_new.diff_ look like.
 If they're relative to the top-level source directory (for example, if a
-patch to 'prefs.c' just has 'prefs.c' as the file name) you'd run it as:
+patch to _prefs.c_ just has _prefs.c_ as the file name) you'd run it as:
 
 ----
 $ patch -p0 < new.diff
@@ -955,24 +955,24 @@ $ patch -p0 < new.diff
 
 If they're relative to a higher-level directory, you'd replace 0 with the
 number of higher-level directories in the path, e.g. if the names are
-'wireshark.orig/prefs.c' and
-'wireshark.mine/prefs.c', you'd run it with:
+_wireshark.orig/prefs.c_ and
+_wireshark.mine/prefs.c_, you'd run it with:
 
 ----
 $ patch -p1 < new.diff
 ----
 
-If they're relative to a 'subdirectory' of the top-level
-directory, you'd run `patch` in 'that' directory and run it with `-p0`.
+If they're relative to a _subdirectory_ of the top-level
+directory, you'd run `patch` in _that_ directory and run it with `-p0`.
 
 If you run it without `-pat` all, the patch tool
 flattens path names, so that if you
-have a patch file with patches to 'Makefile.am' and
-'wiretap/Makefile.am',
+have a patch file with patches to _Makefile.am_ and
+_wiretap/Makefile.am_,
 it'll try to apply the first patch to the top-level
-'Makefile.am' and then apply the
-'wiretap/Makefile.am' patch to the top-level
-'Makefile.am' as well.
+_Makefile.am_ and then apply the
+_wiretap/Makefile.am_ patch to the top-level
+_Makefile.am_ as well.
 
 At which position in the filesystem should the patch tool be called?
 
@@ -981,11 +981,11 @@ directory above that directory, you'd run it in the top-level source
 directory.
 
 If they're relative to a *subdirectory* -- for example,
-if somebody did a patch to 'packet-ip.c' and ran `diff` or `git diff` in
-the 'epan/dissectors' directory -- you'd run it in that subdirectory.
+if somebody did a patch to _packet-ip.c_ and ran `diff` or `git diff` in
+the _epan/dissectors_ directory -- you'd run it in that subdirectory.
 It is preferred that people *not* submit patches like
 that, especially if they're only patching files that exist in multiple
-directories such as 'Makefile.am'.
+directories such as _Makefile.am_.
 
 [[ChSrcBinary]]
 
@@ -1073,7 +1073,7 @@ installing the _qt-devel_ package.
 ==== macOS: .dmg packages
 
 The macOS Package is built using macOS packaging tools, based on information
-found in the source tree under 'packaging/macosx'. It must be built using
+found in the source tree under _packaging/macosx_. It must be built using
 CMake. In your build directory, type:
 
 ----
@@ -1089,10 +1089,10 @@ to build the macOS Package.
 The _Nullsoft Install System_ is a free installer generator for Windows
 systems. Instructions on installing it can be found in <<ChToolsNSIS>>.
 NSIS is script based. You can find the main Wireshark installer
-generation script at 'packaging/nsis/wireshark.nsi'.
+generation script at _packaging/nsis/wireshark.nsi_.
 
-When building with CMake you must first build the 'nsis_package_prep' target,
-followed by the 'nsis_package' target, e.g.
+When building with CMake you must first build the _nsis_package_prep_ target,
+followed by the _nsis_package_ target, e.g.
 
 ----
 > msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@@ -1109,8 +1109,8 @@ It might take some time, even on fast machines.
 ====
 
 If everything went well, you will now find something like:
-'wireshark-setup-{wireshark-version}.exe' in
-the 'packaging/nsis' directory in the source tree.
+_wireshark-setup-{wireshark-version}.exe_ in
+the _packaging/nsis_ directory in the source tree.
 
 [[ChSrcPortableApps]]
 
@@ -1119,7 +1119,7 @@ the 'packaging/nsis' directory in the source tree.
 _PortableApps.com_ is an environment that lets users run popular applications
 from portable media such as flash drives and cloud drive services.
 
-Install the 'PortableApps.com Platform'. Install for ``all users``, which
+Install the _PortableApps.com Platform_. Install for ``all users'', which
 will place it in `C:\PortableApps`. Add the following apps:
 
 - NSIS Portable (Unicode)
@@ -1127,9 +1127,9 @@ will place it in `C:\PortableApps`. Add the following apps:
 - PortableApps.com Launcher
 - PortableApps.com AppCompactor
 
-When building with CMake you must first build the 'nsis_package_prep' target
+When building with CMake you must first build the _nsis_package_prep_ target
 (which takes care of general packaging dependencies), followed by the
-'portableapps_package' target, e.g.
+_portableapps_package_ target, e.g.
 
 ----
 > msbuild /m /p:Configuration=RelWithDebInfo nsis_package_prep.vcxproj
@@ -1144,8 +1144,8 @@ It might take some time, even on fast machines.
 ====
 
 If everything went well, you will now find something like:
-'WiresharkPortable_{wireshark-version}.paf.exe' in
-the 'packaging/portableapps' directory.
+_WiresharkPortable_{wireshark-version}.paf.exe_ in
+the _packaging/portableapps_ directory.
 
 ++++++++++++++++++++++++++++++++++++++
 <!-- End of WSDG Chapter Sources -->
diff --git a/docbook/wsdg_src/WSDG_chapter_tools.asciidoc b/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
index 211d896e44..906359205f 100644
--- a/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_tools.asciidoc
@@ -55,18 +55,18 @@ many of the packages required for Wireshark development. Chocolatey can be
 obtained from the http://chocolatey.org[website] or from a Command Prompt:
 
 ----
-C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
+C:\>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
 ----
 
 or a Powershell prompt:
 
 ----
-PS:\>iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
+PS:\>iex ((new-object net.webclient).DownloadString(_https://chocolatey.org/install.ps1_))
 ----
 
 Chocolatey sometimes installs packages in unexpected locations. Cygwin is a notable
-example -- recent versions of the Cygwin package are installed in 'C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin' instead of Cygwin's default location
-('C:\cygwin' or 'C:\cygwin64').
+example -- recent versions of the Cygwin package are installed in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ instead of Cygwin's default location
+(_C:\cygwin_ or _C:\cygwin64_).
 
 [[ChToolsCygwin]]
 
@@ -75,29 +75,29 @@ example -- recent versions of the Cygwin package are installed in 'C:\ProgramDat
 Cygwin provides a lot of UNIX based tools on the Windows platform. It uses a UNIX
 emulation layer which might be a bit slower compared to the native Windows tools,
 but at an acceptable level. The installation and update is pretty easy and done
-through a single utility, 'setup-x86.exe' for 32-bit Windows and
-'setup-x86_64.exe' for 64-bit Windows.
+through a single utility, _setup-x86.exe_ for 32-bit Windows and
+_setup-x86_64.exe_ for 64-bit Windows.
 
 Over time the Wireshark development toolchain has been migrating away from Cygwin
 toward native tools and we hope to eliminate it as a requirement someday.
 
 Although Cygwin consists of several separate packages, the installation
-and update is done through a single utility, 'setup-x86.exe' or
-'setup-x86_64.exe', which acts similarly to other web based installers.
+and update is done through a single utility, _setup-x86.exe_ or
+_setup-x86_64.exe_, which acts similarly to other web based installers.
 You can install Cygwin and its packages using Chocolatey, but this is not
 recommended due to Chocolatey's default installation location, described
 in the previous section.
 
 ==== Installing Cygwin using the Cygwin installer
 
-You will find 'setup-x86.exe', for 32-bit systems, and
-'setup-x86_64.exe', for 64-bit systems, at
+You will find _setup-x86.exe_, for 32-bit systems, and
+_setup-x86_64.exe_, for 64-bit systems, at
 http://www.cygwin.com/install.html[]. Click on the link for the
 appropriate setup utility to download it. After the download completes,
 run it.
 
 All tools will be installed into one base folder. The default is
-'C:\cygwin' for the 32-bit installer and 'C:\cygwin64' for the 64-bit
+_C:\cygwin_ for the 32-bit installer and _C:\cygwin64_ for the 64-bit
 installer.
 
 The setup utility will ask you for some settings. The defaults
@@ -134,15 +134,15 @@ number will be displayed, so it will be automatically updated.  You can
 change the current setting by simply clicking at it, it will change
 between:
 
-* 'A specific version number.' This specific package version will be installed.
+* _A specific version number._ This specific package version will be installed.
 
-* 'Skip.' Not installed, no changes.
+* _Skip._ Not installed, no changes.
 
-* 'Keep.' Already installed, no changes.
+* _Keep._ Already installed, no changes.
 
-* 'Uninstall.' Uninstall this package.
+* _Uninstall._ Uninstall this package.
 
-* 'Reinstall.' Reinstall this package.
+* _Reinstall._ Reinstall this package.
 
 ==== Installing Cygwin using Chocolatey
 
@@ -155,7 +155,7 @@ PS$>choco install cygwin
 PS$>choco install cyg-get
 ----
 
-Chocolatey installs Cygwin in 'C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin' by default.
+Chocolatey installs Cygwin in _C:\ProgramData\chocolatey\lib\Cygwin\tools\cygwin_ by default.
 
 One or more Cygwin packages can be installed using `cyg-get`:
 
@@ -208,7 +208,7 @@ In particular, the macOS and Windows packages are built using CMake.
 
 Building with CMake typically includes creating a build directory and
 specifying a *generator*, aka a build tool. For example, to build
-Wireshark using Ninja in the directory 'wireshark-ninja' you might
+Wireshark using Ninja in the directory _wireshark-ninja_ you might
 run the following commands:
 
 ----
@@ -235,7 +235,7 @@ using the `-D` flag. Useful variables and generators include the following:
 
 -DENABLE_HTML_GUIDES=ON -DENABLE_PDF_GUIDES=ON:: Build documentation
 
--DCMAKE_C_FLAGS='-Qunused-arguments':: Make ccache and clang work together
++++-DCMAKE_C_FLAGS='-Qunused-arguments'+++:: Make ccache and clang work together
 
 -DPYTHON_EXECUTABLE=c:/Python27/python:: Force the Python path. Useful on Windows since Cygwin's /usrbin/python is a symlink.
 
@@ -364,52 +364,52 @@ Your version string may vary, of course.
 
 === Microsoft compiler toolchain (Windows native)
 
-To compile Wireshark on Windows using the Microsoft C/$$C++$$
+To compile Wireshark on Windows using the Microsoft C/{cpp}
 compiler, you'll need:
 
-. C compiler ('cl.exe')
+. C compiler (_cl.exe_)
 
-. Assembler ('ml.exe' for 32-bit targets and 'ml64.exe' for 64-bit targets)
+. Assembler (_ml.exe_ for 32-bit targets and _ml64.exe_ for 64-bit targets)
 
-. Linker ('link.exe')
+. Linker (_link.exe_)
 
-. Resource Compiler ('rc.exe')
+. Resource Compiler (_rc.exe_)
 
-. C runtime headers and libraries (e.g. 'stdio.h', 'msvcrt.lib')
+. C runtime headers and libraries (e.g. _stdio.h_, _msvcrt.lib_)
 
 . Windows platform headers and libraries (e.g.
-'windows.h', 'WSock32.lib')
+_windows.h_, _WSock32.lib_)
 +
 // Can we drop support for CHM?
-. HTML help headers and libraries ('htmlhelp.h', 'htmlhelp.lib')
+. HTML help headers and libraries (_htmlhelp.h_, _htmlhelp.lib_)
 
 ==== Official Toolchain Packages And Alternatives
 
-The official Wireshark 2.4.x releases are compiled using Microsoft Visual $$C++$$ 2015.
-The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual $$C++$$ 2013.
+The official Wireshark 2.4.x releases are compiled using Microsoft Visual {cpp} 2015.
+The Wireshark 2.2.x and 2.0.x releases are compiled using Microsoft Visual {cpp} 2013.
 The Wireshark 1.12.x and 1.10.x releases were compiled using
-Microsoft Visual $$C++$$ 2010 SP1.
+Microsoft Visual {cpp} 2010 SP1.
 The 1.8 releases were compiled using
-Microsoft Visual $$C++$$ 2010 SP1 as well.
+Microsoft Visual {cpp} 2010 SP1 as well.
 The 1.6, 1.4, and 1.2 releases were compiled using
-Microsoft Visual $$C++$$ 2008 SP1.
+Microsoft Visual {cpp} 2008 SP1.
 Other past releases, including the 1.0 branch,
-were compiled using Microsoft Visual $$C++$$ 6.0.
+were compiled using Microsoft Visual {cpp} 6.0.
 
 Using the release compilers is recommended for Wireshark development work.
 
 The older "Express
-Edition" compilers such as Visual $$C++$$ 2010 Express Edition SP1 can be
+Edition" compilers such as Visual {cpp} 2010 Express Edition SP1 can be
 used but any PortableApps packages you create with them
-will require the installation of a separate Visual $$C++$$
+will require the installation of a separate Visual {cpp}
 Redistributable package on any machine on which the PortableApps
 package is to be used. See
 <<msvc-runtime-redistributable>> below for more details.
 
-However, you might already have a different Microsoft $$C++$$ compiler
+However, you might already have a different Microsoft {cpp} compiler
 installed. It should be possible to use any of the following with the considerations listed:
 
-.Visual $$C++$$ 2013 Community Edition
+.Visual {cpp} 2013 Community Edition
 
 IDE + Debugger?:: Yes
 
@@ -419,7 +419,7 @@ SDK required for 64-bit builds?:: No
 
 CMake Generator: *`Visual Studio 12`*
 
-.Visual $$C++$$ 2010 Express Edition
+.Visual {cpp} 2010 Express Edition
 
 IDE + Debugger?:: Yes
 
@@ -429,13 +429,13 @@ SDK required for 64-bit builds?:: Yes.
 
 CMake Generator: *`Visual Studio 10`*
 
-Remarks:: Installers created using express editions require a $$C++$$ redistributable
-'$$vcredist_x86.exe$$' (3MB free
+Remarks:: Installers created using express editions require a {cpp} redistributable
+_vcredist_x86.exe_ (3MB free
 download) is required to build
 Wireshark-win32-{wireshark-version}.exe, and
-'$$vcredist_x64.exe$$' is required to build
+_vcredist_x64.exe_ is required to build
 Wireshark-win64-{wireshark-version}.exe. The version of
-'$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' _must_ match the version for your
+_vcredist_x86.exe_ or _vcredist_x64.exe_ _must_ match the version for your
 compiler including any service packs installed for the compiler.]
 
 .Visual Studio 2010
@@ -449,8 +449,8 @@ SDK required for 64-bit builds?:: No
 CMake Generator: *`Visual Studio 10`*
 
 Remarks:: Building a 64-bit installer
-requires a a $$C++$$ redistributable
-('$$vcredist_x86.exe$$').footnoteref[vcredist]
+requires a a {cpp} redistributable
+(_vcredist_x86.exe_).footnoteref[vcredist]
 
 You can use Chocolatey to install Visual Studio, e.g:
 
@@ -482,7 +482,7 @@ at the Visual Studio Command line prompt (cmd.exe):
 should result in something like:
 
 ----
-Microsoft (R) C/$$C++$$ Optimizing Compiler Version 18.00.31101 for x86
+Microsoft (R) C/{cpp} Optimizing Compiler Version 18.00.31101 for x86
 Copyright (C) Microsoft Corporation.  All rights reserved.
 
 usage: cl [ option... ] filename... [ /link linkoption...
@@ -531,12 +531,12 @@ they are available - but they might not be available on a user machine!
 
 This is especially true for the C runtime DLL (msvcr*.dll), which contains the
 implementation of ANSI and alike functions, e.g.: fopen(), malloc(). The DLL is
-named like: msvcr'version'.dll, an abbreviation for "MicroSoft Visual C
+named like: _msvcr**version**.dll_, an abbreviation for "Microsoft Visual C
 Runtime". For Wireshark to work, this DLL must be available on the users
 machine.
 
 Starting with MSVC7, it is necessary to ship the C runtime DLL
-(msvcr'version'.dll) together with the application installer somehow, as that
+(_msvcr**version**.dll_) together with the application installer somehow, as that
 DLL is possibly not available on the target system.
 
 
@@ -554,7 +554,7 @@ interested reader:
 
 * http://msdn.microsoft.com/en-us/library/ms235299.aspx[Redistributing Visual C++ Files]
 
-In all cases where '$$vcredist_x86.exe$$' or '$$vcredist_x64.exe$$' is
+In all cases where _vcredist_x86.exe_ or _vcredist_x64.exe_ is
 downloaded it should be downloaded to the directory into which the support
 libraries for Wireshark have been downloaded and installed. This directory is
 specified by the WIRESHARK_BASE_DIR or WIRESHARK_LIB_DIR environment variables.
@@ -566,42 +566,42 @@ There are three redistribution methods that MSDN
 mentions for MSVC 2013 (see:
 http://msdn.microsoft.com/en-us/library/vstudio/ms235316(v=vs.120).aspx["Choosing a Deployment Method"]):
 
-. 'Using Visual $$C++$$ Redistributable Package'.
+. _Using Visual {cpp} Redistributable Package._
 The Microsoft libraries are installed by copying
-'$$vcredist_x64.exe$$' or
-'$$vcredist_x86.exe$$' to the target
+_vcredist_x64.exe_ or
+_vcredist_x86.exe_ to the target
 machine and executing it on that machine (MSDN recommends
 this for applications built with Visual Studio 2013)
 
-. 'Using Visual $$C++$$ Redistributable Merge Modules'.
+. _Using Visual {cpp} Redistributable Merge Modules._
 (Loadable modules for building msi installers.
 Not suitable for Wireshark's NSIS based installer)
 
-. 'Install a particular Visual $$C++$$ assembly as a
-private assembly for the application'. The
+. _Install a particular Visual {cpp} assembly as a
+private assembly for the application._ The
 Microsoft libraries are installed by copying the folder
-content of 'Microsoft.VC120.CRT' to
-the target directory (e.g. 'C:\Program Files\Wireshark')
+content of _Microsoft.VC120.CRT_ to
+the target directory (e.g. _C:\Program Files\Wireshark_)
 
 To save installer size, and to make a portable
 version of Wireshark (which must be completely self-contained,
 on a medium such as a flash drive, and not require that an
 installer be run to install anything on the target machine)
 possible, when building 32-bit Wireshark with MSVC2013, method
-3 (copying the content of 'Microsoft.VC120.CRT')
+3 (copying the content of _Microsoft.VC120.CRT_)
 is used (this produces the smallest package).
 
 ==== Windows (Platform) SDK
 
 The Windows Platform SDK (PSDK) or Windows SDK is a free
 (as in beer) download and contains platform specific headers and
-libraries (e.g. 'windows.h', 'WSock32.lib', etc.). As new Windows
+libraries (e.g. _windows.h_, _WSock32.lib_, etc.). As new Windows
 features evolve in time, updated SDK's become available that
 include new and updated APIs.
 
 When you purchase a commercial Visual Studio or use the Community Edition, it will
 include an SDK. The free Express (as in beer) downloadable C compiler
-versions (V$$C++$$ 2012 Express, V$$C++$$ 2012 Express, etc.) do not
+versions (V{cpp} 2012 Express, V{cpp} 2012 Express, etc.) do not
 contain an SDK -- you'll need to download a PSDK in order to
 have the required C header files and libraries.
 
@@ -628,7 +628,7 @@ have a look at the HHC_DIR setting in the file docbook/Makefile.
 
 ===== HTML Help Build Files (htmlhelp.c / htmlhelp.lib)
 
-The files 'htmlhelp.c' and 'htmlhelp.lib' are required to
+The files _htmlhelp.c_ and _htmlhelp.lib_ are required to
 be able to open .chm files from Wireshark and show the
 online help. Both files are part of the SDK (standalone (P)SDK or MSVC
 since 2002).
@@ -759,7 +759,7 @@ Python 2.5 or later (including Python 3) should work fine and Python 3.5 and
 
 Python is either included or available as a package on most UNIX-like platforms.
 Windows packages and source are available at http://python.org/download/[].
-The Cygwin Python package is *not* recommended since '/usr/bin/python' is
+The Cygwin Python package is *not* recommended since _/usr/bin/python_ is
 a symbolic link, which causes confusion outside Cygwin.
 
 You can also use Chocolatey to install Python:
@@ -774,7 +774,7 @@ or
 PS:\> choco install Python2
 ----
 
-Chocolatey installs Python into 'C:\tools\python3' or 'C:\tools\python2' by
+Chocolatey installs Python into _C:\tools\python3_ or _C:\tools\python2_ by
 default. You can verify your Python version by running
 
 ----
@@ -934,7 +934,7 @@ Your version string may vary.
 
 A native Windows version of bison is available in the _winflexbison_
 https://chocolatey.org/[Chocolatey] package. Note that the executable is named
-'win_bison'.
+_win_bison_.
 
 Native packages are available from other sources such as
 http://gnuwin32.sourceforge.net/packages/bison.htm[GnuWin]. They aren't
@@ -977,7 +977,7 @@ Your version string may vary.
 
 A native Windows version of flex is available in the _winflexbison_
 https://chocolatey.org/[Chocolatey] package. Note that the executable is named
-'win_flex'.
+_win_flex_.
 
 ----
 PS:\>choco install winflexbison
@@ -1141,7 +1141,7 @@ installation should be straightforward.
 === Windows: NSIS (optional)
 
 The NSIS (Nullsoft Scriptable Install System) is used to generate
-'Wireshark-win32-{wireshark-version}.exe' from all the files
+_Wireshark-win32-{wireshark-version}.exe_ from all the files
 needed to be installed, including all required DLLs, plugins, and supporting
 files.
 
@@ -1158,7 +1158,7 @@ You can find more instructions on using NSIS in <<ChSrcNSIS>>.
 === Windows: PortableApps (optional)
 
 The PortableApps.com Installer is used to generate
-'WiresharkPortable-{wireshark-version}.paf.exe' from all the files
+_WiresharkPortable-{wireshark-version}.paf.exe_ from all the files
 needed to be installed, including all required DLLs, plugins, and supporting
 files.
 
diff --git a/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc b/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
index ce2a070a63..b97fe763fb 100644
--- a/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_userinterface.asciidoc
@@ -80,12 +80,12 @@ adding new UI features much easier. It doesn't work well on Windows at
 the present time, so it's recommended that you use it on macOS or Linux.
 
 To edit and build Wireshark using Qt Cretor, open the top-level
-'CMakeLists.txt' within Qt Creator. It should ask you to choose a build
+_CMakeLists.txt_ within Qt Creator. It should ask you to choose a build
 location. Do so. It should then ask you to run CMake. Fill in any
 desired build arguments (e.g. "-D CMAKE_BUILD_TYPE=Debug" or "-D
 ENABLE_GTK3=OFF") and click the ``Run CMake'' button. When that
 completes select ``Build → Open Build and Run Kit Selector...'' and make
-sure 'wireshark' is selected.
+sure _wireshark_ is selected.
 
 Note that Qt Creator uses output created by CMake's *CodeBlocks*
 generator. If you run CMake outside of Qt Creator you should use the
@@ -94,19 +94,19 @@ prompt you to re-run CMake.
 
 ==== Source Code Overview
 
-Wireshark's `main` entry point is in 'wireshark-qt.cpp'. Command-line arguments
+Wireshark's `main` entry point is in _wireshark-qt.cpp_. Command-line arguments
 are processed there and the main application class (`WiresharkApplication`)
 instance is created there along with the main window.
 
-The main window along with the rest of the application resides in 'ui/qt'. Due
-to its size the main window code is split into two modules, 'main_window.cpp'
-and 'main_window_slots.cpp'.
+The main window along with the rest of the application resides in _ui/qt_. Due
+to its size the main window code is split into two modules, _main_window.cpp_
+and _main_window_slots.cpp_.
 
-Most of the modules in 'ui/qt' are dialogs. Although we follow Qt naming
+Most of the modules in _ui/qt_ are dialogs. Although we follow Qt naming
 conventions for class names, we follow our own conventions by separating file
 name components with underscores. For example, ColoringRulesDialog is defined in
-'coloring_rules_dialog.cpp', 'coloring_rules_dialog.h', and
-'coloring_rules_dialog.ui'.
+_coloring_rules_dialog.cpp_, _coloring_rules_dialog.h_, and
+_coloring_rules_dialog.ui_.
 
 General-purpose dialogs are subclasses of `QDialog`. Dialogs that rely on the
 current capture file can subclass `WiresharkDialog`, which provides methods and
@@ -117,7 +117,7 @@ open when the capture file closes.
 
 ===== Names
 
-The code in 'ui/qt' directory uses three APIs: Qt (which uses
+The code in _ui/qt_ directory uses three APIs: Qt (which uses
 InterCapConvention), GLib (which uses underscore_convention), and the Wireshark
 API (which also uses underscore_convention). As a general rule Wireshark's Qt
 code uses InterCapConvention for class names, interCapConvention for methods,
@@ -175,18 +175,18 @@ QStrings are generally *much* safer and easier to use. They also make
 translations easier.
 
 If you need to pass strings between Qt and GLib you can use a number
-of convenience routines which are defined in 'ui/qt/qt_ui_utils.h'.
+of convenience routines which are defined in _ui/qt/qt_ui_utils.h_.
 
 If you're calling a function that returns wmem-allocated memory it might make
-more sense to add a wrapper function to 'qt_ui_utils' than to call wmem_free in
+more sense to add a wrapper function to _qt_ui_utils_ than to call wmem_free in
 your code.
 
-===== Mixing C and $$C++$$
+===== Mixing C and {cpp}
 
-Sometimes we have to call $$C++$$ functions from one of
-Wireshark's C callbacks and pass $$C++$$ objects to or from C. Tap
-listeners are a common example. The $$C++$$ FAQ link:$$http://www.
-parashift.com/c++-faq/mixing-c-and-cpp.html$$:[describes how to do this
+Sometimes we have to call {cpp} functions from one of
+Wireshark's C callbacks and pass {cpp} objects to or from C. Tap
+listeners are a common example. The {cpp} FAQ link:http://www.
+parashift.com/c++-faq/mixing-c-and-cpp.html:[describes how to do this
 safely].
 
 Tapping usually involves declaring static methods for callbacks, passing `this`
@@ -197,10 +197,10 @@ as the tap data.
 Qt provides a convenient method for translating text: `Qobject::tr()`,
 usually available as `tr()`.
 
-However, please avoid using `tr()` for static strings and define them in '*.ui'
+However, please avoid using `tr()` for static strings and define them in _*.ui_
 files instead. `tr()` on manually created objects like `QMenu` are not
 automatically retranslated and must instead be manually translated using
-`changeEvent()` and `retranslateUi()`. See 'summary_dialog.[ch]' for an example
+`changeEvent()` and `retranslateUi()`. See _summary_dialog.[ch]_ for an example
 of this.
 
 NOTE: If your object life is short and your components are (re)created
@@ -212,16 +212,16 @@ In most cases you should handle the changeEvent in order to catch
 Qt makes translating the Wireshark UI into different languages easy. To add a new
 translation, do the following:
 
-- Add your translation ('ui/qt/wireshark_XX.ts') to 'ui/qt/Makefile.am' and 'ui/qt/CMakeLists.txt'
-- (Recommended) Add a flag image for your language in 'images/languages/XX.svg'. Update 'image/languages/languages.qrc' accordingly.
+- Add your translation (_ui/qt/wireshark_XX.ts_) to _ui/qt/Makefile.am_ and _ui/qt/CMakeLists.txt_
+- (Recommended) Add a flag image for your language in _images/languages/XX.svg_. Update _image/languages/languages.qrc_ accordingly.
 - Run `lupdate ui/qt -ts ui/qt/wireshark_XX.ts` to generate/update your translation file.
 - Translate with Qt Linguist: `linguist ui/qt/wireshark_XX.ts`.
-- Do a test build and make sure the generated 'wireshark_XX.qm' binary file is included.
+- Do a test build and make sure the generated _wireshark_XX.qm_ binary file is included.
 - Push your translation to Gerrit for review. See <<ChSrcContribute>> for details.
 
-Alternatively you can put your QM and flag files in the 'languages'
+Alternatively you can put your QM and flag files in the _languages_
 directory in the Wireshark user configuration directory
-('$XDG_CONFIG_HOME/wireshark/languages/' or '$HOME/.wireshark/languages/' on
+(_$XDG_CONFIG_HOME/wireshark/languages/_ or _$HOME/.wireshark/languages/_ on
 UNIX).
 
 For more information about Qt Linguist see
@@ -254,7 +254,7 @@ doesn't meet your needs.
 ==== Other Issues and Information
 
 The main window has many QActions which are shared with child widgets. See
-'ui/qt/proto_tree.cpp' for an example of this.
+_ui/qt/proto_tree.cpp_ for an example of this.
 
 http://www.kdab.com/kdab-products/gammaray/[GammaRay] lets you inspect
 the internals of a running Qt application similar to $$Spy++$$ on Windows.
@@ -335,7 +335,7 @@ GTK 3.x depends on the following libraries:
 ==== Compatibility GTK versions
 
 The GTK library itself defines some values which makes it easy to distinguish
-between the versions, e.g. +GTK_MAJOR_VERSION+ and +GTK_MINOR_VERSION+ will be
+between the versions, e.g. `GTK_MAJOR_VERSION` and `GTK_MINOR_VERSION` will be
 set to the GTK version at compile time inside the gtkversion.h header.
 
 [[ChUIGTKWeb]]
diff --git a/docbook/wsdg_src/WSDG_chapter_works.asciidoc b/docbook/wsdg_src/WSDG_chapter_works.asciidoc
index 712063c023..07adfec2bd 100644
--- a/docbook/wsdg_src/WSDG_chapter_works.asciidoc
+++ b/docbook/wsdg_src/WSDG_chapter_works.asciidoc
@@ -26,29 +26,29 @@ image::wsdg_graphics/ws-function-blocks.png[{pdf-scaledwidth}]
 The function blocks in more detail:
 
 GUI:: Handling of all user input/output (all windows, dialogs and such).
-Source code can be found in the 'ui/qt' and 'ui/gtk' directory.
+Source code can be found in the _ui/qt_ and _ui/gtk_ directory.
 
 Core:: Main "glue code" that holds the other blocks together. Source
 code can be found in the root directory.
 
 Epan:: Ethereal Packet ANalyzer -- the packet analyzing engine.
-Source code can be found in the 'epan' directory. Epan provides
+Source code can be found in the _epan_ directory. Epan provides
 the following APIs:
 
 * Protocol Tree. Dissection information for an individual packet.
 
 * Dissectors. The various protocol dissectors in
-'epan/dissectors'.
+_epan/dissectors_.
 
 * Dissector Plugins - Support for implementing dissectors as separate modules.
-Source code can be found in 'plugins'.
+Source code can be found in _plugins_.
 
 * Display Filters - The display filter engine at
-'epan/dfilter'.
+_epan/dfilter_.
 
 Wiretap:: The wiretap library is used to read and write capture files in libpcap,
 pcapng, and many other file formats. Source code is in the
-'wiretap' directory.
+_wiretap_ directory.
 
 Capture:: The interface with the capture engine. Source code is in the
 root directory.