head	1.29;
access;
symbols
	core-8-5-9:1.22.2.1
	core-8-5-8:1.22
	macosx-cocoa-merge:1.25
	macosx-cocoa-premerge:1.25
	macosx-carbon-freeze:1.25
	core-8-5-7:1.22
	core-8-5-6:1.22
	core-8-6-b1:1.24
	core-8-6-a3:1.24
	core-8-5-5:1.22
	core-8-6-a2:1.23
	core-8-5-4:1.22
	core-8-5-3:1.22
	core-8-6-a1:1.22
	core-8-4-19:1.14.2.5
	core-8-5-branch:1.22.0.2
	core-8-5-2:1.22
	core-8-4-18:1.14.2.5
	core-8-5-1:1.22
	core-8-4-17:1.14.2.5
	core-8-5-0:1.22
	core-8-5-b3:1.21
	core-8-5-b2:1.20
	core-8-4-16:1.14.2.5
	core-8-5-b1:1.20
	core-stablilizer-merge:1.20
	core-stabilizer-branch:1.19.0.2
	core-stabilizer-merge:1.22
	core-8-4-15:1.14.2.4
	core-8-5-a6:1.19
	core-8-5-a5:1.19
	core-8-4-14:1.14.2.4
	core-8-5-a4:1.19
	core-8-4-13:1.14.2.4
	core-8-4-12:1.14.2.4
	core-8-4-11:1.14.2.4
	core-8-5-a3:1.19
	core-8-4-10:1.14.2.4
	core-8-4-9-branch:1.14.2.4.0.2
	core-8-5-a2:1.18
	core-8-4-9:1.14.2.4
	core-8-4-8:1.14.2.4
	core-8-4-7:1.14.2.3
	core-8-5-a1:1.16
	core-8-4-6:1.14.2.3
	core-8-4-5:1.14.2.3
	mistachkin-dev-branch:1.16.0.2
	core-8-4-4:1.14.2.3
	core-8-4-3:1.14
	core-8-4-branch:1.14.0.2
	core-8-4-2:1.14
	core-8-4-1:1.12
	core-8-3-5:1.4.2.1
	core-8-4-0:1.12
	macosx-8-4-merge-2002-08-31-trunk:1.12
	macosx-8-4-premerge-2002-08-31-branch:1.7.4.3
	macosx-8-4-premerge-2002-08-31-trunk:1.12
	macosx-8-4-merge-2002-08-30-branch:1.7.4.3
	macosx-8-4-merge-2002-08-30-trunk:1.12
	macosx-8-4-merge-2002-08-20-branch:1.7.4.3
	macosx-8-4-merge-2002-08-20-trunk:1.12
	core-8-4-b2:1.12
	core-8-4-b1:1.12
	macosx-premerge-6-9-02:1.7.4.1
	core-8-4-a4:1.9
	core-8-3-4:1.4.2.1
	macosx-8-4-branch:1.7.0.4
	macosx-8-4-branchpoint:1.7
	core-8-4-a3:1.7
	core-8-3-3:1.4.2.1
	dgp-privates-into-namespace:1.7.0.2
	tclpro-1-5-0:1.4
	core-8-4-win-speedup:1.6.0.2
	core-8-4-a2:1.6
	tclpro-1-4-1:1.4
	tclpro-1-4-0:1.4
	core-8-3-2:1.4
	ajuba-ajuba2-2-1-base:1.4
	ajuba-ajuba2-2-0:1.4
	core-8-4-a1:1.5
	core-8-3-1-branch:1.4.0.2
	core-8-3-1:1.4
	scriptics-sc-2-0-b5:1.4
	scriptics-sc-2-0-fixed:1.4
	scriptics-sc-2-0-b2:1.4
	scriptics-sc-2-0-b1:1.4
	core-8-3-0:1.4
	core-8-3-b2:1.3
	core-8-3-b1:1.3
	scriptics-sc-1-1:1.2
	scriptics-sc-1-1-b1:1.2
	core-8-2-3:1.2
	scriptics-sc-1-1-branch:1.2.0.16
	scriptics-sc-1-1-base:1.2
	scriptics-sc-1-0:1.2
	scriptics-sc-1-0-branch:1.2.0.14
	scriptics-sc-1-0-base:1.2
	core-8-2-2:1.2
	core-8-2-1:1.2
	scriptics-bc-1-0-b1:1.2
	core-8-2-1-branch:1.2.0.12
	scriptics-tclpro-1-3-0:1.2
	core-8-2-0:1.2
	core-8-2-b3-branch:1.2.0.10
	core-8-2-b3-base:1.2
	scriptics-tclpro-1-3-b4:1.2
	core-8-2-b2:1.2
	scriptics-tclpro-1-3-b3:1.2
	core-8-2-b1:1.2
	scriptics-tclpro-1-3-b2:1.2
	merge-to-mainline-5/21/99:1.2
	scriptics-tclpro-1-3-b2-branch:1.2.0.8
	core-8-1-1:1.2
	scriptics-tclpro-1-3-b1:1.2
	core-8-1-1-base:1.2
	core-8-1-0:1.2
	merge-to-mainline-4-29-99:1.2
	merge-to-mainline-4-23-99:1.2
	core-8-1-branch-old:1.1.0.4
	core-8-0-6-branch:1.2.0.6
	core-8-0-6-base:1.2
	core-8-0-5:1.2
	core-8-1-b3:1.1.4.1
	core-8-1-b2:1.1.4.1
	dev-8-1-stubs-branch:1.1.4.1.0.2
	dev-stubs-branch:1.2.0.4
	scriptics-tclpro-1-2:1.2
	scriptics-tclpro-1-2-b2:1.2
	core-8-1-merge-2/10/99:1.2
	core-8-0-5-branch:1.2.0.2
	core-8-0-5-base:1.2
	scriptics-tclpro-1-2-b1:1.2
	scriptics-tclpro-1-2-a1:1.2
	core-8-1-b1:1.1.4.1
	core-8-0-4:1.2
	core-8-1-a2:1.1
	core-8-0-2:1.1
	core-8-0-3:1.2;
locks; strict;
comment	@# @;


1.29
date	2010.04.09.14.45.35;	author nijtmans;	state Exp;
branches;
next	1.28;

1.28
date	2010.01.13.15.54.03;	author dkf;	state Exp;
branches;
next	1.27;

1.27
date	2010.01.08.10.31.40;	author dkf;	state Exp;
branches;
next	1.26;

