Typo (wehter -> whether) and minor consistancy in code comment (grey -> gray)

2 files changed, 12 insertions, 12 deletions

diff --git a/doc/FindPhoto.3 b/doc/FindPhoto.3
index 3f6b919..dc218bf 100644
--- a/doc/FindPhoto.3
+++ b/doc/FindPhoto.3
@@ -4,7 +4,7 @@
 '\"
 '\" See the file "license.terms" for information on usage and redistribution
 '\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
-'\" 
+'\"
 '\" Author: Paul Mackerras (paulus@cs.anu.edu.au),
 '\"	    Department of Computer Science,
 '\"	    Australian National University.
@@ -99,8 +99,8 @@ being written to the photo image.
 particular photo image to the other procedures.  The parameter is the
 name of the image, that is, the name specified to the \fBimage create
 photo\fR command, or assigned by that command if no name was specified.
-If \fIimageName\fR does not exist or is not a photo image, 
-\fBTk_FindPhoto\fR returns NULL. 
+If \fIimageName\fR does not exist or is not a photo image,
+\fBTk_FindPhoto\fR returns NULL.
 .PP
 \fBTk_PhotoPutBlock\fR is used to supply blocks of image data to be
 displayed.  The call affects an area of the image of size
@@ -193,16 +193,16 @@ that describe the address and layout of the image data that the
 photo image has stored internally.  The values are valid
 until the image is destroyed or its size is changed.
 .PP
-It is possible to modify an image by writing directly to the data 
+It is possible to modify an image by writing directly to the data
 the \fIpixelPtr\fR field points to. The size of the image cannot be
 changed this way, though.
-Also, changes made by writing directly to \fIpixelPtr\fR will not be 
-immediately visible, but only after a call to 
-\fBTk_ImageChanged\fR or after an event that causes the interested 
+Also, changes made by writing directly to \fIpixelPtr\fR will not be
+immediately visible, but only after a call to
+\fBTk_ImageChanged\fR or after an event that causes the interested
 widgets to redraw themselves.
-For these reasons usually it is preferable to make changes to 
-a copy of the image data and write it back with 
-\fBTk_PhotoPutBlock\fR or \fBTk_PhotoPutZoomedBlock\fR. 
+For these reasons usually it is preferable to make changes to
+a copy of the image data and write it back with
+\fBTk_PhotoPutBlock\fR or \fBTk_PhotoPutZoomedBlock\fR.
 .PP
 \fBTk_PhotoGetImage\fR returns 1 for compatibility with the
 corresponding procedure in the old photo widget.
@@ -263,7 +263,7 @@ The \fBTk_PhotoImageBlock\fR structure used to provide image data to
 data (e.g. separate planes for the red, green, blue and alpha
 channels).  Unfortunately, the implementation fails to hold this
 promise.  The problem is that the \fIpixelSize\fR field is
-(incorrectly) used to determine wehter the image has an alpha channel.
+(incorrectly) used to determine whether the image has an alpha channel.
 Currently, if the offset for the alpha channel is greater or equal than
 \fIpixelSize\fR, \fBtk_PhotoPutblock\fR assumes no alpha data is
 present and makes the image fully opaque.  This means that for layouts
diff --git a/generic/tkImgPhInstance.c b/generic/tkImgPhInstance.c
index 98aaeab..fd98c6e 100644
--- a/generic/tkImgPhInstance.c
+++ b/generic/tkImgPhInstance.c
@@ -1261,7 +1261,7 @@ AllocateColors(
 		}
 	    } else {
 		/*
-		 * Monochrome display - allocate the shades of grey we want.
+		 * Monochrome display - allocate the shades of gray we want.
 		 */
 
 		for (i = 0; i < numColors; ++i) {