Fixes reflow whitespace issue. (#10)

Author: kattni

docs/en/tutorial/topics/camera-access.md

@@ -91,8 +91,8 @@ def main():
 
 This code has two changes over the default app that is generated by Briefcase. These additions are highlighted above:
 
-1. The first highlighted code block (in the `startup()` method) adds  the two widgets needed to control the camera: an `ImageView` to  display a photo; and a `Button` to trigger the camera.
-2. The second highlighted code block (the `take_photo()` method)  defines the event handler when the button is pressed. This handler  first confirms if the application has permission to take a photo; if  permission doesn't exist, it is requested. Then, a photo is taken.  The request for permission and the request to take a photo are both  asynchronous requests, so they require the use of `await`; while the  app is waiting for the user to confirm permissions or take the  photo, the app's event loop can continue in the background.
+1. The first highlighted code block (in the `startup()` method) adds the two widgets needed to control the camera: an `ImageView` to display a photo; and a `Button` to trigger the camera.
+2. The second highlighted code block (the `take_photo()` method) defines the event handler when the button is pressed. This handler first confirms if the application has permission to take a photo; if permission doesn't exist, it is requested. Then, a photo is taken. The request for permission and the request to take a photo are both asynchronous requests, so they require the use of `await`; while the app is waiting for the user to confirm permissions or take the photo, the app's event loop can continue in the background.
 
 If the camera successfully takes a photo, it will return an `Image` object that can be assigned as the content of the `ImageView`. If the photo request was canceled by the user, the `self.camera.take_photo()` call will return `None`, and the result can be ignored. If the user doesn't grant permission to use the camera, or the camera isn't implemented on the current platform, an error will be raised, and a dialog will be shown to the user.
 

docs/en/tutorial/tutorial-3.md

@@ -113,15 +113,15 @@ Installing src/helloworld... done
 
 You've probably just seen pages of content go past in your terminal... so what just happened? Briefcase has done the following:
 
-1. It **generated an application template**. There's a lot of files and  configurations required to build a native installer, above and  beyond the code of your actual application. This extra scaffolding  is almost the same for every application on the same platform,  except for the name of the actual application being constructed - so  Briefcase provides an application template for each platform it  supports. This step rolls out the template, substituting the name of  your application, bundle ID, and other properties of your  configuration file as required to support the platform you're  building on.   If you're not happy with the template provided by Briefcase, you can  provide your own. However, you probably don't want to do this until  you've got a bit more experience using Briefcase's default template.
+1. It **generated an application template**. There's a lot of files and configurations required to build a native installer, above and beyond the code of your actual application. This extra scaffolding is almost the same for every application on the same platform, except for the name of the actual application being constructed - so Briefcase provides an application template for each platform it supports. This step rolls out the template, substituting the name of your application, bundle ID, and other properties of your configuration file as required to support the platform you're building on. If you're not happy with the template provided by Briefcase, you can provide your own. However, you probably don't want to do this until you've got a bit more experience using Briefcase's default template.
 
-2. It **downloaded and installed a support package**. The packaging  approach taken by Briefcase is best described as "the simplest thing  that could possibly work" - it ships a complete, isolated Python  interpreter as part of every application it builds (except for Linux  native system package builds). This is slightly space inefficient -  if you have 5 applications packaged with Briefcase, you'll have 5  copies of the Python interpreter. However, this approach guarantees  that every application is completely independent, using a specific  version of Python that is known to work with the application.   Again, Briefcase provides a default support package for each  platform; if you want, you can provide your own support package, and  have that package included as part of the build process. You may  want to do this if you have particular options in the Python  interpreter that you need to have enabled, or if you want to strip  modules out of the standard library that you don't need at runtime.   Briefcase maintains a local cache of support packages, so once  you've downloaded a specific support package, that cached copy will  be used on future builds.   As noted above, when Briefcase packages an app as a native Linux  system package (the default package format for Linux), a support  package is not included with the app. Instead, the app will use the  Python that is provided by the distribution of Linux being targeted.
+2. It **downloaded and installed a support package**. The packaging approach taken by Briefcase is best described as "the simplest thing that could possibly work" - it ships a complete, isolated Python interpreter as part of every application it builds (except for Linux native system package builds). This is slightly space inefficient - if you have 5 applications packaged with Briefcase, you'll have 5 copies of the Python interpreter. However, this approach guarantees that every application is completely independent, using a specific version of Python that is known to work with the application. Again, Briefcase provides a default support package for each platform; if you want, you can provide your own support package, and have that package included as part of the build process. You may want to do this if you have particular options in the Python interpreter that you need to have enabled, or if you want to strip modules out of the standard library that you don't need at runtime. Briefcase maintains a local cache of support packages, so once you've downloaded a specific support package, that cached copy will be used on future builds. As noted above, when Briefcase packages an app as a native Linux system package (the default package format for Linux), a support package is not included with the app. Instead, the app will use the Python that is provided by the distribution of Linux being targeted.
 
-3. It **installed application requirements**. Your application can  specify any third-party modules that are required at runtime. These  will be installed using `pip` into your application's installer.
+3. It **installed application requirements**. Your application can specify any third-party modules that are required at runtime. These will be installed using `pip` into your application's installer.
 
-4. It **Installed your application code**. Your application will have  its own code and resources (e.g., images that are needed at  runtime); these files are copied into the installer.
+4. It **Installed your application code**. Your application will have its own code and resources (e.g., images that are needed at runtime); these files are copied into the installer.
 
-5. It **installed your resources needed by your application.** Lastly,  it adds any additional resources that are needed by the installer  itself. This includes things like icons that need to be attached to  the final application and splash screen images.
+5. It **installed your resources needed by your application.** Lastly, it adds any additional resources that are needed by the installer itself. This includes things like icons that need to be attached to the final application and splash screen images.
 
 Once this completes, if you look in the project directory, you should now see a directory corresponding to your platform (`macOS`, `linux`, or `windows`) that contains additional files. This is the platform-specific packaging configuration for your application.