1.26
date	2010.01.08.00.28.17;	author patthoyts;	state Exp;
branches;
next	1.25;

1.25
date	2008.12.28.13.08.38;	author dkf;	state Exp;
branches;
next	1.24;

1.24
date	2008.09.23.13.36.46;	author dkf;	state Exp;
branches;
next	1.23;

1.23
date	2008.06.30.22.57.03;	author dkf;	state Exp;
branches;
next	1.22;

1.22
date	2007.12.13.15.23.43;	author dgp;	state Exp;
branches
	1.22.2.1;
next	1.21;

1.21
date	2007.10.29.16.04.14;	author dkf;	state Exp;
branches;
next	1.20;

1.20
date	2007.06.05.12.56.03;	author dkf;	state Exp;
branches;
next	1.19;

1.19
date	2005.04.06.21.11.54;	author dkf;	state Exp;
branches
	1.19.2.1;
next	1.18;

1.18
date	2004.08.20.14.15.29;	author dkf;	state Exp;
branches;
next	1.17;

1.17
date	2004.06.21.15.07.53;	author dkf;	state Exp;
branches;
next	1.16;

1.16
date	2003.07.17.22.57.03;	author dkf;	state Exp;
branches;
next	1.15;

1.15
date	2003.07.14.22.58.26;	author dkf;	state Exp;
branches;
next	1.14;

1.14
date	2003.01.19.07.50.58;	author hobbs;	state Exp;
branches
	1.14.2.1;
next	1.13;

1.13
date	2002.12.17.15.28.19;	author dkf;	state Exp;
branches;
next	1.12;

1.12
date	2002.06.22.00.37.16;	author dkf;	state Exp;
branches;
next	1.11;

1.11
date	2002.06.14.13.35.47;	author dkf;	state Exp;
branches;
next	1.10;

1.10
date	2002.03.14.10.19.40;	author dkf;	state Exp;
branches;
next	1.9;

1.9
date	2002.03.02.23.37.13;	author hobbs;	state Exp;
branches;
next	1.8;

1.8
date	2002.02.01.14.27.30;	author dkf;	state Exp;
branches;
next	1.7;

1.7
date	2001.02.13.21.52.45;	author ericm;	state Exp;
branches
	1.7.4.1;
next	1.6;

1.6
date	2000.07.25.21.14.35;	author jenglish;	state Exp;
branches
	1.6.2.1;
next	1.5;

1.5
date	2000.05.23.00.31.36;	author hobbs;	state Exp;
branches;
next	1.4;

1.4
date	2000.01.26.21.11.00;	author ericm;	state Exp;
branches
	1.4.2.1;
next	1.3;

1.3
date	99.10.29.03.57.40;	author hobbs;	state Exp;
branches;
next	1.2;

1.2
date	98.09.14.18.22.59;	author stanton;	state Exp;
branches;
next	1.1;

1.1
date	98.04.01.09.39.55;	author rjohnson;	state Exp;
branches
	1.1.4.1;
next	;

1.1.4.1
date	98.09.30.02.16.26;	author stanton;	state Exp;
branches;
next	;

1.4.2.1
date	2001.04.04.07.23.48;	author hobbs;	state Exp;
branches;
next	;

1.6.2.1
date	2002.04.02.20.57.53;	author hobbs;	state Exp;
branches;
next	;

1.7.4.1
date	2002.02.05.02.25.14;	author wolfsuit;	state Exp;
branches;
next	1.7.4.2;

1.7.4.2
date	2002.06.10.05.38.23;	author wolfsuit;	state Exp;
branches;
next	1.7.4.3;

1.7.4.3
date	2002.08.20.20.27.00;	author das;	state Exp;
branches;
next	;

1.14.2.1
date	2003.07.14.22.59.34;	author dkf;	state Exp;
branches;
next	1.14.2.2;

1.14.2.2
date	2003.07.17.22.53.09;	author dkf;	state Exp;
branches;
next	1.14.2.3;

1.14.2.3
date	2003.07.17.22.55.27;	author dkf;	state Exp;
branches;
next	1.14.2.4;

1.14.2.4
date	2004.10.28.12.25.22;	author dkf;	state Exp;
branches;
next	1.14.2.5;

1.14.2.5
date	2007.06.05.12.58.18;	author dkf;	state Exp;
branches;
next	;

1.19.2.1
date	2007.06.05.14.11.23;	author dgp;	state Exp;
branches;
next	1.19.2.2;

1.19.2.2
date	2007.11.01.16.37.15;	author dgp;	state Exp;
branches;
next	;

1.22.2.1
date	2010.01.08.00.36.56;	author patthoyts;	state Exp;
branches;
next	;


desc
@@


1.29
log
@Follow-up to [Bug 2983824]: update doc
@
text
@'\"
'\" Copyright (c) 1994 The Australian National University
'\" Copyright (c) 1994-1997 Sun Microsystems, Inc.
'\"
'\" 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.
'\"
'\" RCS: @@(#) $Id: photo.n,v 1.28 2010/01/13 15:54:03 dkf Exp $
'\" 
.so man.macros
.TH photo n 4.0 Tk "Tk Built-In Commands"
.BS
'\" Note:  do not modify the .SH NAME line immediately below!
.SH NAME
photo \- Full-color images
.SH SYNOPSIS
.nf
\fBimage create photo \fR?\fIname\fR? ?\fIoptions\fR?

