diff options
Diffstat (limited to 'Master/xemtex/doc/ghostscript/Projects.htm')
-rw-r--r-- | Master/xemtex/doc/ghostscript/Projects.htm | 629 |
1 files changed, 0 insertions, 629 deletions
diff --git a/Master/xemtex/doc/ghostscript/Projects.htm b/Master/xemtex/doc/ghostscript/Projects.htm deleted file mode 100644 index 3ee7f5cad5f..00000000000 --- a/Master/xemtex/doc/ghostscript/Projects.htm +++ /dev/null @@ -1,629 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html> -<head> -<title>Ghostscript projects</title> -<!-- $Id: Projects.htm,v 1.33.2.11.2.6 2003/05/17 14:39:00 giles Exp $ --> -<link rel="stylesheet" type="text/css" href="gs.css" title="Ghostscript Style"> -</head> - -<body> -<!-- [1.0 begin visible header] ============================================ --> - -<!-- [1.1 begin headline] ================================================== --> - -<h1>Ghostscript projects seeking developers</h1> - -<!-- [1.1 end headline] ==================================================== --> - -<!-- [1.2 begin table of contents] ========================================= --> - -<h2>Table of contents</h2> - -<ul> -<li><a href="#Platforms">Platforms</a> -<li><a href="#Driver_architecture">Driver architecture</a> -<li><a href="#Specific_drivers">Specific drivers</a> -<li><a href="#Graphics_functionality">Graphics functionality</a> -<li><a href="#Performance">Performance</a> -<li><a href="#Other_functionality">Other functionality</a> -<li><a href="#Other_implementation">Implementation improvements</a> -</ul> - -<!-- [1.2 end table of contents] =========================================== --> - -<!-- [1.3 begin hint] ====================================================== --> - -<p>For other information, see the <a href="Readme.htm">Ghostscript -overview</a>. - -<!-- [1.3 end hint] ======================================================== --> - -<hr> - -<!-- [1.0 end visible header] ============================================== --> - -<!-- [2.0 begin contents] ================================================== --> - -<p> -There are many projects that would improve Ghostscript and that we would -like to do, but for which we don't have enough resources. If you would like -to take responsibility for any of these projects, please <a -href="mailto:raph@artofcode.com">contact us</a>. Additional comments on -implementation approaches or project goals are in <I>italic type like -this</I>. - -<h2><a name="Platforms"></a>Additional platforms</h2> - -<h3>DOS, Windows and OS/2 builds using gcc.</h3> - -<p> -We would like Ghostscript to work with the free <b><tt>emx/gcc</tt></b> and -<b><tt>rsx</tt></b> libraries, to provide an alternative DOS, Windows -95/98/NT, and OS/2 implementation that requires no proprietary, commercial -compilers. We think Ghostscript's existing OS/2 makefile already includes -most of what is needed. If someone is willing to do the work, we will be -happy to include this in our list of supported platforms and to distribute -the makefiles. - -<h3>Windows driver using Ghostscript as a language monitor.</h3> - -<p> -MS Windows has a "language monitor" capability which would allow Ghostscript -to be invoked seamlessly to process input files in any language Ghostscript -could handle (currently PostScript and PDF) and for any printer for which -Ghostscript had a driver. Doing this properly would require integrating -Ghostscript with Windows' "Add Printer" dialog, and would also require -creating a PPD for Ghostscript. <I>Russell Lang's RedMon program provides -some, but not all, of this capability.</I> - -<h3>Netscape browser plug-in.</h3> - -<p> -Currently, Ghostscript can work as a "helper application" for the Netscape -browser, but not as a plug-in; the latter would integrate it more closely -with the browser. We aren't sure what doing this would involve; we've also -heard by rumor that it's already been done. - -<h3>Ghostscript as an Active-X COM Object.</h3> - -<p> -In order to integrate Ghostscript into XMetaL and other applications it -would be convenient for Ghostscript to be distributed as a COM object -along with the current gswin32.exe, gswin32c.exe and gsdll32.dll files. - -<hr> - -<h2><a name="Driver_architecture"></a>Driver Architecture</h2> - -<h3>Improved multi-threaded rendering support.</h3> - -<p> -Currently, drivers can be written so that converting PostScript to a list of -graphical objects can run in one thread, and rasterizing the objects can run -in another thread. However, drivers must be written specially if they are -going to do this. We would like to change the architecture so that any -driver can work this way. We would also like to support dual-threaded -operation for drivers that produce high-level output, such as the PDF -writer. <I>Doing this would require separating banding from -the multithreaded logic. Also, currently each thread has its own allocation -pool: this is unnecessary in the normal case, since Ghostscript now supports -properly locked access to the C heap, but embedded systems still need to use -a fixed-size area for the rasterizing thread. With a locked, shared -allocator, the rasterizing thread could use the full set of band list -functions; with a fixed-size area and a separate allocator, only a subset is -available, as is the case now for dual-threaded drivers. -</I> - -<h3>Dynamic run-time loadable devices.</h3> - -<p> -Currently, drivers must be linked into the executable. We would like to be -able to load drivers dynamically. Doing this requires defining a -platform-independent API (presumably extending the current gp_* APIs) that -would work at least on GNU/Linux, vendor Unix, MS Windows, and Macintosh. Unix -systems should include Sun, HP, AIX, IRIX, DEC; Linux ELF and a.out formats -should both be supported. <I>Consider the Netscape plug-in -architecture.</I> - -<h3>Moving 'setpagedevice' into C.</h3> - -<p> -The PostScript 'setpagedevice' function implements matching of media and -page size requests to available media, page orientation, and paper handling -(duplex, etc.) Currently it is implemented in PostScript code, which means -it is not available for use with other input languages. (It is available -for PDF, which Ghostscript implements on top of PostScript, but not for the -not-yet-freely-available PCL interpreters that use the Ghostscript library, -or for possible future SVG or similar interpreters). We would like to move -this function into C. <I>The device driver will be required to -send page parameters up to PostScript to be stored in a resource. To be -included in this project are handling policy implementations in the device -drivers. DeferredMediaSelection should also be implemented.</I> - -<h3>Adding 'tee' for output to multiple devices.</h3> - -<p> -In a few cases, it would be desirable to provide a 'tee' capability for -drivers: specifically, for generating small, low-resolution 'thumbnail' -images concurrently with other output. <I>Probably the -simplest way to do this is to generate a band list and then process it -twice. This is not completely trivial, since the band list does include -device resolution information and scaling would be required for some -constructs.</I> - -<h3><b><tt>OutputDevice</tt></b> resource category</h3> - -<p> -Each available output device should provide an instance of the -<b><tt>OutputDevice</tt></b> resource category, which gives the available -page sizes, resolutions, media classes, process color models, and other -information about the device. <I>This would replace the current -non-standard use of a 4-element <b><tt>PageSize</tt></b> in the -<b><tt>InputAttributes</tt></b> entry of the page device dictionary.</I> - -<h3>Removing the limit on the length of OutputFile.</h3> - -<p> -Currently, the maximum length of the <b><tt>OutputFile</tt></b> parameter is -a compile-time constant, <b><tt>gp_file_name_sizeof</tt></b>. This is -appropriate for ordinary file names, since this constant is the platform's -limit on the length of a file name. However, if <b><tt>OutputFile</tt></b> -is a pipe, the length should not be limited in this way. <I>This is -probably a small project: it requires allocating the file name dynamically, -and freeing it in the finalization routine that gets called when a driver -instance is freed.</I>. - -<h2><a name="Specific_drivers"></a>Specific drivers</h2> - -<h3>PrintGear and PPA output drivers.</h3> - -<p> -We would like to provide (Adobe) PrintGear and (H-P) PPA output drivers for -Ghostscript, but the specifications for these protocols are not published. -If you can provide them to us without violating any agreements, please let -us know. (Some work has already been done on reverse-engineering these -protocols, but we don't have references to it.) - -<h3>Improve 'pswrite' up to the level of 'pdfwrite'.</h3> - -<p> -We would like to improve the high-level PostScript-writing -<b><tt>pswrite</tt></b> driver to bring it up to parity with the PDF-writing -driver (including the many improvements in the latter being implemented in -Ghostscript 7.xx). Specifically, we want it to write text as text rather -than bitmaps, and to consistently write images in their original high-level -form. <I>We have already started to factor out code that -should be common to these two drivers, specifically for writing embedded -fonts and compressed data streams.</I> - -<p> -There is one small part of this project that would be especially valuable -and could be done independently (although it might have to be partly or -entirely redone later): compressing images. Currently the driver only -compresses character bitmaps, and doesn't compress other images at all. -<I>It should use the <b><tt>CCITTFaxEncode</tt></b> filter for 1-bit-deep -images, and plane-separated <b><tt>LZWEncode</tt></b> compression for color -images, using the <b><tt>miGIF</tt></b> algorithms that are believed to be -free of the Welch patent for the latter. When generating LL3 PS, the -<b><tt>Flate</tt></b> compression will work better than miGIF. It may be -worth trying several methods on each image and use the one that works best.</I> - -<h3>High level graphics and text for PCL 5 and PCL XL drivers.</h3> - -<p> -Currently, the PCL 5 drivers produce only bitmaps; the PCL XL driver -produces high-level graphics and sometimes high-level images, but low-level -text. We would like to improve these drivers to produce higher-level, -smaller output. <I>This was a very low-priority project; it has become more -important now that H-P's laser printers are shipping with less memory.</I> - -<h3>Improved high level GDI driver for Windows.</h3> - -<p> -We would like a "GDI driver" for MS Windows that would implement more -higher-level constructs (specifically for text). <I> The -<b><tt>mswin</tt></b> and <b><tt>mswinprn</tt></b> drivers both do some of -this. Some of the the 'xfont' support code for MS Windows should be useful. -We were frustrated in the past because the GDI calls for getting font sizes -and metrics consistently returned incorrect information and provided no way -to get the correct information; perhaps this has been fixed in 32-bit -Windows. We believe that H-P, Russell Lang, and perhaps others are working -in this area, but we can always use more help.</I> - -<h3>PDF thumbnail generation.</h3> - -<p> -The PDF writer needs to be able to generate thumbnails (small previews). We -might do this through the 'tee' capability mentioned above. However, we -currently prefer the idea of implementing a completely separate program to -add thumbnails to an arbitrary, existing PDF file: this would allow -Ghostscript to add thumbnails to PDF files generated by other programs. -<I>Much of the code needed to do this has already been written -for Ghostscript's PDF linearizer: see -<b><tt>lib/pdfwrite.ps</tt></b>. A user has implemented this as well, -using a separate program that calls Ghostscript: see -<a href="http://www.uni-giessen.de/~g029/eurotex99/oberdiek/"> -http://www.uni-giessen.de/~g029/eurotex99/oberdiek/</a>. -</I> - -<h3>Consolidate inkjet drivers into a single family.</h3> - -<p> -In addition to factoring out the error diffusion code as described below, we -would like to see another attempt at reducing the enormous volume of code -for color inkjet drivers. There are three sets of drivers (gdevcdj.c, -gdevstc.c, gdevupd.c) with much overlapping functionality. The latter two -driver families make good attempts at factoring out things like head -geometry and canned control strings, but we think this problem deserves -another pass, especially in the hope of consolidating these drivers into a -single family. - -<h3>Download glyph bitmaps (with glyph decaching notification).</h3> - -<p> -See below under "Notification for glyph decaching." - -<h3>Preserve compression when writing PDF images.</h3> - -<p> -Currently, all images are decompressed by the interpreter before being -passed to the graphics library; the PDF writer may then compress them again. -Ordinarily, this only slows things down a little, but in the case of -DCT-encoded images that are being DCT-encoded in the output, image -degradation may occur. Ideally, the implementation should be smart enough -to not decode and re-encode the image. However, making this work properly -is difficult. <I>This would probably involve extending the library APIs for -images so that they could pass a stream, possibly including filters, instead -of the (fully decoded) data rows.</I> - -<hr> - -<h2><a name="Graphics_functionality"></a>Graphics functionality</h2> - -<h3>Support for 64-bit colors on 64-bit platforms.</h3> - -<p> -Currently, the library supports a maximum of 32 bits of data per pixel; we -would like to raise this limit to 64 bits on systems where the 'long' data -type is 64 bits wide. <I>The <b><tt>gx_color_index</tt></b> -type is already defined as 'long', but there are many places where the type -<b><tt>bits32</tt></b> is used for pixel values; there is a 32-bit -stored-image "device", but there is no 64-bit device; a few algorithms and -tables have knowledge of the 32-bit width built into them, only because the -C preprocessor doesn't have any kind of loop or repetition -capability.</I> - -<h3>In-RIP trapping.</h3> - -<p> -The PostScript specification includes an option for the interpreter to -implement trapping (adjustments of object boundaries to prevent visual -anomalies caused by slight misregistration of different ink layers): we -would like to implement this. <I>This is a complex and -difficult area; even many Adobe RIPs don't do it.</I> - -<h3>Hook FreeType TrueType library into graphics library.</h3> - -<p> -We would like to provide an option for good integration of the FreeType font -rasterizer into Ghostscript, since the FreeType code is better than -Ghostscript's current rasterizers. We understand that some users in Japan -have done this already, but we don't know if this is a good starting point -(the only documentation is in Japanese). <I>Their work uses -Ghostscript's 'xfont' interface, which is how Ghostscript interfaces to -platform facilities such as the X and MS Windows font capabilities. This is -a device-level interface and not the best place to do this: we would rather -have the graphics library interface to FreeType directly.</I> - -<h3>ICC profile support for output.</h3> - -<p> -Ghostscript 7.00 and later supports ICCBased color spaces of PDF -using the icclib package from -<a href="http://web.access.net.au/argyll/color.html "> -http://web.access.net.au/argyll/color.html</a> -but there is no facility to use ICC output (printer) profiles that -may be embedded in the PDF. Also it would be useful for PostScript -to be able to directly use a specific Intent from ICC profile to -convert output colors (as CRD's are now used). -<I>The primary difficulty is that the graphics library and PostScript -always use CIE XYZ as the connection space, but ICC profiles may -use CIELAB as the connection space, requiring conversion for use -with the graphics library. </I> - -<h3>Making halftones into "objects" and adding new types.</h3> - -<p> -Currently, knowledge of the specific data formats and algorithms for -halftoning permeates too many places in the library. We would like -halftoning to be more "object oriented" (using virtual procedures) so that -we could support other halftoning methods such as direct use of threshold -arrays, or the double-rectangle approach added in newer PostScript versions. -<I>Threshold arrays take much less space than the current -representation, generally at the expense of longer rendering time for -black-and-white images; double-rectangle representation would give us a -better implementation of AccurateScreens. We might want store both -threshold arrays and the current representation.</I> - -<h3>Factor out error diffusion routines, integrate ETS.</h3> - -<p> -Currently, several different inkjet drivers implement their own, very -similar but slightly differing error diffusion methods. This has caused -severe code bloat as well as tempting future driver writers to contribute to -it further. We want to factor out error diffusion into a common set of -facilities that drivers can use. <I>We would like to design -these facilities so that they can easily interface to the Even-Toned -Screening algorithms from artofcode (Raph Levien), to the extent that these -will be Open Source.</I> - -<h3>Improve, or generalize, linearization for stochastic threshold -data.</h3> - -<p> -The Ghostscript distribution includes a stochastic threshold array. This -array has some gamma correction built into it, which works well for some -output devices and not for others. We would like to provide a version of -this array without (or with less) gamma correction. <I>We have -original data available from which this could be done fairly easily.</I> - -<h3>Change sampled functions to use new interpreted functions.</h3> - -<p> -The PostScript language defines many functions relevant to graphics -rendering as being implemented by arbitrary PostScript procedures: transfer -(gamma correction), black generation, undercolor removal, several stages of -CIE color space and rendering, and color mapping for Separation and DeviceN -spaces. Since the graphics library can't call PostScript procedures, -Ghostscript currently samples these procedures at a fixed number of points -and interpolates linearly between the samples. As of Ghostscript 6.20, the -library can interpret a restricted subset of PostScript procedures directly -(basically those that only use arithmetic and comparisons: no loops, -sub-procedures, or data structures). Changing the rendering functions to -use this approach when possible would greatly improve output quality when -the functions are very non-linear (which we have actually seen in practice). -<I>This should only be done if the function is, in fact, -severely non-linear, since interpreting the function definition will almost -always be much slower than interpolating in the table.</I> - -<h3>Add optional cubic interpolation to RenderTable and other table -lookup.</h3> - -<p> -Currently, if a CIE rendering dictionary uses a lookup table for the final -step, Ghostscript always interpolates linearly between the entries. Cubic -interpolation should be supported as an option. A cubic interpolation -option is also needed for general table-lookup Functions. - -<h3>Add better (SVG-like) alpha channel and compositing to library.</h3> - -<p> -Ghostscript has partial support for alpha channel and for alpha and RasterOp -compositing. There is some architectural support for general compositing, -but it postdates the RasterOp implementation, and most of the RasterOp code -doesn't use it. We expect that the more extensive compositing and alpha -capabilities of SVG will find their way into PDF (and probably PostScript as -well) in the course of 2000 and 2001, and we will need to implement them. - -<hr> - -<h2><a name="Performance"></a>Performance</h2> - -<h3>Change band list logic to defer halftoning until rendering.</h3> - -<p> -Currently, when Ghostscript uses a band list, it does halftoning before -banding. It should do halftoning after banding: this produces smaller band -lists and shifts more work to the rasterizer (which is good because the -rasterizer can be multi-threaded internally for higher performance on -multiprocessors: see the next topic.) - -<h3>Reduce redundant data for smoothed banded images.</h3> - -<p> -When smoothed ("interpolated") images are written in the band list, extra -rows must be written above and below each band in order to provide the data -for interpolation. Currently, the number of such rows is computed very -conservatively; instead, the final interpolation algorithm should be -consulted to provide the correct value. <i>This is a small task.</i> - -<h3>Multi-threaded rasterizing</h3> - -<p> -For high-resolution devices, rasterization dominates execution time. On -multiprocessor systems, Ghostscript can do tasks in parallel: - -<ul> - -<li>Rasterize multiple bands simultaneously; - -<li>Rasterize multiple color planes of a single band simultaneously (if a -planar representation is being used); - -<li>For some computation-intensive tasks like smoothing images or filling -large regions, partition the task (possibly buffering more data to allow -larger-grain partitioning) and execute several partitions simultaneously. - -</ul> - -<p> -We would want these facilities implemented so that no conditional -compilation was involved: on uniprocessor systems, the locking API would -simply have a vacuous implementation. - -<h3>Notification for glyph decaching.</h3> - -<p> -Currently, drivers can't do a very good job of downloading rendered -character bitmaps to the device they manage, because they can't find out -when a bitmap is being deleted from Ghostscript's cache and therefore will -never be referenced again. Here is a sketch of how we would add this -capability to the graphics library: - -<ul> - -<li>The driver would implement the <b><tt>text_begin</tt></b> call, simply -to get access to a <b><tt>gs_imager_state</tt></b> that references the -rendered character cache. (The driver could always simply call the default -implementation of <b><tt>text_begin</tt></b>.) - -<li>In the <b><tt>text_begin</tt></b> procedure, the driver would call - -<blockquote><pre> -gs_glyph_decache_register(imager_state, notify_proc, proc_data) -</pre></blockquote> - -<p> -where <b><tt>proc_data</tt></b> was, or pointed to a structure that -included, a pointer to the driver. - -<li><b><tt>gs_glyph_decache_register</tt></b> would use the general -notification mechanism defined in <b><tt>gsnotify.h</tt></b> to call - -<blockquote><pre> -notify_proc(proc_data, pchar_data) -</pre></blockquote> - -<p> -whenever a bitmap was removed from the character cache. -<b><tt>pchar_data</tt></b> would point to some identification of the -character; perhaps just the bitmap ID, but possibly a -<b><tt>gx_cached_bits_common</tt></b> or even a <b><tt>cached_char</tt></b>. - -<li>The <b><tt>char_cache</tt></b> structure would be need an additional -member, a <b><tt>gs_notify_list_t</tt></b>. It would also need to add -finalization so that when it was freed, it would notify and unregister all -clients, using <b><tt>gs_notify_all(list, NULL)</tt></b> and then -<b><tt>gs_notify_release</tt></b>. - -</ul> - -<p> -<I>This facility was requested by the Display Ghostscript project, but it -could also be used to improve the output of the PCL XL driver and possibly -the X and PCL5 drivers.</I> - -<hr> - -<h2><a name="Other_functionality"></a>Other functionality</h2> - -<h3>OpenStep (Display PostScript + NeXT) extensions to Ghostscript.</h3> - -<p> -There is a project to create a GNU implementation of the OPENStep API, which -involves extending Ghostscript to provide the full functionality of Adobe's -Display PostScript system with some of the NeXT extensions. For more -information, please contact Net-Community <<a -href="mailto:scottc@net-community.com">scottc@net-community.com</a>>. - -<h3>Job Server implementation.</h3> - -<p> -For full Adobe PostScript compatibility, Ghostscript needs a real "job -server" to encapsulate the execution of PostScript files. -<I>See the section on "Job Execution Environment" in the PostScript -Language Reference Manual for details.</I> - -<h3>SVG (XML Structured Vector Graphics) interpreter.</h3> - -<p> -Ghostscript could be adapted with some work to read SVG. This would be an -interesting and challenging project because SVG's graphics model would -require extending the library (see above). <I>If SVG turns out to be an -important standard, it is important that there be a good free implementation -of it.</I> - -<h3><b><tt>%font%</tt></b> and other IODevices.</h3> - -<p> -Currently, the <b><tt>%font%</tt></b> IODevice is not implemented. We would -like to see this implemented using a general framework for implementing -IODevices (%xxxx%) entirely in PostScript, in an "object oriented" manner -very similiar to the way Resource categories are implemented. An IODevice -would be implemented as a dictionary with the following keys, whose values -would be procedures that implemented the corresponding operation: - -<blockquote><pre> -/File -/DeleteFile -/RenameFile -/Status -/FileNameForAll -/GetDevParams -/PutDevParams -</pre></blockquote> - -<p> -There would only be global IODevices, no local ones; the dictionary keeping -track of them would be stored in global VM. - -<p> -<I>This is an obscure feature that matters only because some PostScript code -uses <b><tt>filenameforall</tt></b> with this IODevice, rather than -<b><tt>filenameforall</tt></b> with the <b><tt>/Font</tt></b> Resource -category, to enumerate available fonts.</I> - -<h3>Repairing damaged or EOL-converted PDF files.</h3> - -<p> -Adobe Acrobat Reader can scan a PDF file that has had its end-of-lines -converted by careless users transferring the file across operating systems -as text rather than binary across, and reconstruct the cross-reference table -which the PDF interpreter requires. This only works if the file has no -binary data in it, which with PDF 1.3 is rarely the case. However, users -occasionally receive PDF files that have been damaged in this way, and it -might be useful to have a program that can repair them. <I>We think this -should probably be done as a separate program, possibly in PostScript, -similar to Ghostscript's PDF linearizer.</I> - -<h2><a name="Other_implementation"></a>Implementation improvements</h2> - -<h3>Fully re-entrant code.</h3> - -<p> -Currently, neither the PostScript interpreter nor the graphics library is -fully re-entrant (no writable globals). Making them fully re-entrant would -make Ghostscript usable in multi-threaded environments, and more easily -usable in embedded environments. Note that this is necessary, but far from -sufficient, for Ghostscript to allow simultaneous execution of a single -Ghostscript interpreter instance by multiple threads: that is probably -permanently out of the question. <I>Almost all drivers, including all of -the drivers in devs.mak which are maintained as part of the main Ghostscript -code, are already fully re-entrant; making the remaining ones re-entrant -should really be up to the driver author.</I> - -<h3>Ghostscript has no %ram% device.</h3> - -The %ram% device is documented in PS Supplement 3010 and 3011 dated August 30, 1999. -This is probably not a major impediment to portability, but it would be handy. -<p><I> -On Unix, the suggested implementation would be to create a subdirectory -of the temporary directory (usually /tmp), with the name chosen and the -directory created in such a way as to avoid /tmp races and similar -problems. Ghostscript should delete the subdirectory when it exits. -</I> - -<!-- [2.0 end contents] ==================================================== --> - -<!-- [3.0 begin visible trailer] =========================================== --> -<hr> - -<p> -<small>Copyright © 2000 Aladdin Enterprises. All rights -reserved.</small> - -<p> -This software is provided AS-IS with no warranty, either express or -implied. - -This software is distributed under license and may not be copied, -modified or distributed except as expressly authorized under the terms -of the license contained in the file LICENSE in this distribution. - -<p> -<small>Ghostscript version 7.07, 17 May 2003 - -<!-- [3.0 end visible trailer] ============================================= --> - -</body> -</html> |