From fa9b215690838b15cde6db8cf2be1545c20f6032 Mon Sep 17 00:00:00 2001 From: "jan.nijtmans" Date: Tue, 2 May 2017 08:41:01 +0000 Subject: Typo (wehter -> whether) and minor consistancy in code comment (grey -> gray) --- doc/FindPhoto.3 | 22 +++++++++++----------- generic/tkImgPhInstance.c | 2 +- 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) { -- cgit v0.12