\fIimageName \fBblank\fR
\fIimageName \fBcget \fIoption\fR
\fIimageName \fBconfigure\fR ?\fIoption\fR? ?\fIvalue option value ...\fR?
\fIimageName \fBcopy \fIsourceImage\fR ?\fIoption value(s) ...\fR?
\fIimageName \fBdata\fR ?\fIoption value(s) ...\fR?
\fIimageName \fBget \fIx y\fR
\fIimageName \fBput \fIdata\fR ?\fIoption value(s) ...\fR?
\fIimageName \fBread \fIfilename\fR ?\fIoption value(s) ...\fR?
\fIimageName \fBredither\fR
\fIimageName \fBtransparency \fIsubcommand \fR?\fIarg arg ...\fR?
\fIimageName \fBwrite \fIfilename\fR ?\fIoption value(s) ...\fR?
.fi
.BE
.SH DESCRIPTION
.PP
A photo is an image whose pixels can display any color or be
transparent.  A photo image is stored internally in full color (32
bits per pixel), and is displayed using dithering if necessary.  Image
data for a photo image can be obtained from a file or a string, or it
can be supplied from
C code through a procedural interface.  At present, only
.VS 8.6
PNG,
.VE 8.6
GIF and PPM/PGM
formats are supported, but an interface exists to allow additional
image file formats to be added easily.  A photo image is transparent
in regions where no image data has been supplied
or where it has been set transparent by the \fBtransparency set\fR
subcommand.
.SH "CREATING PHOTOS"
.PP
Like all images, photos are created using the \fBimage create\fR
command.
Photos support the following \fIoptions\fR:
.TP
\fB\-data \fIstring\fR
.
Specifies the contents of the image as a string.  The string should
contain binary data or, for some formats, base64-encoded data (this is
currently guaranteed to be supported for PNG and GIF images). The
format of the
string must be one of those for which there is an image file format
handler that will accept string data.  If both the \fB\-data\fR
and \fB\-file\fR options are specified, the \fB\-file\fR option takes
precedence.
.TP
\fB\-format \fIformat-name\fR
.
Specifies the name of the file format for the data specified with the
\fB\-data\fR or \fB\-file\fR option.
.TP
\fB\-file \fIname\fR
.
\fIname\fR gives the name of a file that is to be read to supply data
for the photo image.  The file format must be one of those for which
there is an image file format handler that can read data.
.TP
\fB\-gamma \fIvalue\fR
.
Specifies that the colors allocated for displaying this image in a
window should be corrected for a non-linear display with the specified
gamma exponent value.  (The intensity produced by most
CRT displays is a power function of the input value, to a good
approximation; gamma is the exponent and is typically around 2).
The value specified must be greater than zero.  The default
value is one (no correction).  In general, values greater than one
will make the image lighter, and values less than one will make it
darker.
.TP
\fB\-height \fInumber\fR
.
Specifies the height of the image, in pixels.  This option is useful
primarily in situations where the user wishes to build up the contents
of the image piece by piece.  A value of zero (the default) allows the
image to expand or shrink vertically to fit the data stored in it.
.TP
\fB\-palette \fIpalette-spec\fR
.
Specifies the resolution of the color cube to be allocated for
displaying this image, and thus the number of colors used from the
colormaps of the windows where it is displayed.  The
\fIpalette-spec\fR string may be either a single decimal number,
specifying the number of shades of gray to use, or three decimal
numbers separated by slashes (/), specifying the number of shades of
red, green and blue to use, respectively.  If the first form (a single
number) is used, the image will be displayed in monochrome (i.e.,
grayscale).
.TP
\fB\-width \fInumber\fR
.
Specifies the width of the image, in pixels.    This option is useful
primarily in situations where the user wishes to build up the contents
of the image piece by piece.  A value of zero (the default) allows the
image to expand or shrink horizontally to fit the data stored in it.
.SH "IMAGE COMMAND"
.PP
When a photo image is created, Tk also creates a new command
whose name is the same as the image.
This command may be used to invoke various operations
on the image.
It has the following general form:
.CS
\fIimageName option \fR?\fIarg arg ...\fR?
.CE
\fIOption\fR and the \fIarg\fRs
determine the exact behavior of the command.
.PP
Those options that write data to the image generally expand the size
of the image, if necessary, to accommodate the data written to the
image, unless the user has specified non-zero values for the
\fB\-width\fR and/or \fB\-height\fR configuration options, in which
case the width and/or height, respectively, of the image will not be
changed.
.PP
The following commands are possible for photo images:
.TP
\fIimageName \fBblank\fR
.
Blank the image; that is, set the entire image to have no data, so it
will be displayed as transparent, and the background of whatever
window it is displayed in will show through.
.TP
\fIimageName \fBcget\fR \fIoption\fR
.
Returns the current value of the configuration option given
by \fIoption\fR.
\fIOption\fR may have any of the values accepted by the
\fBimage create\fR \fBphoto\fR command.
.TP
\fIimageName \fBconfigure\fR ?\fIoption\fR? ?\fIvalue option value ...\fR?
.
Query or modify the configuration options for the image.
If no \fIoption\fR is specified, returns a list describing all of
the available options for \fIimageName\fR (see \fBTk_ConfigureInfo\fR for
information on the format of this list).  If \fIoption\fR is specified
with no \fIvalue\fR, then the command returns a list describing the
one named option (this list will be identical to the corresponding
sublist of the value returned if no \fIoption\fR is specified).  If
one or more \fIoption\-value\fR pairs are specified, then the command
modifies the given option(s) to have the given value(s);  in
this case the command returns an empty string.
\fIOption\fR may have any of the values accepted by the
\fBimage create\fR \fBphoto\fR command.
.TP
\fIimageName \fBcopy\fR \fIsourceImage\fR ?\fIoption value(s) ...\fR?
.
Copies a region from the image called \fIsourceImage\fR (which must
be a photo image) to the image called \fIimageName\fR, possibly with
pixel zooming and/or subsampling.  If no options are specified, this
command copies the whole of \fIsourceImage\fR into \fIimageName\fR,
starting at coordinates (0,0) in \fIimageName\fR.  The following
options may be specified:
.RS
.TP
\fB\-from \fIx1 y1 x2 y2\fR
.
Specifies a rectangular sub-region of the source image to be copied.
(\fIx1,y1\fR) and (\fIx2,y2\fR) specify diagonally opposite corners of
the rectangle.  If \fIx2\fR and \fIy2\fR are not specified, the
default value is the bottom-right corner of the source image.  The
pixels copied will include the left and top edges of the specified
rectangle but not the bottom or right edges.  If the \fB\-from\fR
option is not given, the default is the whole source image.
.TP
\fB\-to \fIx1 y1 x2 y2\fR
.
Specifies a rectangular sub-region of the destination image to be
affected.  (\fIx1,y1\fR) and (\fIx2,y2\fR) specify diagonally opposite
corners of the rectangle.  If \fIx2\fR and \fIy2\fR are not specified,
the default value is (\fIx1,y1\fR) plus the size of the source
region (after subsampling and zooming, if specified).  If \fIx2\fR and
\fIy2\fR are specified, the source region will be replicated if
necessary to fill the destination region in a tiled fashion.
.TP
\fB\-shrink\fR
.
Specifies that the size of the destination image should be reduced, if
necessary, so that the region being copied into is at the bottom-right
corner of the image.  This option will not affect the width or height
of the image if the user has specified a non-zero value for the
\fB\-width\fR or \fB\-height\fR configuration option, respectively.
.TP
\fB\-zoom \fIx y\fR
.
Specifies that the source region should be magnified by a factor of
\fIx\fR in the X direction and \fIy\fR in the Y direction.  If \fIy\fR
is not given, the default value is the same as \fIx\fR.  With this
option, each pixel in the source image will be expanded into a block
of \fIx\fR x \fIy\fR pixels in the destination image, all the same
color.  \fIx\fR and \fIy\fR must be greater than 0.
.TP
\fB\-subsample \fIx y\fR
.
Specifies that the source image should be reduced in size by using
only every \fIx\fRth pixel in the X direction and \fIy\fRth pixel in
the Y direction.  Negative values will cause the image to be flipped
about the Y or X axes, respectively.  If \fIy\fR is not given, the
default value is the same as \fIx\fR.
.TP
\fB\-compositingrule \fIrule\fR
.
Specifies how transparent pixels in the source image are combined with
the destination image.  When a compositing rule of \fIoverlay\fR is
set, the old contents of the destination image are visible, as if the
source image were printed on a piece of transparent film and placed
over the top of the destination.  When a compositing rule of \fIset\fR
is set, the old contents of the destination image are discarded and
the source image is used as-is.  The default compositing rule is
\fIoverlay\fR.
.RE
.TP
\fIimageName \fBdata\fR ?\fIoption value(s) ...\fR?
.
Returns image data in the form of a string. The following options
may be specified:
.RS
.TP
\fB\-background\fI color\fR
.
If the color is specified, the data will not contain any transparency
information. In all transparent pixels the color will be replaced by
the specified color.
.TP
\fB\-format\fI format-name\fR
.
Specifies the name of the image file format handler to be used.
Specifically, this subcommand searches
for the first handler whose name matches an initial substring of
\fIformat-name\fR and which has the capability to read this image data.
If this option is not given, this subcommand uses the first
handler that has the capability to read the image data.
.TP
\fB\-from \fIx1 y1 x2 y2\fR
.
Specifies a rectangular region of \fIimageName\fR to be returned.
If only \fIx1\fR and \fIy1\fR are specified, the region
extends from \fI(x1,y1)\fR to the bottom-right corner of
\fIimageName\fR.  If all four coordinates are given, they specify
diagonally opposite corners of the rectangular region, including x1,y1
and excluding x2,y2.  The default, if this option is not given, is the
whole image.
.TP
\fB\-grayscale\fR
.
If this options is specified, the data will not contain color
information. All pixel data will be transformed into grayscale.
.RE
.TP
\fIimageName \fBget\fR \fIx y\fR
.
Returns the color of the pixel at coordinates (\fIx\fR,\fIy\fR) in the
image as a list of three integers between 0 and 255, representing the
red, green and blue components respectively.
.TP
\fIimageName \fBput\fR \fIdata\fR ?\fIoption value(s) ...\fR?
.
Sets pixels in \fI imageName\fR to the data specified in \fIdata\fR.
This command first searches the list of image file format handlers for
a handler that can interpret the data in \fIdata\fR, and then reads
the image encoded within into \fIimageName\fR (the destination image).
If \fIdata\fR does not match any known format, an attempt to interpret
it as a (top-to-bottom) list of scan-lines is made, with each
scan-line being a (left-to-right) list of pixel colors (see
\fBTk_GetColor\fR for a description of valid colors.)  Every scan-line
must be of the same length.  Note that when \fIdata\fR is a single
color name, you are instructing Tk to fill a rectangular region with
that color.  The following options may be specified:
.RS
.TP
\fB\-format \fIformat-name\fR
.
Specifies the format of the image data in \fIdata\fR.
Specifically, only image file format handlers whose names begin with
\fIformat-name\fR will be used while searching for an image data
format handler to read the data.
.TP
\fB\-to \fIx1 y1\fR ?\fIx2 y2\fR?
.
Specifies the coordinates of the top-left corner (\fIx1\fR,\fIy1\fR)
of the region of \fIimageName\fR into which the image data will be
copied.  The default position is (0,0).  If \fIx2\fR,\fIy2\fR is given
and \fIdata\fR is not large enough to cover the rectangle specified by
this option, the image data extracted will be tiled so it covers the
entire destination rectangle.  Note that if \fIdata\fR specifies a
single color value, then a region extending to the bottom-right corner
represented by (\fIx2\fR,\fIy2\fR) will be filled with that color.
.RE
.TP
\fIimageName \fBread\fR \fIfilename\fR ?\fIoption value(s) ...\fR?
.
Reads image data from the file named \fIfilename\fR into the image.
This command first searches the list of
image file format handlers for a handler that can interpret the data
in \fIfilename\fR, and then reads the image in \fIfilename\fR into
\fIimageName\fR (the destination image).  The following options may be
specified:
.RS
.TP
\fB\-format \fIformat-name\fR
.
Specifies the format of the image data in \fIfilename\fR.
Specifically, only image file format handlers whose names begin with
\fIformat-name\fR will be used while searching for an image data
format handler to read the data.
.TP
\fB\-from \fIx1 y1 x2 y2\fR
.
Specifies a rectangular sub-region of the image file data to be copied
to the destination image.  If only \fIx1\fR and \fIy1\fR are
specified, the region extends from (\fIx1,y1\fR) to the bottom-right
corner of the image in the image file.  If all four coordinates are
specified, they specify diagonally opposite corners or the region.
The default, if this option is not specified, is the whole of the
image in the image file.
.TP
\fB\-shrink\fR
.
If this option, the size of \fIimageName\fR will be reduced, if
necessary, so that the region into which the image file data are read
is at the bottom-right corner of the \fIimageName\fR.  This option
will not affect the width or height of the image if the user has
specified a non-zero value for the \fB\-width\fR or \fB\-height\fR
configuration option, respectively.
.TP
\fB\-to \fIx y\fR
.
Specifies the coordinates of the top-left corner of the region of
\fIimageName\fR into which data from \fIfilename\fR are to be read.
The default is (0,0).
.RE
.TP
\fIimageName \fBredither\fR
.
The dithering algorithm used in displaying photo images propagates
quantization errors from one pixel to its neighbors.
If the image data for \fIimageName\fR is supplied in pieces, the
dithered image may not be exactly correct.  Normally the difference is
not noticeable, but if it is a problem, this command can be used to
recalculate the dithered image in each window where the image is
displayed.
.TP
\fIimageName \fBtransparency \fIsubcommand \fR?\fIarg arg ...\fR?
.
Allows examination and manipulation of the transparency information in
the photo image.  Several subcommands are available:
.RS
.TP
\fIimageName \fBtransparency get \fIx y\fR
.
Returns a boolean indicating if the pixel at (\fIx\fR,\fIy\fR) is
transparent.
.TP
\fIimageName \fBtransparency set \fIx y boolean\fR
.
Makes the pixel at (\fIx\fR,\fIy\fR) transparent if \fIboolean\fR is
true, and makes that pixel opaque otherwise.
.RE
.TP
\fIimageName \fBwrite \fIfilename\fR ?\fIoption value(s) ...\fR?
.
Writes image data from \fIimageName\fR to a file named \fIfilename\fR.
The following options may be specified:
.RS
.TP
\fB\-background\fI color\fR
.
If the color is specified, the data will not contain any transparency
information. In all transparent pixels the color will be replaced by
the specified color.
.TP
\fB\-format\fI format-name\fR
.
Specifies the name of the image file format handler to be used to
write the data to the file.  Specifically, this subcommand searches
for the first handler whose name matches an initial substring of
\fIformat-name\fR and which has the capability to write an image
file.  If this option is not given, the format is guessed from
the file extension. If that cannot be determined, this subcommand
uses the first handler that has the capability to write an image file.
.TP
\fB\-from \fIx1 y1 x2 y2\fR
.
Specifies a rectangular region of \fIimageName\fR to be written to the
image file.  If only \fIx1\fR and \fIy1\fR are specified, the region
extends from \fI(x1,y1)\fR to the bottom-right corner of
\fIimageName\fR.  If all four coordinates are given, they specify
diagonally opposite corners of the rectangular region.  The default,
if this option is not given, is the whole image.
.TP
\fB\-grayscale\fR
.
If this options is specified, the data will not contain color
information. All pixel data will be transformed into grayscale.
.RE
.SH "IMAGE FORMATS"
.PP
The photo image code is structured to allow handlers for additional
image file formats to be added easily.  The photo image code maintains
a list of these handlers.  Handlers are added to the list by
registering them with a call to \fBTk_CreatePhotoImageFormat\fR.  The
standard Tk distribution comes with handlers for PPM/PGM, PNG and GIF
formats, which are automatically registered on initialization.
.PP
When reading an image file or processing
string data specified with the \fB\-data\fR configuration option, the
photo image code invokes each handler in turn until one is
found that claims to be able to read the data in the file or string.
Usually this will find the correct handler, but if it does not, the
user may give a format name with the \fB\-format\fR option to specify
which handler to use.  In fact the photo image code will try those
handlers whose names begin with the string specified for the
\fB\-format\fR option (the comparison is case-insensitive).  For
example, if the user specifies \fB\-format gif\fR, then a handler
named GIF87 or GIF89 may be invoked, but a handler
named JPEG may not (assuming that such handlers had been
registered).
.PP
When writing image data to a file, the processing of the
\fB\-format\fR option is slightly different: the string value given
for the \fB\-format\fR option must begin with the complete name of the
requested handler, and may contain additional information following
that, which the handler can use, for example, to specify which variant
to use of the formats supported by the handler.
Note that not all image handlers may support writing transparency data
to a file, even where the target image format does.
.SS "FORMAT SUBOPTIONS"
.PP
.VS 8.6
Some image formats support sub-options, which are specified at the time that
the image is loaded using additional words in the \fB\-format\fR option. At
the time of writing, the following are supported:
.TP
\fBgif \-index\fI indexValue\fR
.
When parsing a multi-part GIF image, Tk normally only accesses the first
image. By giving the \fB\-index\fR sub-option, the \fIindexValue\fR'th value
may be used instead. The \fIindexValue\fR must be an integer from 0 up to the
number of image parts in the GIF data.
.TP
\fBpng \-alpha\fI alphaValue\fR
.
An additional alpha filtering for the overall image, which allows the
background on which the image is displayed to show through. This usually also
has the effect of desaturating the image. The \fIalphaValue\fR must be between
0.0 and 1.0.
.VE 8.6
.SH "COLOR ALLOCATION"
.PP
When a photo image is displayed in a window, the photo image code
allocates colors to use to display the image and dithers the image, if
necessary, to display a reasonable approximation to the image using
the colors that are available.  The colors are allocated as a color
cube, that is, the number of colors allocated is the product of the
number of shades of red, green and blue.
.PP
Normally, the number of
colors allocated is chosen based on the depth of the window.  For
example, in an 8-bit PseudoColor window, the photo image code will
attempt to allocate seven shades of red, seven shades of green and
four shades of blue, for a total of 198 colors.  In a 1-bit StaticGray
(monochrome) window, it will allocate two colors, black and white.  In
a 24-bit DirectColor or TrueColor window, it will allocate 256 shades
each of red, green and blue.  Fortunately, because of the way that
pixel values can be combined in DirectColor and TrueColor windows,
this only requires 256 colors to be allocated.  If not all of the
colors can be allocated, the photo image code reduces the number of
shades of each primary color and tries again.
.PP
The user can exercise some control over the number of colors that a
photo image uses with the \fB\-palette\fR configuration option.  If
this option is used, it specifies the maximum number of shades of
each primary color to try to allocate.  It can also be used to force
the image to be displayed in shades of gray, even on a color display,
by giving a single number rather than three numbers separated by
slashes.
.SH CREDITS
.PP
The photo image type was designed and implemented by Paul Mackerras,
based on his earlier photo widget and some suggestions from
John Ousterhout.
.SH EXAMPLE
.PP
Load an image from a file and tile it to the size of a window, which
is useful for producing a tiled background:
.PP
.CS
# These lines should be called once
\fBimage create photo\fR untiled \-file "theFile.ppm"
\fBimage create photo\fR tiled

