Changes in 7e37361: spellcheck remote graphics

				remote_graphics.md
			
          @@ -14,7 +14,7 @@ Using `ssh -Y` or `ssh -X` requires less additional software, but can be problem

            1. If the local system is MacOS and you're using `ssh -Y` or `ssh -X`, XQuartz needs to be installed and functional for local programs (in other words, `echo $DISPLAY` and `launchctl getenv DISPLAY`).

            1. Check the (Workstation Setup Instructions)[workstation_setup] for missing packages.

          - 1. Check if non-OpenGL programs work over the remote connection; if not, programs using OpenGL will definately not work.  If things are failing at this stage, the XOrg logs (Linux, typically under `/var/log/Xorg.${n}.log`, where `${n}` is the session number) and XQuartz logs (MacOS, typically under `~/Library/Logs/X11/`) usually have information that's helpful for troubleshooting.  

          + 1. Check if non-OpenGL programs work over the remote connection; if not, programs using OpenGL will definitely not work.  If things are failing at this stage, the XOrg logs (Linux, typically under `/var/log/Xorg.${n}.log`, where `${n}` is the session number) and XQuartz logs (MacOS, typically under `~/Library/Logs/X11/`) usually have information that's helpful for troubleshooting.  

            1. Check that `glxinfo` works over the remote connection, and is reporting an OpenGL version equal to or greater than that required by the program you're using.  If `glxinfo` crashes, the same logs mentioned earlier are helpful for troubleshooting.  If `glxinfo` isn't installed, please check the [workstation setup](workstation_setup) page for missing dependencies.

            1. If there are still problems, when putting in support requests please include the relevant Xorg/XQuartz logs, `glxinfo` output, `sbinfo` output from the local and remote systems, and (for MacOS) the output of `defaults read org.xquartz.X11` (and `defaults read org.macos.xquartz`).

...	...	@@ -14,7 +14,7 @@ Using `ssh -Y` or `ssh -X` requires less additional software, but can be problem
14	14
15	15	1. If the local system is MacOS and you're using `ssh -Y` or `ssh -X`, XQuartz needs to be installed and functional for local programs (in other words, `echo $DISPLAY` and `launchctl getenv DISPLAY`).
16	16	1. Check the (Workstation Setup Instructions)[workstation_setup] for missing packages.
17		- 1. Check if non-OpenGL programs work over the remote connection; if not, programs using OpenGL will definately not work. If things are failing at this stage, the XOrg logs (Linux, typically under `/var/log/Xorg.${n}.log`, where `${n}` is the session number) and XQuartz logs (MacOS, typically under `~/Library/Logs/X11/`) usually have information that's helpful for troubleshooting.
	17	+ 1. Check if non-OpenGL programs work over the remote connection; if not, programs using OpenGL will definitely not work. If things are failing at this stage, the XOrg logs (Linux, typically under `/var/log/Xorg.${n}.log`, where `${n}` is the session number) and XQuartz logs (MacOS, typically under `~/Library/Logs/X11/`) usually have information that's helpful for troubleshooting.
18	18	1. Check that `glxinfo` works over the remote connection, and is reporting an OpenGL version equal to or greater than that required by the program you're using. If `glxinfo` crashes, the same logs mentioned earlier are helpful for troubleshooting. If `glxinfo` isn't installed, please check the [workstation setup](workstation_setup) page for missing dependencies.
19	19	1. If there are still problems, when putting in support requests please include the relevant Xorg/XQuartz logs, `glxinfo` output, `sbinfo` output from the local and remote systems, and (for MacOS) the output of `defaults read org.xquartz.X11` (and `defaults read org.macos.xquartz`).
20	20