Fix asciidoctor 'spaces' conversion issues

spring-boot-docs/src/main/asciidoc/howto.adoc

@@ -25,7 +25,7 @@ can send us a {github-code}[pull request].
 
 [[howto-troubleshoot-auto-configuration]]
 === Troubleshoot auto-configuration
-The Spring Boot auto-configuration tries its best to '`do the right thing`'    , but
+The Spring Boot auto-configuration tries its best to '`do the right thing`', but
 sometimes things fail and it can be hard to tell why.
 
 There is a really useful `AutoConfigurationReport` available in any Spring Boot
@@ -366,7 +366,7 @@ that and be sure that it has initialized is to add a `@Bean` of type
 out of the event when it is published.
 
 A really useful thing to do in is to use `@IntegrationTest` to set `server.port=0`
-and then inject the actual ('`local`'    ) port as a `@Value`. For example:
+and then inject the actual ('`local`') port as a `@Value`. For example:
 
 [source,java,indent=0,subs="verbatim,quotes,attributes"]
 ----
@@ -772,14 +772,14 @@ added.
 
 `WebMvcAutoConfiguration` adds the following `ViewResolvers` to your context:
 
-* An `InternalResourceViewResolver` with bean id '`defaultViewResolver`'    . This one locates
+* An `InternalResourceViewResolver` with bean id '`defaultViewResolver`'. This one locates
   physical resources that can be rendered using the `DefaultServlet` (e.g. static
   resources and JSP pages if you are using those). It applies a prefix and a suffix to the
   view name and then looks for a physical resource with that path in the servlet context
   (defaults are both empty, but accessible for external configuration via
   `spring.view.prefix` and `spring.view.suffix`). It can be overridden by providing a
   bean of the same type.
-* A `BeanNameViewResolver` with id '`beanNameViewResolver`'    . This is a useful member of the
+* A `BeanNameViewResolver` with id '`beanNameViewResolver`'. This is a useful member of the
   view resolver chain and will pick up any beans with the same name as the `View` being
   resolved. It shouldn't be necessary to override or replace it.
 * A `ContentNegotiatingViewResolver` with id '`viewResolver`' is only added if there *are*
@@ -789,27 +789,27 @@ added.
   https://spring.io/blog/2013/06/03/content-negotiation-using-views[blog about `ContentNegotiatingViewResolver`]
   that you might like to study to learn more, and also look at the source code for detail.
   You can switch off the auto-configured
-  `ContentNegotiatingViewResolver` by defining a bean named '`viewResolver`'    .
+  `ContentNegotiatingViewResolver` by defining a bean named '`viewResolver`'.
 * If you use Thymeleaf you will also have a `ThymeleafViewResolver` with id
-  '`thymeleafViewResolver`'    . It looks for resources by surrounding the view name with a
+  '`thymeleafViewResolver`'. It looks for resources by surrounding the view name with a
   prefix and suffix (externalized to `spring.thymeleaf.prefix` and
   `spring.thymeleaf.suffix`, defaults '`classpath:/templates/`' and '`.html`'
   respectively). It can be overridden by providing a bean of the same name.
 * If you use FreeMarker you will also have a `FreeMarkerViewResolver` with id
-  '`freeMarkerViewResolver`'    . It looks for resources in a loader path (externalized to
-  `spring.freemarker.templateLoaderPath`, default '`classpath:/templates/`'    ) by
+  '`freeMarkerViewResolver`'. It looks for resources in a loader path (externalized to
+  `spring.freemarker.templateLoaderPath`, default '`classpath:/templates/`') by
   surrounding the view name with a prefix and suffix (externalized to `spring.freemarker.prefix`
   and `spring.freemarker.suffix`, with empty and '`.ftl`' defaults respectively). It can
   be overridden by providing a bean of the same name.
 * If you use Groovy templates (actually if groovy-templates is on your classpath) you will
-  also have a `Groovy TemplateViewResolver` with id '`groovyTemplateViewResolver`'    . It
+  also have a `Groovy TemplateViewResolver` with id '`groovyTemplateViewResolver`'. It
   looks for resources in a loader path by surrounding the view name with a prefix and
   suffix (externalized to `spring.groovy.template.prefix` and
   `spring.groovy.template.suffix`, defaults '`classpath:/templates/`' and '`.tpl`'
   respectively). It can be overriden by providing a bean of the same name.
-* If you use Velocity you will also have a `VelocityViewResolver` with id '`velocityViewResolver`'    .
+* If you use Velocity you will also have a `VelocityViewResolver` with id '`velocityViewResolver`'.
   It looks for resources in a loader path (externalized to `spring.velocity.resourceLoaderPath`,
-  default '`classpath:/templates/`'    ) by surrounding the view name with a prefix and suffix
+  default '`classpath:/templates/`') by surrounding the view name with a prefix and suffix
   (externalized to `spring.velocity.prefix` and `spring.velocity.suffix`, with empty  and '`.vm`'
   defaults respectively). It can be overridden by providing a bean of the same name.
 
@@ -1063,7 +1063,7 @@ for more details.
 [[howto-use-custom-entity-manager]]
 === Use a custom EntityManagerFactory
 To take full control of the configuration of the `EntityManagerFactory`, you need to add
-a `@Bean` named '`entityManagerFactory`'    . Spring Boot auto-configuration switches off its
+a `@Bean` named '`entityManagerFactory`'. Spring Boot auto-configuration switches off its
 entity manager based on the presence of a bean of that type.
 
 
@@ -1118,7 +1118,7 @@ might be able to use a JTA transaction manager spanning both.
 Spring doesn't require the use of XML to configure the JPA provider, and Spring Boot
 assumes you want to take advantage of that feature. If you prefer to use `persistence.xml`
 then you need to define your own `@Bean` of type `LocalEntityManagerFactoryBean` (with
-id '`entityManagerFactory`'    , and set the persistence unit name there.
+id '`entityManagerFactory`', and set the persistence unit name there.
 
 See
 https://github.com/spring-projects/spring-boot/blob/master/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/orm/jpa/JpaBaseConfiguration.java[`JpaBaseConfiguration`]
@@ -1236,7 +1236,7 @@ To automatically run Flyway database migrations on startup, add the
 `org.flywaydb:flyway-core` to your classpath.
 
 The migrations are scripts in the form `V<VERSION>__<NAME>.sql` (with `<VERSION>` an
-underscore-separated version, e.g. '`1`'     or '`2_1`'    ). By default they live in a folder
+underscore-separated version, e.g. '`1`' or '`2_1`'). By default they live in a folder
 `classpath:db/migration` but you can modify that using `flyway.locations` (a list). See
 the Flyway class from flyway-core for details of available settings like schemas etc. In
 addition Spring Boot provides a small set of properties in
@@ -1637,7 +1637,7 @@ Boot Starter Parent to manage the plugin versions and other configuration defaul
 ----
 
 Two jars are produced, the default one, and an executable one using the Boot plugin with
-classifier '`exec`'    .
+classifier '`exec`'.
 
 For Gradle users the steps are similar. Example:
 
@@ -1868,7 +1868,7 @@ after which you can run the application with
 Use the `SpringBootServletInitializer` base class, which is picked up by Spring's
 Servlet 3.0 support on deployment. Add an extension of that to your project and build a
 war file as normal. For more detail, see the
-http://spring.io/guides/gs/convert-jar-to-war['`Converting a jar Project to a war`'    ] guide
+http://spring.io/guides/gs/convert-jar-to-war['`Converting a jar Project to a war`'] guide
 on the spring.io website and the sample below.
 
 The war file can also be executable if you use the Spring Boot build tools. In that case