# These lines should be called whenever .someWidget changes
# size; a <Configure> binding is useful here
set width  [winfo width .someWidget]
set height [winfo height .someWidget]
tiled \fBcopy\fR untiled \-to 0 0 $width $height \-shrink
.CE
.PP
.VS 8.6
The PNG image loader allows the application of an additional alpha factor
during loading, which is useful for generating images suitable for disabled
buttons:
.PP
.CS
\fBimage create photo\fR icon \-file "icon.png"
\fBimage create photo\fR iconDisabled \-file "icon.png" \e
        \-format "png \-alpha 0.5"
button .b \-image icon \-disabledimage iconDisabled
.CE
.VE 8.6
.SH "SEE ALSO"
image(n)
.SH KEYWORDS
photo, image, color
'\" Local Variables:
'\" mode: nroff
'\" End:
@


1.28
log
@Add subcommands to SYNOPSIS, small improvement to cross-links
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.27 2010/01/08 10:31:40 dkf Exp $
d401 3
a403 2
file.  If this option is not given, this subcommand uses the first
handler that has the capability to write an image file.
@


1.27
log
@Minor formatting fix
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.26 2010/01/08 00:28:17 patthoyts Exp $
d21 1
d23 13
d152 1
a152 1
\fBimage create photo\fR command.
d167 1
a167 1
\fBimage create photo\fR command.
@


