|
0
|
1 |
<!-- Creator : groff version 1.18.1 -->
|
|
|
2 |
<!-- CreationDate: Mon Mar 13 18:03:08 2006 -->
|
|
|
3 |
<html>
|
|
|
4 |
<head>
|
|
|
5 |
<meta name="generator" content="groff -Thtml, see www.gnu.org">
|
|
|
6 |
<meta name="Content-Style" content="text/css">
|
|
|
7 |
<title>TIFFOpen</title>
|
|
|
8 |
</head>
|
|
|
9 |
<body>
|
|
|
10 |
|
|
|
11 |
<h1 align=center>TIFFOpen</h1>
|
|
|
12 |
<a href="#NAME">NAME</a><br>
|
|
|
13 |
<a href="#SYNOPSIS">SYNOPSIS</a><br>
|
|
|
14 |
<a href="#DESCRIPTION">DESCRIPTION</a><br>
|
|
|
15 |
<a href="#OPTIONS">OPTIONS</a><br>
|
|
|
16 |
<a href="#BYTE ORDER">BYTE ORDER</a><br>
|
|
|
17 |
<a href="#RETURN VALUES">RETURN VALUES</a><br>
|
|
|
18 |
<a href="#DIAGNOSTICS">DIAGNOSTICS</a><br>
|
|
|
19 |
<a href="#SEE ALSO">SEE ALSO</a><br>
|
|
|
20 |
|
|
|
21 |
<hr>
|
|
|
22 |
<a name="NAME"></a>
|
|
|
23 |
<h2>NAME</h2>
|
|
|
24 |
<!-- INDENTATION -->
|
|
|
25 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
26 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
27 |
<tr valign="top" align="left">
|
|
|
28 |
<td width="8%"></td>
|
|
|
29 |
<td width="91%">
|
|
|
30 |
<p>TIFFOpen, TIFFFdOpen, TIFFClientOpen − open a
|
|
|
31 |
<small>TIFF</small> file for reading or writing</p>
|
|
|
32 |
</td>
|
|
|
33 |
</table>
|
|
|
34 |
<a name="SYNOPSIS"></a>
|
|
|
35 |
<h2>SYNOPSIS</h2>
|
|
|
36 |
<!-- INDENTATION -->
|
|
|
37 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
38 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
39 |
<tr valign="top" align="left">
|
|
|
40 |
<td width="8%"></td>
|
|
|
41 |
<td width="91%">
|
|
|
42 |
<p><b>#include <tiffio.h></b></p>
|
|
|
43 |
<!-- INDENTATION -->
|
|
|
44 |
<p><b>TIFF* TIFFOpen(const char *</b><i>filename</i><b>,
|
|
|
45 |
const char *</b><i>mode</i><b>)<br>
|
|
|
46 |
TIFF* TIFFFdOpen(const int</b> <i>fd</i><b>, const char
|
|
|
47 |
*</b><i>filename</i><b>, const char
|
|
|
48 |
*</b><i>mode</i><b>)</b></p>
|
|
|
49 |
<!-- INDENTATION -->
|
|
|
50 |
<p><b>typedef tsize_t (*TIFFReadWriteProc)(thandle_t,
|
|
|
51 |
tdata_t, tsize_t);<br>
|
|
|
52 |
typedef toff_t (*TIFFSeekProc)(thandle_t, toff_t, int);<br>
|
|
|
53 |
typedef int (*TIFFCloseProc)(thandle_t);<br>
|
|
|
54 |
typedef toff_t (*TIFFSizeProc)(thandle_t);<br>
|
|
|
55 |
typedef int (*TIFFMapFileProc)(thandle_t, tdata_t*,
|
|
|
56 |
toff_t*);<br>
|
|
|
57 |
typedef void (*TIFFUnmapFileProc)(thandle_t, tdata_t,
|
|
|
58 |
toff_t);</b></p>
|
|
|
59 |
<!-- INDENTATION -->
|
|
|
60 |
<p><b>TIFF* TIFFClientOpen(const char
|
|
|
61 |
*</b><i>filename</i><b>, const char *</b><i>mode</i><b>,
|
|
|
62 |
thandle_t</b> <i>clientdata</i><b>, TIFFReadWriteProc</b>
|
|
|
63 |
<i>readproc</i><b>, TIFFReadWriteProc</b>
|
|
|
64 |
<i>writeproc</i><b>, TIFFSeekProc</b> <i>seekproc</i><b>,
|
|
|
65 |
TIFFCloseProc</b> <i>closeproc</i><b>, TIFFSizeProc</b>
|
|
|
66 |
<i>sizeproc</i><b>, TIFFMapFileProc</b> <i>mapproc</i><b>,
|
|
|
67 |
TIFFUnmapFileProc</b> <i>unmapproc</i><b>)</b></p>
|
|
|
68 |
</td>
|
|
|
69 |
</table>
|
|
|
70 |
<a name="DESCRIPTION"></a>
|
|
|
71 |
<h2>DESCRIPTION</h2>
|
|
|
72 |
<!-- INDENTATION -->
|
|
|
73 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
74 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
75 |
<tr valign="top" align="left">
|
|
|
76 |
<td width="8%"></td>
|
|
|
77 |
<td width="91%">
|
|
|
78 |
<p><i>TIFFOpen</i> opens a <small>TIFF</small> file whose
|
|
|
79 |
name is <i>filename</i> and returns a handle to be used in
|
|
|
80 |
subsequent calls to routines in <i>libtiff</i>. If the open
|
|
|
81 |
operation fails, then zero is returned. The <i>mode</i>
|
|
|
82 |
parameter specifies if the file is to be opened for reading
|
|
|
83 |
(‘‘r’’), writing
|
|
|
84 |
(‘‘w’’), or appending
|
|
|
85 |
(‘‘a’’) and, optionally, whether to
|
|
|
86 |
override certain default aspects of library operation (see
|
|
|
87 |
below). When a file is opened for appending, existing data
|
|
|
88 |
will not be touched; instead new data will be written as
|
|
|
89 |
additional subfiles. If an existing file is opened for
|
|
|
90 |
writing, all previous data is overwritten.</p>
|
|
|
91 |
<!-- INDENTATION -->
|
|
|
92 |
<p>If a file is opened for reading, the first
|
|
|
93 |
<small>TIFF</small> directory in the file is automatically
|
|
|
94 |
read (also see <i>TIFFSetDirectory</i>(3TIFF) for reading
|
|
|
95 |
directories other than the first). If a file is opened for
|
|
|
96 |
writing or appending, a default directory is automatically
|
|
|
97 |
created for writing subsequent data. This directory has all
|
|
|
98 |
the default values specified in <small>TIFF</small> Revision
|
|
|
99 |
6.0: <i>BitsPerSample</i>=1, <i>ThreshHolding</i>=bilevel
|
|
|
100 |
art scan, <i>FillOrder</i>=1 (most significant bit of each
|
|
|
101 |
data byte is filled first), <i>Orientation</i>=1 (the 0th
|
|
|
102 |
row represents the visual top of the image, and the 0th
|
|
|
103 |
column represents the visual left hand side),
|
|
|
104 |
<i>SamplesPerPixel</i>=1, <i>RowsPerStrip</i>=infinity,
|
|
|
105 |
<i>ResolutionUnit</i>=2 (inches), and <i>Compression</i>=1
|
|
|
106 |
(no compression). To alter these values, or to define values
|
|
|
107 |
for additional fields, <i>TIFFSetField</i>(3TIFF) must be
|
|
|
108 |
used.</p>
|
|
|
109 |
<!-- INDENTATION -->
|
|
|
110 |
<p><i>TIFFFdOpen</i> is like <i>TIFFOpen</i> except that it
|
|
|
111 |
opens a <small>TIFF</small> file given an open file
|
|
|
112 |
descriptor <i>fd</i>. The file’s name and mode must
|
|
|
113 |
reflect that of the open descriptor. The object associated
|
|
|
114 |
with the file descriptor <b>must support random
|
|
|
115 |
access</b>.</p>
|
|
|
116 |
<!-- INDENTATION -->
|
|
|
117 |
<p><i>TIFFClientOpen</i> is like <i>TIFFOpen</i> except that
|
|
|
118 |
the caller supplies a collection of functions that the
|
|
|
119 |
library will use to do <small>UNIX</small> -like I/O
|
|
|
120 |
operations. The <i>readproc</i> and <i>writeproc</i> are
|
|
|
121 |
called to read and write data at the current file position.
|
|
|
122 |
<i>seekproc</i> is called to change the current file
|
|
|
123 |
position a la <i>lseek</i>(2). <i>closeproc</i> is invoked
|
|
|
124 |
to release any resources associated with an open file.
|
|
|
125 |
<i>sizeproc</i> is invoked to obtain the size in bytes of a
|
|
|
126 |
file. <i>mapproc</i> and <i>unmapproc</i> are called to map
|
|
|
127 |
and unmap a file’s contents in memory; c.f.
|
|
|
128 |
<i>mmap</i>(2) and <i>munmap</i>(2). The <i>clientdata</i>
|
|
|
129 |
parameter is an opaque ‘‘handle’’
|
|
|
130 |
passed to the client-specified routines passed as parameters
|
|
|
131 |
to <i>TIFFClientOpen</i>.</p>
|
|
|
132 |
</td>
|
|
|
133 |
</table>
|
|
|
134 |
<a name="OPTIONS"></a>
|
|
|
135 |
<h2>OPTIONS</h2>
|
|
|
136 |
<!-- INDENTATION -->
|
|
|
137 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
138 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
139 |
<tr valign="top" align="left">
|
|
|
140 |
<td width="8%"></td>
|
|
|
141 |
<td width="91%">
|
|
|
142 |
<p>The open mode parameter can include the following flags
|
|
|
143 |
in addition to the ‘‘r’’,
|
|
|
144 |
‘‘w’’, and
|
|
|
145 |
‘‘a’’ flags. Note however that
|
|
|
146 |
option flags must follow the read-write-append
|
|
|
147 |
specification.</p>
|
|
|
148 |
</td>
|
|
|
149 |
</table>
|
|
|
150 |
<!-- TABS -->
|
|
|
151 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
152 |
cols="5" cellspacing="0" cellpadding="0">
|
|
|
153 |
<tr valign="top" align="left">
|
|
|
154 |
<td width="10%"></td>
|
|
|
155 |
<td width="2%">
|
|
|
156 |
|
|
|
157 |
<p><b>l</b></p>
|
|
|
158 |
</td>
|
|
|
159 |
<td width="6%"></td>
|
|
|
160 |
<td width="80%">
|
|
|
161 |
|
|
|
162 |
<p>When creating a new file force information be written
|
|
|
163 |
with Little-Endian byte order (but see below). By default
|
|
|
164 |
the library will create new files using the native
|
|
|
165 |
<small>CPU</small> byte order.</p>
|
|
|
166 |
</td>
|
|
|
167 |
<td width="0%">
|
|
|
168 |
</td>
|
|
|
169 |
<tr valign="top" align="left">
|
|
|
170 |
<td width="10%"></td>
|
|
|
171 |
<td width="2%">
|
|
|
172 |
|
|
|
173 |
<p><b>b</b></p>
|
|
|
174 |
</td>
|
|
|
175 |
<td width="6%"></td>
|
|
|
176 |
<td width="80%">
|
|
|
177 |
|
|
|
178 |
<p>When creating a new file force information be written
|
|
|
179 |
with Big-Endian byte order (but see below). By default the
|
|
|
180 |
library will create new files using the native
|
|
|
181 |
<small>CPU</small> byte order.</p>
|
|
|
182 |
</td>
|
|
|
183 |
<td width="0%">
|
|
|
184 |
</td>
|
|
|
185 |
<tr valign="top" align="left">
|
|
|
186 |
<td width="10%"></td>
|
|
|
187 |
<td width="2%">
|
|
|
188 |
|
|
|
189 |
<p><b>L</b></p>
|
|
|
190 |
</td>
|
|
|
191 |
<td width="6%"></td>
|
|
|
192 |
<td width="80%">
|
|
|
193 |
|
|
|
194 |
<p>Force image data that is read or written to be treated
|
|
|
195 |
with bits filled from Least Significant Bit (
|
|
|
196 |
<small>LSB</small> ) to Most Significant Bit (
|
|
|
197 |
<small>MSB</small> ). Note that this is the opposite to the
|
|
|
198 |
way the library has worked from its inception.</p>
|
|
|
199 |
</td>
|
|
|
200 |
<td width="0%">
|
|
|
201 |
</td>
|
|
|
202 |
<tr valign="top" align="left">
|
|
|
203 |
<td width="10%"></td>
|
|
|
204 |
<td width="2%">
|
|
|
205 |
|
|
|
206 |
<p><b>B</b></p>
|
|
|
207 |
</td>
|
|
|
208 |
<td width="6%"></td>
|
|
|
209 |
<td width="80%">
|
|
|
210 |
|
|
|
211 |
<p>Force image data that is read or written to be treated
|
|
|
212 |
with bits filled from Most Significant Bit (
|
|
|
213 |
<small>MSB</small> ) to Least Significant Bit (
|
|
|
214 |
<small>LSB</small> ); this is the default.</p>
|
|
|
215 |
</td>
|
|
|
216 |
<td width="0%">
|
|
|
217 |
</td>
|
|
|
218 |
<tr valign="top" align="left">
|
|
|
219 |
<td width="10%"></td>
|
|
|
220 |
<td width="2%">
|
|
|
221 |
|
|
|
222 |
<p><b>H</b></p>
|
|
|
223 |
</td>
|
|
|
224 |
<td width="6%"></td>
|
|
|
225 |
<td width="80%">
|
|
|
226 |
|
|
|
227 |
<p>Force image data that is read or written to be treated
|
|
|
228 |
with bits filled in the same order as the native
|
|
|
229 |
<small>CPU.</small></p>
|
|
|
230 |
</td>
|
|
|
231 |
<td width="0%">
|
|
|
232 |
</td>
|
|
|
233 |
<tr valign="top" align="left">
|
|
|
234 |
<td width="10%"></td>
|
|
|
235 |
<td width="2%">
|
|
|
236 |
|
|
|
237 |
<p><b>M</b></p>
|
|
|
238 |
</td>
|
|
|
239 |
<td width="6%"></td>
|
|
|
240 |
<td width="80%">
|
|
|
241 |
|
|
|
242 |
<p>Enable the use of memory-mapped files for images opened
|
|
|
243 |
read-only. If the underlying system does not support
|
|
|
244 |
memory-mapped files or if the specific image being opened
|
|
|
245 |
cannot be memory-mapped then the library will fallback to
|
|
|
246 |
using the normal system interface for reading information.
|
|
|
247 |
By default the library will attempt to use memory-mapped
|
|
|
248 |
files.</p>
|
|
|
249 |
</td>
|
|
|
250 |
<td width="0%">
|
|
|
251 |
</td>
|
|
|
252 |
<tr valign="top" align="left">
|
|
|
253 |
<td width="10%"></td>
|
|
|
254 |
<td width="2%">
|
|
|
255 |
|
|
|
256 |
<p><b>m</b></p>
|
|
|
257 |
</td>
|
|
|
258 |
<td width="6%"></td>
|
|
|
259 |
<td width="80%">
|
|
|
260 |
|
|
|
261 |
<p>Disable the use of memory-mapped files.</p>
|
|
|
262 |
</td>
|
|
|
263 |
<td width="0%">
|
|
|
264 |
</td>
|
|
|
265 |
<tr valign="top" align="left">
|
|
|
266 |
<td width="10%"></td>
|
|
|
267 |
<td width="2%">
|
|
|
268 |
|
|
|
269 |
<p><b>C</b></p>
|
|
|
270 |
</td>
|
|
|
271 |
<td width="6%"></td>
|
|
|
272 |
<td width="80%">
|
|
|
273 |
|
|
|
274 |
<p>Enable the use of ‘‘strip
|
|
|
275 |
chopping’’ when reading images that are
|
|
|
276 |
comprised of a single strip or tile of uncompressed data.
|
|
|
277 |
Strip chopping is a mechanism by which the library will
|
|
|
278 |
automatically convert the single-strip image to multiple
|
|
|
279 |
strips, each of which has about 8 Kilobytes of data. This
|
|
|
280 |
facility can be useful in reducing the amount of memory used
|
|
|
281 |
to read an image because the library normally reads each
|
|
|
282 |
strip in its entirety. Strip chopping does however alter the
|
|
|
283 |
apparent contents of the image because when an image is
|
|
|
284 |
divided into multiple strips it looks as though the
|
|
|
285 |
underlying file contains multiple separate strips. Finally,
|
|
|
286 |
note that default handling of strip chopping is a
|
|
|
287 |
compile-time configuration parameter. The default behaviour,
|
|
|
288 |
for backwards compatibility, is to enable strip
|
|
|
289 |
chopping.</p>
|
|
|
290 |
</td>
|
|
|
291 |
<td width="0%">
|
|
|
292 |
</td>
|
|
|
293 |
<tr valign="top" align="left">
|
|
|
294 |
<td width="10%"></td>
|
|
|
295 |
<td width="2%">
|
|
|
296 |
|
|
|
297 |
<p><b>c</b></p>
|
|
|
298 |
</td>
|
|
|
299 |
<td width="6%"></td>
|
|
|
300 |
<td width="80%">
|
|
|
301 |
|
|
|
302 |
<p>Disable the use of strip chopping when reading
|
|
|
303 |
images.</p>
|
|
|
304 |
</td>
|
|
|
305 |
<td width="0%">
|
|
|
306 |
</td>
|
|
|
307 |
<tr valign="top" align="left">
|
|
|
308 |
<td width="10%"></td>
|
|
|
309 |
<td width="2%">
|
|
|
310 |
|
|
|
311 |
<p><b>h</b></p>
|
|
|
312 |
</td>
|
|
|
313 |
<td width="6%"></td>
|
|
|
314 |
<td width="80%">
|
|
|
315 |
|
|
|
316 |
<p>Read TIFF header only, do not load the first image
|
|
|
317 |
directory. That could be useful in case of the broken first
|
|
|
318 |
directory. We can open the file and proceed to the other
|
|
|
319 |
directories.</p>
|
|
|
320 |
</td>
|
|
|
321 |
<td width="0%">
|
|
|
322 |
</td>
|
|
|
323 |
</table>
|
|
|
324 |
<a name="BYTE ORDER"></a>
|
|
|
325 |
<h2>BYTE ORDER</h2>
|
|
|
326 |
<!-- INDENTATION -->
|
|
|
327 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
328 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
329 |
<tr valign="top" align="left">
|
|
|
330 |
<td width="8%"></td>
|
|
|
331 |
<td width="91%">
|
|
|
332 |
<p>The <small>TIFF</small> specification (<b>all
|
|
|
333 |
versions</b>) states that compliant readers <i>must be
|
|
|
334 |
capable of reading images written in either byte order</i>.
|
|
|
335 |
Nonetheless some software that claims to support the reading
|
|
|
336 |
of <small>TIFF</small> images is incapable of reading images
|
|
|
337 |
in anything but the native <small>CPU</small> byte order on
|
|
|
338 |
which the software was written. (Especially notorious are
|
|
|
339 |
applications written to run on Intel-based machines.) By
|
|
|
340 |
default the library will create new files with the native
|
|
|
341 |
byte-order of the <small>CPU</small> on which the
|
|
|
342 |
application is run. This ensures optimal performance and is
|
|
|
343 |
portable to any application that conforms to the TIFF
|
|
|
344 |
specification. To force the library to use a specific
|
|
|
345 |
byte-order when creating a new file the
|
|
|
346 |
‘‘b’’ and
|
|
|
347 |
‘‘l’’ option flags may be included
|
|
|
348 |
in the call to open a file; for example,
|
|
|
349 |
‘‘wb’’ or
|
|
|
350 |
‘‘wl’’.</p>
|
|
|
351 |
</td>
|
|
|
352 |
</table>
|
|
|
353 |
<a name="RETURN VALUES"></a>
|
|
|
354 |
<h2>RETURN VALUES</h2>
|
|
|
355 |
<!-- INDENTATION -->
|
|
|
356 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
357 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
358 |
<tr valign="top" align="left">
|
|
|
359 |
<td width="8%"></td>
|
|
|
360 |
<td width="91%">
|
|
|
361 |
<p>Upon successful completion <i>TIFFOpen</i>,
|
|
|
362 |
<i>TIFFFdOpen</i>, and <i>TIFFClientOpen</i> return a
|
|
|
363 |
<small>TIFF</small> pointer. Otherwise, NULL is
|
|
|
364 |
returned.</p>
|
|
|
365 |
</td>
|
|
|
366 |
</table>
|
|
|
367 |
<a name="DIAGNOSTICS"></a>
|
|
|
368 |
<h2>DIAGNOSTICS</h2>
|
|
|
369 |
<!-- INDENTATION -->
|
|
|
370 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
371 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
372 |
<tr valign="top" align="left">
|
|
|
373 |
<td width="8%"></td>
|
|
|
374 |
<td width="91%">
|
|
|
375 |
<p>All error messages are directed to the
|
|
|
376 |
<i>TIFFError</i>(3TIFF) routine. Likewise, warning messages
|
|
|
377 |
are directed to the <i>TIFFWarning</i>(3TIFF) routine.</p>
|
|
|
378 |
<!-- INDENTATION -->
|
|
|
379 |
<p><b>"%s": Bad mode</b>. The specified
|
|
|
380 |
<i>mode</i> parameter was not one of
|
|
|
381 |
‘‘r’’ (read),
|
|
|
382 |
‘‘w’’ (write), or
|
|
|
383 |
‘‘a’’ (append).</p>
|
|
|
384 |
<!-- INDENTATION -->
|
|
|
385 |
<p><b>%s: Cannot open</b>. <i>TIFFOpen</i>() was unable to
|
|
|
386 |
open the specified filename for read/writing.</p>
|
|
|
387 |
<!-- INDENTATION -->
|
|
|
388 |
<p><b>Cannot read TIFF header</b>. An error occurred while
|
|
|
389 |
attempting to read the header information.</p>
|
|
|
390 |
<!-- INDENTATION -->
|
|
|
391 |
<p><b>Error writing TIFF header</b>. An error occurred while
|
|
|
392 |
writing the default header information for a new file.</p>
|
|
|
393 |
<!-- INDENTATION -->
|
|
|
394 |
<p><b>Not a TIFF file, bad magic number %d (0x%x)</b>. The
|
|
|
395 |
magic number in the header was not (hex) 0x4d4d or (hex)
|
|
|
396 |
0x4949.</p>
|
|
|
397 |
<!-- INDENTATION -->
|
|
|
398 |
<p><b>Not a TIFF file, bad version number %d (0x%x)</b>. The
|
|
|
399 |
version field in the header was not 42 (decimal).</p>
|
|
|
400 |
<!-- INDENTATION -->
|
|
|
401 |
<p><b>Cannot append to file that has opposite byte
|
|
|
402 |
ordering</b>. A file with a byte ordering opposite to the
|
|
|
403 |
native byte ordering of the current machine was opened for
|
|
|
404 |
appending (‘‘a’’). This is a
|
|
|
405 |
limitation of the library.</p>
|
|
|
406 |
</td>
|
|
|
407 |
</table>
|
|
|
408 |
<a name="SEE ALSO"></a>
|
|
|
409 |
<h2>SEE ALSO</h2>
|
|
|
410 |
<!-- INDENTATION -->
|
|
|
411 |
<table width="100%" border=0 rules="none" frame="void"
|
|
|
412 |
cols="2" cellspacing="0" cellpadding="0">
|
|
|
413 |
<tr valign="top" align="left">
|
|
|
414 |
<td width="8%"></td>
|
|
|
415 |
<td width="91%">
|
|
|
416 |
<p><i>libtiff</i>(3TIFF), <i>TIFFClose</i>(3TIFF)</p>
|
|
|
417 |
</td>
|
|
|
418 |
</table>
|
|
|
419 |
<hr>
|
|
|
420 |
</body>
|
|
|
421 |
</html>
|