1.26
log
@[Bug 2927569] Corrected image put documentation for -to option.

Multiple edits have peverted the original meaning of the phrase 'image
file data' to reference a filename option that does not exist.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.25 2008/12/28 13:08:38 dkf Exp $
d47 1
d58 1
d63 1
d69 1
d81 1
d88 1
d100 1
d128 1
d134 1
d141 1
d156 1
d166 1
d176 1
d186 1
d194 1
d203 1
d211 1
d222 2
a223 1
\fIimageName \fBdata ?\fIoption value(s) ...\fR?
d229 1
d235 1
d244 1
d254 1
d260 1
d266 1
d281 1
d288 1
d300 1
d310 1
d317 1
d327 1
d336 1
d343 1
d352 2
a353 1
\fIimageName \fBtransparency \fIsubcommand ?arg arg ...?\fR
d359 1
d364 1
d370 1
d376 1
d382 1
d391 1
d400 1
@


1.25
log
@Implementation of TIP #244, PNG image support.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.24 2008/09/23 13:36:46 dkf Exp $
d264 2
a265 2
of the region of \fIimageName\fR into which data from \fIfilename\fR
are to be read.  The default is (0,0).  If \fIx2\fR,\fIy2\fR is given
@


1.24
log
@Fix [Bug 2118116]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.23 2008/06/30 22:57:03 dkf Exp $
d30 5
a34 1
C code through a procedural interface.  At present, only GIF and PPM/PGM
d49 2
a50 1
currently guaranteed to be supported for GIF images).  The format of the
d370 2
a371 2
standard Tk distribution comes with handlers for PPM/PGM and GIF formats,
which are automatically registered on initialization.
d395 21
d454 1
d466 13
@


1.23
log
@Minor doc updates (removing out of date changebars, improving typedef formatting,
 etc.)
@
text
@a0 1
'\" -*- nroff -*-
d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.22 2007/12/13 15:23:43 dgp Exp $
d443 3
@


1.22
log
@merge stable branch onto HEAD
@
text
@d1 1
d13 1
a13 1
'\" RCS: @@(#) $Id: photo.n,v 1.19.2.2 2007/11/01 16:37:15 dgp Exp $
a23 1

d426 1
a439 1

a441 1

@


1.22.2.1
log
@[Bug 2927569] Backported documentation fix for image put -to
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.22 2007/12/13 15:23:43 dgp Exp $
d260 2
a261 2
of the region of \fIimageName\fR into which the image data will be
copied.  The default position is (0,0).  If \fIx2\fR,\fIy2\fR is given
@


1.21
log
@Lots more GOOBE stuff. Now works with 'make html'!
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.20 2007/06/05 12:56:03 dkf Exp $
@


1.20
log
@Fix [Bug 1731348]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.19 2005/04/06 21:11:54 dkf Exp $
d373 1
a373 1
Usually this will find the correct handler, but if it doesn't, the
d430 1
a430 1
\fBimage create photo\fR untiled -file "theFile.ppm"
@


1.19
log
@Purge old and inaccurate .VS/.VE macros.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.18 2004/08/20 14:15:29 dkf Exp $
d44 3
a46 2
Specifies the contents of the image as a string.  The string can
contain base64 encoded data or binary data.  The format of the
@


1.19.2.1
log
@merge updates from HEAD
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.19 2005/04/06 21:11:54 dkf Exp $
d44 2
a45 3
Specifies the contents of the image as a string.  The string should
contain binary data or, for some formats, base64-encoded data (this is
currently guaranteed to be supported for GIF images).  The format of the
@


1.19.2.2
log
@merge updates from HEAD
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.19.2.1 2007/06/05 14:11:23 dgp Exp $
d373 1
a373 1
Usually this will find the correct handler, but if it does not, the
d430 1
a430 1
\fBimage create photo\fR untiled \-file "theFile.ppm"
@


1.18
log
@More doc fixes. [Patch 1012837]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.17 2004/06/21 15:07:53 dkf Exp $
a34 1
.VS 8.4
a36 1
.VE 8.4
a189 1
.VS 8.4
a197 1
.VE 8.4
a315 1
.VS 8.4
a327 1
.VE 8.4
a387 1
.VS 8.4
a389 1
.VE 8.4
@


1.17
log
@Added example
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.16 2003/07/17 22:57:03 dkf Exp $
d217 1
a217 1
for the first handler whose name matches a initial substring of
d348 1
a348 1
for the first handler whose name matches a initial substring of
@


1.16
log
@Better docs of [$photo put].  [Bug 728952]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.15 2003/07/14 22:58:26 dkf Exp $
a38 1

a94 1

a397 1

a426 1

d432 17
@


1.15
log
@Added missing .TP
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14 2003/01/19 07:50:58 hobbs Exp $
d248 7
a254 3
Note that \fIdata\fR may also be a single color name if you wish to
fill a rectangular region with that color.  The following options may
be specified:
d264 7
a270 4
Specifies the coordinates of the top-left corner (\fIx1\fR,\fIy1\fR) of the
region of \fIimageName\fR into which data from \fIfilename\fR are to be
read.  The default is (0,0).  If \fIx2\fR,\fIy2\fR is given and \fIdata\fR
is one color value, then a region extending to the bottom-right corner
@


1.14
log
@	* doc/photo.n: $image put only accepts -format and -to, and note
	extended use of -to.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.13 2002/12/17 15:28:19 dkf Exp $
d323 1
@


1.14.2.1
log
@Added missing .TP
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14 2003/01/19 07:50:58 hobbs Exp $
a322 1
.TP
@


1.14.2.2
log
@Better docs of [$photo put].  [Bug 728952]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14.2.1 2003/07/14 22:59:34 dkf Exp $
d248 3
a250 7
If \fIdata\fR does not match any known format, an attempt to interpret
it as a (top-to-bottom) list of scan-lines is made, with each
scan-line being a (left-to-right) list of pixel colors (see
\fBTk_GetColor\fR for a description of valid colors.)  Every scan-line
must be of the same length.  Note that when \fIdata\fR is a single
color name, you are instructing Tk to fill a rectangular region with
that color.  The following options may be specified:
d260 5
a264 8
Specifies the coordinates of the top-left corner (\fIx1\fR,\fIy1\fR)
of the region of \fIimageName\fR into which data from \fIfilename\fR
are to be read.  The default is (0,0).  If \fIx2\fR,\fIy2\fR is given
and \fIdata\fR is not large enough to cover the rectangle specified by
this option, the image data extracted will be tiled so it covers the
entire destination.  Note that if \fIdata\fR specifies a single color
value, then a region extending to the bottom-right corner represented
by (\fIx2\fR,\fIy2\fR) will be filled with that color.
@


1.14.2.3
log
@D'oh!  Important word missing...
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14.2.2 2003/07/17 22:53:09 dkf Exp $
d269 3
a271 3
entire destination rectangle.  Note that if \fIdata\fR specifies a
single color value, then a region extending to the bottom-right corner
represented by (\fIx2\fR,\fIy2\fR) will be filled with that color.
@


1.14.2.4
log
@More backporting of doc fixes
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14.2.3 2003/07/17 22:55:27 dkf Exp $
d39 1
d96 1
d219 1
a219 1
for the first handler whose name matches an initial substring of
d350 1
a350 1
for the first handler whose name matches an initial substring of
d400 1
d430 1
a435 17
.SH EXAMPLE
Load an image from a file and tile it to the size of a window, which
is useful for producing a tiled background:
.CS
# These lines should be called once
\fBimage create photo\fR untiled -file "theFile.ppm"
\fBimage create photo\fR tiled

# These lines should be called whenever .someWidget changes
# size; a <Configure> binding is useful here
set width  [winfo width .someWidget]
set height [winfo height .someWidget]
tiled \fBcopy\fR untiled \-to 0 0 $width $height \-shrink
.CE

.SH "SEE ALSO"
image(n)
@


1.14.2.5
log
@Fix [Bug 1731348]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.14.2.4 2004/10/28 12:25:22 dkf Exp $
d46 2
a47 3
Specifies the contents of the image as a string.  The string should
contain binary data or, for some formats, base64-encoded data (this is
currently guaranteed to be supported for GIF images).  The format of the
@


1.13
log
@Doc-fix: [$photo put] knows about solid colours, and not files. [Bug 640026]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.12 2002/06/22 00:37:16 dkf Exp $
d259 6
a264 20
\fB\-from \fIx1 y1 x2 y2\fR
Specifies a rectangular sub-region of the image file data to be
returned. If only \fIx1\fR and \fIy1\fR are specified, the region
extends from (\fIx1,y1\fR) to the bottom-right corner of the image
in the image file.  If all four coordinates are specified, they
specify diagonally opposite corners or the region. The default,
if this option is not specified, is the whole of the image.
.TP
\fB\-shrink\fR
If this option, the size of \fIimageName\fR will be reduced, if
necessary, so that the region into which the image file data are read
is at the bottom-right corner of the \fIimageName\fR.  This option
will not affect the width or height of the image if the user has
specified a non-zero value for the \fB\-width\fR or \fB\-height\fR
configuration option, respectively.
.TP
\fB\-to \fIx y\fR
Specifies the coordinates of the top-left corner of the region of
\fIimageName\fR into which data from \fIfilename\fR are to be read.
The default is (0,0).
@


1.12
log
@Fixes to make HTML generation work better.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.11 2002/06/14 13:35:47 dkf Exp $
d244 7
a250 6
Sets pixels in \fI imageName\fR to the data specified in
\fIdata\fR. This command first searches the list of image file
format handlers for a handler that can interpret the data
in \fIdata\fR, and then reads the image in \fIfilename\fR into
\fIimageName\fR (the destination image). The following options
may be specified:
@


1.11
log
@TIP#98 implementation; improved photo image copy and GIF frame access
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.10 2002/03/14 10:19:40 dkf Exp $
d199 1
a199 1
over the top of the destination.  When a compositing rule of \fIset\R
@


1.10
log
@Typo fix
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.9 2002/03/02 23:37:13 hobbs Exp $
d192 12
@


1.9
log
@nroff macro fix
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.8 2002/02/01 14:27:30 dkf Exp $
d324 1
a324 1
\fIimageName \fBtransparency get \fIx y boolean\fR
@


1.8
log
@Final part of TIP#14 support (photo image transparency access); the C API
stuff has been in there for ages for some reason...
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.7 2001/02/13 21:52:45 ericm Exp $
d36 1
a36 1
or where it has been set transparent by the \fBtransparency set\fB
@


1.7
log
@* doc/photo.n: [Bug 132213] Added clarification on interpretation
of ranges for "photoName data -from" subcommand.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.6 2000/07/25 21:14:35 jenglish Exp $
d34 5
a38 1
in regions where no image data has been supplied.
d315 15
d389 4
@


1.7.4.1
log
@Merge with current TOT
Added support for the wm stackorder command
Fixed crash when selecting Menu items in the Application menu that we didn't
put there.
Added first bits of the use of CG for low-level drawing.  The line-drawing works,
the rest doesn't yet.  You have to set the file static useCGDrawing to 1 and
rebuild to activate this code.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.7 2001/02/13 21:52:45 ericm Exp $
d34 1
a34 5
in regions where no image data has been supplied
.VS 8.4
or where it has been set transparent by the \fBtransparency set\fB
subcommand.
.VE 8.4
a310 15
\fIimageName \fBtransparency \fIsubcommand ?arg arg ...?\fR
.VS 8.4
Allows examination and manipulation of the transparency information in
the photo image.  Several subcommands are available:
.RS
.TP
\fIimageName \fBtransparency get \fIx y\fR
Returns a boolean indicating if the pixel at (\fIx\fR,\fIy\fR) is
transparent.
\fIimageName \fBtransparency get \fIx y boolean\fR
Makes the pixel at (\fIx\fR,\fIy\fR) transparent if \fIboolean\fR is
true, and makes that pixel opaque otherwise.
.RE
.VE 8.4
.TP
a369 4
.VS 8.4
Note that not all image handlers may support writing transparency data
to a file, even where the target image format does.
.VE 8.4
@


1.7.4.2
log
@Merging with TOT as of 06/09/2002.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id$
d36 1
a36 1
or where it has been set transparent by the \fBtransparency set\fR
d324 1
a324 1
\fIimageName \fBtransparency set \fIx y boolean\fR
@


1.7.4.3
log
@merged with trunk at tag macosx-8-4-merge-2002-08-20-trunk
@
text
@a191 12
.TP
\fB\-compositingrule \fIrule\fR
.VS 8.4
Specifies how transparent pixels in the source image are combined with
the destination image.  When a compositing rule of \fIoverlay\fR is
set, the old contents of the destination image are visible, as if the
source image were printed on a piece of transparent film and placed
over the top of the destination.  When a compositing rule of \fIset\fR
is set, the old contents of the destination image are discarded and
the source image is used as-is.  The default compositing rule is
\fIoverlay\fR.
.VE 8.4
@


1.6
log
@CanvPsY.3, ConfigWidg.3, CrtImgType.3, CrtItemType.3,
FontId.3, GetFont.3, canvas.n, font.n, options.n, text.n:
Documentation fix: Replaced references to XFontStruct *
and Tk_FontStruct with Tk_Font.
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.5 2000/05/23 00:31:36 hobbs Exp $
d213 3
a215 2
diagonally opposite corners of the rectangular region.  The default,
if this option is not given, is the whole image.
@


1.6.2.1
log
@sync with head
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.10 2002/03/14 10:19:40 dkf Exp $
d34 1
a34 5
in regions where no image data has been supplied
.VS 8.4
or where it has been set transparent by the \fBtransparency set\fR
subcommand.
.VE 8.4
d213 2
a214 3
diagonally opposite corners of the rectangular region, including x1,y1
and excluding x2,y2.  The default, if this option is not given, is the
whole image.
a309 15
\fIimageName \fBtransparency \fIsubcommand ?arg arg ...?\fR
.VS 8.4
Allows examination and manipulation of the transparency information in
the photo image.  Several subcommands are available:
.RS
.TP
\fIimageName \fBtransparency get \fIx y\fR
Returns a boolean indicating if the pixel at (\fIx\fR,\fIy\fR) is
transparent.
\fIimageName \fBtransparency set \fIx y boolean\fR
Makes the pixel at (\fIx\fR,\fIy\fR) transparent if \fIboolean\fR is
true, and makes that pixel opaque otherwise.
.RE
.VE 8.4
.TP
a368 4
.VS 8.4
Note that not all image handlers may support writing transparency data
to a file, even where the target image format does.
.VE 8.4
@


1.5
log
@	* doc/bind.n:
	* doc/canvas.n:
	* doc/entry.n:
	* doc/listbox.n:
	* doc/photo.n: doc fix-ups [Bug: 5396]
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.4 2000/01/26 21:11:00 ericm Exp $
a339 1
.TP
@


1.4
log
@* generic/tkImgPhoto.c: Added some comments regarding slow
processing of transparent images.

* generic/tkImgGIF.c: Improved GIF decoder for ~60% speed
increase.  Added some comments on how to further improve the
implementation, time permitting.

* doc/photo.n: Added a description of what the -data string can
contain (base64 or binary data).
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.3 1999/10/29 03:57:40 hobbs Exp $
d201 2
a202 2
Specifies the name of the image file format handler to be used to
write the data to the file.  Specifically, this subcommand searches
d204 3
a206 3
\fIformat-name\fR and which has the capability to write an image
file.  If this option is not given, this subcommand uses the first
handler that has the capability to write an image file.
d209 2
a210 2
Specifies a rectangular region of \fIimageName\fR to be written to the
image file.  If only \fIx1\fR and \fIy1\fR are specified, the region
@


1.4.2.1
log
@doc cleanup and clarifications from 8.4aCVS backport
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.7 2001/02/13 21:52:45 ericm Exp $
d201 2
a202 2
Specifies the name of the image file format handler to be used.
Specifically, this subcommand searches
d204 3
a206 3
\fIformat-name\fR and which has the capability to read this image data.
If this option is not given, this subcommand uses the first
handler that has the capability to read the image data.
d209 2
a210 2
Specifies a rectangular region of \fIimageName\fR to be returned.
If only \fIx1\fR and \fIy1\fR are specified, the region
d213 2
a214 3
diagonally opposite corners of the rectangular region, including x1,y1
and excluding x2,y2.  The default, if this option is not given, is the
whole image.
d340 1
@


1.3
log
@	* doc/CrtImgType.3:
	* doc/CrtPhImgFmt.3:
	* doc/FindPhoto.3:
	* doc/photo.n: new docs for Img patch mods
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.2 1998/09/14 18:22:59 stanton Exp $
d43 2
a44 1
Specifies the contents of the image as a string.  The format of the
@


1.2
log
@Replaced SCCS strings, fixed binary files
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id$
d27 1
a27 1
transparent.  A photo image is stored internally in full color (24
d189 31
d225 36
a260 14
\fIimageName \fBput \fIdata\fR ?\fB\-to\fI x1 y1 x2 y2\fR?
Sets pixels in \fIimageName\fR to the colors specified in \fIdata\fR.
\fIdata\fR is used to form a two-dimensional array of pixels that are
then copied into the \fIimageName\fR.  \fIdata\fR is structured as a
list of horizontal rows, from top to bottom, each of which is a list
of colors, listed from left to right.  Each color may be specified by name
(e.g., blue) or in hexadecimal form (e.g., #2376af).  The
\fB\-to\fR option can be used to specify the area of \fIimageName\fR to be
affected.  If only \fIx1\fR and \fIy1\fR are given, the area affected
has its top-left corner at (\fIx1,y1\fR) and is the same size as the
array given in \fIdata\fR.  If all four coordinates are given, they
specify diagonally opposite corners of the affected rectangle, and the
array given in \fIdata\fR will be replicated as necessary in the X and
Y directions to fill the rectangle.
d314 5
d334 4
d339 1
@


1.1
log
@Initial revision
@
text
@d12 1
a12 1
'\" "@@(#) photo.n 1.12 97/10/14 10:52:30"
@


1.1.4.1
log
@Merged 8.0.3 changes into 8.1
@
text
@d12 1
a12 1
'\" RCS: @@(#) $Id: photo.n,v 1.2 1998/09/14 18:22:59 stanton Exp $
@


